2.5D游戲,雖然在外觀上近似于3D游戲,卻又不是嚴格意義上講的3D游戲,故此2.5D游戲又常被稱為[偽3D游戲]。
在筆者的觀念中,2.5D嚴格上說并不能算是一種技術(shù),而只是一種實現(xiàn)方式或者說應(yīng)用手段。大多數(shù)時候,游戲公司之所以會采取2.5D方式開發(fā)游戲,常是為解決3D及2D技術(shù)混用而采取的一種折中,而并不是說這種手段有多么先進。2.5D游戲的實現(xiàn)方式雖然很多,但主要無非有三類,即:2D角色+3D場景(比如RO1)、3D角色+2D場景(比如生化復(fù)刻版)、2D角色+2D場景(比如仙劍),另外有些純3D游戲出于操作性考慮而固定視角,勉強擦了個2.5D的邊,但嚴格上講依舊是3D。
除了2D角色+2D場景是利用斜45度的2D圖片來“冒充”3D效果以外,其它組合方式大多有真正的3D演算參與其中,不過是出于開發(fā)效率或者游戲風(fēng)格等外部因素考慮而混入2D,可以說是一種產(chǎn)生在2D向3D演變過程中的過渡物。
使用2.5D方式開發(fā)游戲的好處在于,能夠免去純3D圖像渲染所涉及的海量運算,從而減低不必要的系統(tǒng)資源損耗,并且在處理單純的2D畫面時,貼圖也明顯較系統(tǒng)渲染為快,最主要的是——開發(fā)周期明顯較3D游戲更短。
當然,缺點也很明顯,最核心的一點就夠——不倫不類,非驢非馬。
具體到2.5D游戲開發(fā),根據(jù)選擇的技術(shù)不同,也會產(chǎn)生不同的實現(xiàn)手段,筆者在[Java中2.5D游戲(斜45度角)的設(shè)計與實現(xiàn)]系列博文中內(nèi)所要介紹的,是最簡單,同時也最方便的2D角色+2D場景——偽45度角方式,不需要的可以無視此文了,具體到真3D與2D的混合,筆者將留到介紹JME時再去講解。
在正式開始本回之前,我們先來簡要介紹下不同維度空間的特點:
零維,簡單講就是沒有維度,表現(xiàn)形式上就是一個[點],沒有長度,更沒有高度。實際上,很多人認為宇宙最初就是個零維空間。
一維,多體現(xiàn)為一條[直線],也可以理解為一個只有長度,而沒有高度的無限線性空間。
二維,即我們常說的[平面],由X及Y兩點交織而成,即只有長與寬,典型的二維空間存在方式是數(shù)據(jù)表格。
三維,三維即[立體],若誰不能理解三維,請隨意向顯示器四周看看,舉目所及全是三維空間。從技術(shù)角度解釋,三維就是在二維的長、寬基礎(chǔ)上再加個高度(厚度)形成的體積面,典型的三維存在方式就是我們這個世界。
四維,四維空間是個非常模糊的概念,實際上它象征著[n維]。在物理學(xué)及數(shù)學(xué)概念中,一個n的序列可以被理解為一個n維空間中的位置,當n=4時,所有這樣的位置的集合都叫做四維空間,但是當n-1或者n+1時,它又會自然過渡成其它空間。這種空間與我們熟悉并在其中居住的三維空間不同,因為它多一個維度。這個額外的維度既可以理解成時間,也可以直接理解為空間的第四維,即第四空間維度。當我們說到四維空間時,常會扯出天堂、地獄、陰陽界等超自然理論,實在玄之又玄,筆者也不知道它究竟怎樣表示才好……
由于人類生存在三維空間,我們周圍的空間自然也都具有三個維度(上下(長)、左右(寬)、前后(厚度)),用中式思維解釋就是世有八荒(又稱八方,即“東、西、南、北、東南、東北、西南、西北”八個方向),人居六合(即“上、下、東、西、南、北”六個方位),我們也都很自然的會用“八荒六合”來進行方位判定,當然,最先決的方位判定條件是“我在其中”。
如果一個人能在“八荒六合”之內(nèi)與我一樣行動,我當然會認為他與我一樣練成了八荒六合唯我獨尊功……咳,我是說認為他與我同樣是一個立體的人,而不是一張紙片,嗯嗯(=_=|||)。
同樣的道理,在游戲中如果一個2D Sprite的行動模式與3D Sprite一致,那么用戶便很容易“誤認”此單元為3D,而非2D。原因就在于,人眼是極好蒙蔽的,比如好萊塢早期大片中就經(jīng)常使用紙制建筑來冒充城鎮(zhèn)或者某個名聲古跡;即便游戲2.5D游戲中沒有實際的3D坐標及多面計算,只要能給人眼以“距離感”或者說“立體感”,我們也會認為這個游戲是三維存在的,而沒人會去關(guān)心它是否真正使用了3D渲染方式。
換句話說,只要我們創(chuàng)建的游戲單元“看上去”能“行八荒”,“游六合”,也就是看上去它的行為是3D立體的,玩家就會認為角色正處于一個三維空間之內(nèi),而不是穿越到某個2D世界。
那么,這個“看上去移動”的效果要如何達到呢?
我們用下圖作為示例:

通過上圖中我們可以發(fā)現(xiàn),此圖中角色的單元動作被分解為八種不同類型,即上、左、右、下、左上、右上、左下、右下,而此八種動作正好對應(yīng)著“八荒”中的“北、西、東、南、西北、東北、西南、東南”。由于人眼所能觀測到的運行是相對的,只要背景或者角色中任意一者發(fā)生移動,我們都會產(chǎn)生“移動”的“錯覺”。所以我們并不追求角色的實際3D運動,而只是令角色單元能做出對應(yīng)“上、左、右、下、左上、右上、左下、右下”這八方向的動作,在普通人眼中,便與角色移動向“北、西、東、南、西北、東北、西南、東南”這八個方向無異。
因此,在2D制作2.5D效果時,每個角色的動作單元實際上都只是一幅分幀小圖罷了。
如何判定對應(yīng)的單元圖像呢?
具體到單元動作的顯示判定,和游戲采取的斜視角產(chǎn)生方式息息相關(guān),大體上分可分兩類,即非等距坐標實現(xiàn)與等距坐標實現(xiàn)。
1、非等距坐標實現(xiàn):
邏輯如下圖:

以0點為常模(參照物),在2D地圖上“錯位”繪制角色,每次角色移動時偏移相應(yīng)坐標,配合圖片產(chǎn)生45度移動錯覺。
優(yōu)點:在編程上極容易實現(xiàn),并且更利于地圖及角色的聯(lián)合操作。
缺點:如果不對單元與地圖的交織部分進行細節(jié)處理,很容易產(chǎn)生移動“生硬”感,并且很難融入一些較復(fù)雜的地形判定。
2、等距坐標實現(xiàn):
邏輯如下圖:
實際上此圖沒有任何坐標變化,而是在不改變2D圖形X,Y坐標系的基礎(chǔ)上,等距轉(zhuǎn)換坐標點位置為斜45度時的狀態(tài),由于坐標系經(jīng)過等距轉(zhuǎn)換,所以實際操作中與2D無疑。
優(yōu)點:除了坐標轉(zhuǎn)換外,基本上還是2D那一套,純2D時怎樣處理便怎樣處理。
缺點:為了配合傾斜后的X,Y坐標拼接,大部分平面圖必須轉(zhuǎn)換為45度圖,當然這是美工的事(^^)(PS:雖然也可以在平面圖上自動換算出所需的斜視圖形,但細節(jié)處通常不夠理想,而且耗費不必要的運算資源,還是交給美工直接切出成品圖最好,鄙人大原則就是能麻煩美工就不勞駕程序員(^^)),不過象筆者這樣個人研究就超麻煩……
在本系列博文在后面會涉及到此部分,在這里先給出一個基本概念。
首先,要轉(zhuǎn)換坐標為斜45度時位置,至少需要以下參數(shù)。
1、mapX(地圖X坐標)
2、mapY(地圖Y坐標)
3、mapMaxY (Y軸的最大縱深)
4、tileWidth(每塊小圖寬度)
5、tileHeight(每塊小圖高度)
而后我們才可以根據(jù)基礎(chǔ)參數(shù)換算坐標位置:
screenX (屏幕坐標X)
screenY (屏幕坐標Y)
screenX = (mapX - mapY + mapMaxY) * (tileWidth / 2);
screenY = (mapX + mapY) * (tileHeight / 2);
bevelMapX (傾視的X坐標)
bevelMapY (傾視的Y坐標)
bevelMapX = ((screenY / tileHeight) + (screenX - (mapMaxY * tileWidth/2)) / tileWidth);
bevelMapY = ((screenY / tileHeight) - (screenX - (mapMaxY * tileWidth/2)) / tileWidth);
這時得到的bevelMapX及bevelMapY,就是斜45度時的繪圖位置,以此坐標繪制準備好的斜視圖,就自然會呈現(xiàn)在斜視情況下的X,Y點位置上。
由于本例中為非等距實現(xiàn),也就是在2D地圖上直接位移角色單元到斜點,故此不需要額外的進行地圖坐標換算處理,但是人物坐標則需偏移。
下面開始我們用代碼示例說話:
Role.java(負責(zé)描述一個角色單元的行為)
RprMap.java(負責(zé)描述角色單元集合在地圖上的具體位置)
Main.java(初始配置及程序運行)
示例截取圖如下所示:


本回提供的源碼內(nèi)容包括:八方走法(支持鼠標及鍵盤)、地圖移動、角色碰撞、NPC隨機行動,詳細請下載參看.
至于腳本處理、事件觸發(fā),對話框、場景轉(zhuǎn)換、角色對戰(zhàn)等部分將在以后逐步講解。
下載地址如下:http://code.google.com/p/loon-simple/downloads/list
PS:這個jar有315KB(源碼在jar內(nèi)),但代碼實際并不多,空間都是圖占的……
——————楚河漢界分割線——————
一直說寫關(guān)于JME的文章,直到最近兩天才著手弄了點JME的介紹及例子,等五一整理下再發(fā)出來。(鄙人的懶性是很驚人的,比如07年底我就想裝個VS2008,結(jié)果到今天也沒安上……)
另外到我五一時準備把前一陣說過的TLOH發(fā)出來,這東西實際上就是非組件化的LoonFramework-Game應(yīng)用,發(fā)的目的就是讓大家?guī)椭母模畈欢嗑投ㄐ瘟耍鹊桨l(fā)LoonFramework-Game包時我可不想和某些東西似的不同版本間接口與函數(shù)都沒個連貫性……
還有隨著筆者手頭積累的Java游戲代碼越來越多,功能越來越復(fù)雜,又產(chǎn)生了想寫個類似于RpgMakerXP的游戲編輯器的念頭,于是業(yè)余時間大體上是這樣度過的:找編輯器資料(學(xué)習(xí)其業(yè)務(wù)實現(xiàn))-〉找解釋器(比如TVP使用的TJS腳本,參考其腳本模式)-〉下游戲(下載同人游戲,學(xué)習(xí)其打包及應(yīng)用模式)-〉玩游戲(很多日寇的同人游戲也讓人上癮,-_-|||),這樣一晃就三個多星期,筆者一直以來的致命缺點就是心太散,注意力超級不集中|||……
浙公網(wǎng)安備 33010602011771號