Cocos2d-x類COC手游與RTS(即時戰略)游戲的編程實踐總結

>>>  創業先鋒 眾人拾柴火焰高  >>> 簡體     傳統

概述

  2014.08.13-2014.09.15 這一個月左右的時間里,我獨自一人在家做了上面視頻中技術演示的demo。用的是Cocos2d-x引擎。說到Cocos2d-x,我接觸有一年了。

  這個demo中的圖片資源都是我自己網上找的。而按鈕等UI是我用PS自己畫的,主要是網上找不到合適的UI。下方的方形按鈕,是我模仿COC的來畫的。

  下面截圖是Windows上開發環境(VS2013)運行的效果:


  下圖是編譯到了安卓手機運行的效果:


  從上面的視頻和截圖可以看到,一個月里,對于制作類COC游戲,我在技術上進行了一些嘗試和探索。我之前沒怎么做過游戲,嘗試去做,可以發現編寫這類游戲會遇到哪些問題,并且思考怎樣解決。算是一種積累經驗吧。

  關于COC,大家應該都不陌生。Supercell公司成立于3年前,后來推出了一款叫 Clash of Clans 的移動游戲,簡稱COC。這款手游后來成為了地球上2014年最賺錢的手游,并且Supercell市值飆到了30億美元

  最初我是想模仿制作一個類COC的手游(也許最終會和COC有很大的不同),并且加入RTS游戲的元素。比如:可以直接選中和控制兵的移動和攻擊,增加操作感等。

  為什么我會想加入RTS的元素呢?因為,很久很久以前,我是一個魔獸3遭遇戰玩家,曾經BN亞洲戰網排名前100-200。

  在視頻中,你會看到。我已經實現的游戲功能有:擺放建筑,拖曳和縮放游戲場景,單位兵種移動和簡單的攻擊。我沒有加入任何游戲的業務邏輯代碼。因為我想搭建一個基礎框架或者是理清一下思路。熟悉編寫這種游戲后,可以改成:RPG(角色扮演),RTS(即時戰略),SLG(策略),塔防等多種類型的游戲。

  試想一下,如果用做RTS的技術來做一個塔防有多酷。RTS對現實世界有更仿真的模擬,但同時技術含量肯定也會比《保衛蘿卜》等高。這就是之前為什么說“也許最終會和COC有很大的不同”的原因。

  COC這類的游戲,相對其他手游來說,編寫的難度要復雜很多。下面總結一下,目前我已知的,編寫類COC游戲會遇到的技術點。

編寫類COC游戲的一些技術點

1. 操作的策劃


  是先定義好操作規則然后實現,還是一面做一面想一面改?

  我覺得可能是后者,除非一點都不創新,想原封不動地照搬“被抄襲的產品”。一開始誰都不太可能把整個系統,整個規則都想清楚,都定義下來。因為我是一個人,所以,我是一面做一面想一面改。我一開始不可能把各種細節都想清楚,所以是先做著看看。

  騰訊的《城堡爭霸》是一款仿COC的產品,操作上和COC有一些不同。比如:移動建筑,手指放開的時候,就直接擺下建筑了。而COC還要再點擊一下確定擺下建筑。在操作上,COC多了一個再次點擊。

2. 操作代碼的編寫

  COC這種游戲,是一種游戲元素很多的游戲。通常上面有樹、石頭,建筑,各種兵種角色單位等。有3種基本操作。

  • 單個手指滑動代表拖曳游戲場景。

  • 兩個手指代表縮放游戲場景。

  • 點擊屏幕同時也代表選中一個單位。


  騰訊的《城堡爭霸》的2個手指的捏合縮放是和COC不同的。《城堡爭霸》的實現算是“中心縮放”,不能同時移動游戲場景。我的實現是仿COC,看視頻就知道了,縮放場景的同時還能控制場景移動。

  拖動與縮放還需要有限制:不能移動到游戲世界區域之外,看到游戲世界外面的黑塊。不能無限放大和縮小。我目前只做了縮放的限制,還沒做移動的限制。移動限制的話,有點麻煩,和縮放是有關系的。

  觀察COC就會發現,如果在一個建筑上面按下手指,如果沒有拖動的話,就是選擇這個建筑。如果拖動了,就不會選擇這個建筑,而只是拖動游戲場景。所以,程序中要做一些判斷和記錄:是否有拖動等。

  像我這種,還加入了RTS控制元素,可以選擇行動體單位并且控制它進行移動和攻擊,這會讓操作控制代碼變得更復雜。對于這種復雜的操作,我是用狀態機來解決。在onTouchesBegan,onTouchesMoved,onTouchesEnded 3個觸摸函數中都弄了狀態機。觸摸函數肯定用的是多點觸摸,否者沒法搞雙手指捏合縮放。我新建一個觸摸層來專門處理觸摸,因為操作的控制本身就很復雜,這樣做可以分割復雜度。

  我的onTouchesMoved的代碼截圖:


  外層代碼,先判斷是一個點觸摸了,還是2個點同時觸摸。然后在2個判斷分支中都做switch-case的狀態機處理。有看過設計模式的同學可能會知道,用switch-case寫狀態機代碼是“幼稚的”,我覺得,如果在嘗試階段,還沒想清楚的時候,用switch-case也無妨。等我想清楚的時候,我可能會改成狀態模式的實現。

3. 角色的AI

  COC中有一些“行動自治體”,比如,有一些角色,會到處走動,一下子摸摸樹一下子摸摸石頭。空降兵到敵人領地時會進行自動攻擊等。這是一些什么三消,跑酷類游戲都沒有的。編寫這些AI,讓玩家有一種在“世界”中的感覺,是相對于其他類型的手游額外多出來的部分。基本上用狀態機建模,都可以搞定這些AI。但目前我的實現程度,還沒有做“行動自治體”。

  尋路也屬于AI部分,求最短路徑的A*算法就是人工智能領域中的算法。其實COC中的尋路是比較簡單的,相比紅警,帝國,魔獸等這種真正的RTS游戲來說。我的游戲中用的尋路也是A*。

  之前我有嘗試,把尋路算法改成開一個線程來計算,這樣的話,就可以不卡住界面。傳統軟件的編寫經常這樣用。但后來再改的過程中遇到不少麻煩和問題,遂暫時擱淺之。

編寫真正的RTS游戲的技術點

  COC其實并不是一個真正RTS游戲,而是一個經營策略類游戲。之前提到了,我想加入RTS游戲的元素,那么我們來看看RTS游戲有什么技術點。

1. 不允許行動體互相穿越的限制

  COC的人物是允許互相穿越的,就是2個行動單位可以互相重疊在一起。魔獸3的行動單位則不允許。不允許互相穿越是基于現實的模擬。正是因為不允許穿越,魔獸3才有了“卡位”,”M圍殺“等各種操作技巧。

  我在實踐的過程中發現,魔獸的限制穿越的編寫處理是比較麻煩的。我個人猜測可能Supercell感覺這個問題實在是有點費神,所以就允許穿越了,不做那么真實的模擬。允許穿越,實際上會極大降低程序的編寫復雜度,為什么這樣說呢?聽我娓娓道來。

  不允許穿越通常是用碰撞檢測的方法來做,如果游戲場景很大的話,為了降低碰撞檢測的時間復雜度,需要做空間分割處理。

  不允許穿越會涉及更多的AI問題。比如:”移動碰頭死鎖“。呵呵,”移動碰頭死鎖“是我自己發明的名詞,用來描述這樣一種場景:在一個狹小且長的通路中,比如一座橋、一個巷子里面、樹林的間隙中,或者甚至是空地,有2個單位,A從左向右行走,B從右向左行走,這2個單位都在同一個水平線上,那么就有一個”你不讓我,我不讓你“的問題。

  用我的游戲截圖,如下圖:



  上圖,A和B都往對方的方向走去,在某個時間上,他們會”碰頭“,如下圖:


  如果沒有AI控制的話,就會出現互不相讓的”死鎖“,雙方都在不斷往對方的方向”推“。這種情況,我們需要編寫AI去決定A和B如何謙讓,然后,再行動到各自的目的地。目前我的做法比較簡單,有一個行動體可能會停下來,然后另一個行動體繞過他。或者是2個行動體都停下來。玩家需要重新控制行動。這種做法會讓玩家覺得游戲中的人物很”蠢“且自己很麻煩,行動體不會聰明避讓且需要自己重新控制行動。
還有就是”集體行動“時的控制。如下圖:


  控制了一幫人往一個地方走,他們之間是不允許互相重疊的。在碰撞檢測中,如果發生了碰撞,需要判斷,是之前說的“碰頭”還是“大家往同一個方向走”的情況。如果是非碰頭情況,我的做法是:等待前面的單位移動出空位之后,后面的單位才上前挪一點。

  代碼截圖:


  從上面代碼可以看到,我僅僅是暫停了Node節點的移動Action。如果檢測發現沒有碰撞了,就恢復執行之前的MoveTo動作。目前我的實現還有缺陷,并不完善。在某種情況下,集體行動,會出現“穿越”的問題,但在大部分情況下是可以保持不穿越的。

  實際上,防穿越還會涉及更多的細節問題,這里我就不一一列舉了。

  從上可以看到,如果加入了防穿越,會讓程序復雜很多。允許穿越的話,什么“碰頭死鎖”,“集體移動”等問題都沒有了。從復雜度、開發成本等各方面因素考慮,我想這是Supercell不做防穿越的原因。

2. 行軍算法、布陣算法

  在魔獸3中,控制部隊達到某地,是有行動隊形的。目前我還沒有仔細去考慮如何做,但這個在RTS游戲中是存在的。另一個問題是關于布陣。仔細觀察和研究魔獸3,選中8個農民到某地,那8個農民到目的地后,有一個類似于矩形的陣型。

  規則布陣這個問題,我也沒仔細考慮。但不可避免的是隨機陣型總要考慮,就是說,如下這種情況:
選中了N個單位,然后指揮他們到某處。這N個單位因為受之前的仿穿越限制,他們不能集中在一個點上。那么,如何確定各個單位的目的點?

  我的做法是:在目的點,進行BFS(寬度優先搜索),尋找每個單位可以被容納的位置,為什么用BFS算法?因為BFS有圓形向外擴展的特性。

  我的代碼截圖如下:


  有一個細節是,如何保持原先的集體“布局”?

  看下圖:


  A,B,C 對于整個選中的單位集合來說,有自己所處的位置。移動這些單位到另一處,好的做法是,也同時保持他們原先在集體中的位置。因為,這樣做是對整體行軍來說,總體移動成本最小。總體移動成本就是說,對于集體中每個行動單位的行動耗時、路徑長度等之和。總體移動成本越小,給玩家的感覺就越和諧。

  我在實踐中,發現了這個問題,做了一些簡單處理。不過從目前來說,效果并不怎么好。

3. “A過去”如何做

  玩魔獸的朋友都知道“A過去”的含義吧?A過去就是“攻擊過去”的意思,源于魔獸3的A鍵控制。

  “過去攻擊”包括2個分解步驟,1.先走過去,2.達到攻擊范圍后,開始攻擊。A過去有2個作用點:1.玩家A的是地板。2.玩家A的是一個游戲實體,某個敵軍單位、建筑等。

  玩家A的是地板的話,AI邏輯是:控制行動體走到A的目的點,如果在行動的過程中有敵軍進入了攻擊范圍,就攻擊,殲滅了敵軍,繼續走到目的點。玩家A的是某個游戲實體的話,AI邏輯是:記住被A的那個目標實體,追著他打,直到目標被殲滅。

  紅警的A,坦克會用炮彈攻擊地面。魔獸3的A,只有控制投石車才會攻擊地面。目前我還沒實現A過去的邏輯。

4. 單位大小通過限制

  魔獸3中的食尸鬼可以通過的地方,劍圣不一定能通過。因為,食尸鬼、劍圣、尸魔 等 的體積不一樣。單純的A*算法,只是能找到有聯通的最短路徑。

  劍圣的尋路是怎樣做的?是不是要在A*算法作用的瓦片方格上,把劍圣不能通過的地方,給填充上,再執行A*呢?這個問題我沒想清楚。目前我的游戲也不處理這點。

  綜上淺談的4點就可以看到像魔獸這樣的RTS游戲編寫的難度。實際上編寫一個真正的RTS還遠不止這4點那么簡單,想想 戰爭迷霧、地形 等等。肯定還有一些未知的技術難點,我還沒意識到。
考慮用數據驅動的方式編寫游戲

  所謂的數據驅動,就是用一些配置來控制游戲的顯示、行為等。我的demo目前是用COC和其他游戲的素材來做的,以后要改成 RPG,塔防什么的,肯定不能盜用別人的美術資源,是吧。
為了方便換皮。游戲實體的顯示、動畫的顯示。我都用了配置來搞。如下面所示。

  動畫表:


  精靈表:


  行動體的顯示控制表:


  等等。有10個表了。

  這些配置表,用Excel來做,然后另存為CSV。程序去解析CSV文件數據。目前,我的這個demo也只用了CSV類型的數據做配置,并且也是我用之前博客中寫的那個CSV類去做解析。

思考的過程

  這里也和大家分享下,我思考的過程。

  《暗時間》這本書中講過,思考是要借助筆和紙的。記錄下當前自己探索到的、思考到的步驟和環境。以便于回溯思維的時候,防止忘記自己推理到哪一步了。

  一個人獨立開發,很多時候是自己和自己對話。自己提出設想,自己論證。這種情況就更加需要筆和紙。
下面是我的一些草稿紙截圖。



最后

  目前我沒發現市面上有任何一本書去教如何寫RTS游戲。一個月的嘗試,還是有價值的。

  僅僅是做類COC的話,感覺并不很復雜。而一旦加入真正的RTS元素,就知道紅警、帝國、魔獸的技術含量有多高了。騰訊等公司可以模仿出COC,什么城堡爭霸,陌陌爭霸 等。但他們目前做不了“類魔獸3”,“類星際2”,魔獸爭霸3 不僅是一個真正的現代RTS,還是3D的。我估計,不是他們不想,而是“類魔獸3”這個玩意“確實有點難度”。

  目前本人入游戲領域不久,菜鳥一枚,歡迎游戲同行與我交流討論。



GameRes游資網 2015-08-23 08:40:38

[新一篇] 解構蘋果iPhone 6產品線對游戲產品之影響:高清的畫質,更長的拇指?

[舊一篇] 魔獸幕后故事:暴雪其實不想跟九城分手
回頂部
寫評論


評論集


暫無評論。

稱謂:

内容:

驗證:


返回列表