前言
我選擇開發(fā)一個游戲有很多原因。我覺得自己是“核心”玩家，過去的大部分時間我都花在玩游戲，自己制作、閱讀和游戲有關(guān)的項目上面。
編程，或更具體地說，游戲“改裝”，來源于21世紀(jì)初的反恐精英1.6。這一切都開始于我加入一個名為“SHMOD服務(wù)器20+英雄”的服務(wù)器，它讓我對超級英雄mod和編程感興趣。其次，這次項目的開發(fā)過程是一次有趣的和具有挑戰(zhàn)性的經(jīng)歷，因為我以前從來沒有用C++開發(fā)過大的工程。
芬蘭的游戲產(chǎn)業(yè)正在增長，并且已經(jīng)發(fā)展得相當(dāng)大，不僅僅是因為最近“憤怒的小鳥”的成功，還因為一些小公司，如Supercell的游戲制作【1】。
我對游戲開發(fā)領(lǐng)域的工作很感興趣，我認(rèn)為這將是一個不錯的學(xué)習(xí)機會。不管怎樣，這是一個在編程和游戲設(shè)計上都很好的學(xué)習(xí)經(jīng)歷。
縮略語表
IDE 綜合開發(fā)環(huán)境（Integrated development environment），比如Eclipse和
Microsoft Visual Studio
FPS 第一人稱射擊（first person shooter），以通過第一人稱視角看到的射彈型武
器為基礎(chǔ)的戰(zhàn)斗為中心的游戲。
RPG 角色扮演游戲（role playing game）
Goto 無條件地將控制轉(zhuǎn)移到由指定標(biāo)識符執(zhí)行的語句
HUD 作為游戲中用戶界面的一部分將信息可視地傳遞到玩家的方法（head-up
display）
1. 介紹
本論文的主題是用Cocos2D-X進行游戲項目開發(fā)。本論文涵蓋從游戲的想法到成品原型的整個過程。其中包括對Cocos2D-X的介紹，游戲設(shè)計，UI設(shè)計，但不限于上述主題。
本次研究與Linda Karlsson密切合作進行，她是 Novia應(yīng)用科學(xué)大學(xué)的平面設(shè)計專業(yè)的學(xué)生。她負(fù)責(zé)所有和游戲相關(guān)的想法，比如說繪畫（或者設(shè)計）人物、背景、敵人、UI等等。我負(fù)責(zé)游戲的設(shè)計和編程。我們共享觀點和反饋，為了達成關(guān)于游戲的不同組件的決定的協(xié)議，例如視覺外觀和游戲玩法。
本論文首先會介紹Cocos2D-X的基礎(chǔ)理論，然后把它和其他流行的框架進行對比。接著著手設(shè)計Project Cherry Brawl，研究與它相關(guān)的背景。最后介紹游戲開發(fā)的不同階段。
2. Cocos2D-X
Cocos2D-X【2】是iOS的Cocos2D引擎的C ++跨平臺端口。它是一個根據(jù)MIT許可的開源游戲引擎，使用它開發(fā)人員不僅可以開發(fā)游戲，還可以開發(fā)應(yīng)用和其他跨平臺GUI交互式程序，如動畫背景。
Cocos2D-x允許開發(fā)人員利用他們現(xiàn)有的C ++，Lua和Javascript知識, 從原型到高性能游戲（應(yīng)用程序）開發(fā)跨平臺游戲（應(yīng)用程序），從而節(jié)省時間和精力。
雖然Cocos2D-X在西方不像Unity3D那樣流行和出名，但在亞洲，它非常受歡迎，可以保持大哥Cocos2D的水準(zhǔn)，甚至因為其跨平臺的能力而超過Cocos2D【3】。
以下部分詳細討論Cocos2D-X的架構(gòu)，與Cocos2D-X兼容的工具，并將Cocos2D-X與其他框架進行比較。
2.1 架構(gòu)
Cocos2D-X的架構(gòu)可以分為三個主要層，每個主要層包含子層。這三個主要層包括游戲/應(yīng)用程序，Cocos2D-X提供的組件和它分別運行的平臺，如下圖1所示。
綠色圖層代表游戲?qū)樱怯螒蜷_發(fā)者創(chuàng)建的。橙色圖層代表了Cocos2D-X提供的所有功能，并讓開發(fā)者構(gòu)建自己的產(chǎn)品，最后棕色層代表游戲和Cocos2D-X將運行的平臺。本章簡要解釋了Cocos2D-X最常用的功能。
導(dǎo)演或CCDirector負(fù)責(zé)在項目中創(chuàng)建的所有場景。CCDirector是一個共享的單例對象，這意味著它只有一個實例在運行。它知道哪個場景當(dāng)前是活動的，并處理一堆場景以允許各種場景調(diào)用，例如暫停，將場景保持而另一個進入，然后返回到原始場景。簡而言之，場景的推送，彈出，替換和終止是由導(dǎo)演發(fā)出的。當(dāng)一個新的場景推入堆棧時，Director暫停前一場景，但將其保留在內(nèi)存中。 稍后當(dāng)頂部場景從堆棧彈出時，暫停的場景從其最后狀態(tài)恢復(fù)。
CCNode是Cocos2D中的主要元素，Cocos2D中幾乎所有的東西都繼承自CCNode，其中最流行的有CCScene, CCLayer, CCSprite和CCMenu，在這里簡要介紹它們，在第三章會進一步詳細討論。CCNode的主要特征是它可以包含其他CCNode，它可以調(diào)度周期性回調(diào)（調(diào)度，非調(diào)度等），并且它可以執(zhí)行動作。
Cocos2D或CCScene中的場景是應(yīng)用程序工作流程的獨立部分，基本上是“階段”，“級別”或電影中的一個場景。它是之前說過的CCNode的一個子類。游戲中可以有很多場景，但一次只能有一個場景處于活躍狀態(tài)。下面的圖2說明了CCScene的類圖。
Cocos2D-X中的一個層稱為CCLayer，它是一個CCNode，它知道如何處理觸摸事件，繪制自己和添加到它的孩子。 圖層最常用于定義游戲的外觀和行為。
Cocos2D-X中的sprite，通常稱為CCSprite，像任何其他計算機sprite一樣。 它是一個2D圖像，可以移動，旋轉(zhuǎn)，縮放，動畫等。CCSprite可以把其他sprite作為孩子，這意味著當(dāng)父節(jié)點變換時，子節(jié)點也會跟著變換。
CCAction是給予CCNode對象的命令。 這些操作可用于修改對象的屬性，如位置，縮放，旋轉(zhuǎn)等。第3章會進一步詳細介紹操作。
2.2 工具
本章簡要介紹了與Cocos2D-X兼容并且在社區(qū)中廣泛使用的工具。這些工具提供給用戶一種簡單的方式來處理不同的任務(wù)，例如打包textures，創(chuàng)建映射或有效管理復(fù)雜數(shù)據(jù)。 這些工具包括第三方程序。
Tiled Map Editor是一個通用的tilemap編輯器【6】。 它是一個免費的工具，允許輕松地創(chuàng)建地圖布局。 它是非常通用的，并允許用戶指定更多的抽象的東西，如碰撞區(qū)域和對象產(chǎn)生點。 它以TMX格式【7】保存此數(shù)據(jù)。
TexturePacker為用戶提供了一個GUI和一個命令行工具來創(chuàng)建精靈表或精靈圖集。 它是非常多才多藝，并與眾多的游戲引擎，如Cocos2D-X和Unity工作。 TexturePacker能產(chǎn)生很好的結(jié)果，同時具有很大的可調(diào)性【8】。
2.2.1 CocoStudio
CocoStudio【9】是CocosBuilder的對應(yīng)版本，兩者都是游戲開發(fā)工具包。
CocoStudio旨在將游戲開發(fā)中的任務(wù)分解為幾個不需要用戶知道如何編程的角色。這些角色包括：用于動畫和圖形藝術(shù)家的動畫編輯器，用于UI圖形藝術(shù)家的UI編輯器，用于游戲設(shè)計者的場景編輯器和用于游戲設(shè)計者的數(shù)據(jù)編輯器。 圖3顯示了如何在CocoStudio中處理角色動畫。
動畫編輯器將骨骼動畫帶到Cocos2D-X。 與傳統(tǒng)幀動畫相比，骨架動畫提供了更低的內(nèi)存消耗，更小的文本大小，把動畫混合在一起，并重用動畫。 然而，骨骼動畫有限制，例如它不能創(chuàng)建爆炸或等長字符。
2.3 比較
這是符合Project Cherry Brawl標(biāo)準(zhǔn)的游戲引擎之間的一個簡短的比較。 游戲引擎的主要區(qū)別如下。 下面的圖4中的代表提供了本論文作者的個人意見。
LibGDX【10】是一個Java游戲開發(fā)框架，提供了一個統(tǒng)一的API，可以在所有支持的平臺上工作。 LibGDX框架為快速原型設(shè)計和快速迭代提供了一個環(huán)境。
Unity3D【11】是一個完整的游戲開發(fā)IDE，它帶有一個強大的渲染引擎，完全集成了一組直觀的工具，更容易創(chuàng)建3D / 2D內(nèi)容和輕松的多平臺發(fā)布。 它還配備了自己的資產(chǎn)商店，用戶可以下載或購買由非常大的社區(qū)創(chuàng)建的資產(chǎn)。
Unity2D 【12】是Unity的一個新增加，使開發(fā)人員更容易開發(fā)2D游戲。 它有很多新的特性，對于2D開發(fā)是必不可少的，如一個新的資產(chǎn)類型被稱為精靈，sprite包裝（專業(yè)版），動畫窗口等等【13】。
Cocos2D-X和LibGDX是免費和開源的，而Unity給開發(fā)者在免費版和專業(yè)版之間的選擇。 Cocos2D-X面向2D，而Unity和LibGDX有很大的2D支持，但更側(cè)重于3D。 所有三個競爭者都有非常好的文檔，它們在stackoverflow標(biāo)簽流行度搜索中顯示非常高，如圖5所示。
Cocos2D-X和LibGDX提供了一個非常容易訪問和靈活的UI實現(xiàn)，Unity則沒有，與前兩個相比非常有限。 Cocos2D-X，Unity和LibGDX提供了極好的跨平臺適應(yīng)性，并具有非常相似的開發(fā)周期。 Cocos2D-X的主要編程語言是C ++，也支持使用Javascript和Lua的腳本，LibGDX使用Java，Unity支持C＃，Javascript和Boo中的腳本。
Cocos2D-X和LibGDX背后有一個龐大的社區(qū)和大量的用戶生成的教程和第三方加載項，而Unity有它的資源商店。 這些功能迅速縮短開發(fā)時間，并使圖形藝術(shù)家和游戲設(shè)計師可以從可下載的模板創(chuàng)建游戲。
3. Project Cherry Brawl
Project Cherry Brawl是一款動作游戲。 通常這種動作游戲是主角（Cherry Lyn）和大量的能力低下的敵人之間的近身作戰(zhàn)。 游戲的運行方式和大多數(shù)的動作游戲一樣，玩家向前移動（向右），與敵人戰(zhàn)斗，擊敗他們，最后擊敗boss完成關(guān)卡。 游戲通過詳細闡述它的背景故事將玩家置于正確的心態(tài)。
Cherry Lyn，一個有著超能力的女孩，因為感冒而從學(xué)校回家了一個星期。當(dāng)Cherry Lyn回到學(xué)校時，事情變得有些不太對勁。在她請假的時候，學(xué)校的科學(xué)俱樂部開發(fā)了一臺可以用作耳機的電腦。 在耳機的幫助下，學(xué)校的學(xué)生將變得更有效率，所以校長允許生產(chǎn)這樣的耳機。沒有人知道的是，在耳機生產(chǎn)之前，科學(xué)俱樂部對它進行了改變。他們增加了一個額外的功能，來洗腦學(xué)生，從而控制學(xué)校。Cherry Lyn現(xiàn)在必須從科學(xué)俱樂部的控制中解放學(xué)校的其他學(xué)生。
3.1 背景研究
自從游戲機和諸如任天堂娛樂系統(tǒng)之類的舊游戲機開始運行以來，動作游戲就一直存在。 必須完成的研究是關(guān)于如何在手持設(shè)備上正確地模擬一個動作游戲。 研究分為兩個不同的類別，第一個是如何正確使用移動設(shè)備屏幕和適合游戲的所有組件。 第二類是如何在移動設(shè)備上模擬控制器。
第一步是在谷歌Play商店中，嘗試盡可能多的被標(biāo)記為動作、格斗類型的游戲。 注意到所有測試的游戲都有一些共同的關(guān)鍵因素。 每個游戲都是橫向模式，給玩家一個更廣泛的視野。 如果手機處于縱向模式，它會縮小播放器的視野，并不適合于一個動作類型的游戲。
如圖6所示，大多數(shù)移動抓取游戲都有非常雜亂的屏幕。 這意味著當(dāng)玩家將他的拇指放在屏幕上時，它將使玩家的視野重新減少大約40％。 另外，在屏幕上具有其他用戶界面組件進一步減少了視野或者僅僅混淆了玩家。 另外，在屏幕的兩側(cè)周圍有按鈕會混淆玩家，因此它們將與背景混合。
圖7展出了之前說的關(guān)于玩家視野減小的情況。 玩家視野將受到玩家自己的手和UI組件以及背景的阻礙。 當(dāng)背景和敵人/ UI組件混合在一起時，可能發(fā)生進一步的混亂，使玩家不能區(qū)分它們，導(dǎo)致糟糕的游戲體驗。
在游戲中有不同類型的UI，通常分為四類。 分別是敘事，非敘述，空間和元。
包括在游戲世界中的界面是敘事的，即玩家的角色可以看到，聽到它。 比如任務(wù)指揮官的全息圖片，他解釋了玩家角色的使命。
非敘述意味著UI被呈現(xiàn)在游戲世界之外，并且僅對玩家本身而言是可見的或可聽見的，而不是角色。 比如Project Cherry Brawl的平視顯示器。
空間UI元素在游戲世界中呈現(xiàn)，但不必是游戲世界中的實體。 比如當(dāng)玩家的光標(biāo)懸停在任何物品或敵人上時，該物品將得到不同的輪廓。
元表示可以存在于游戲世界中，但不被歸類為空間。 元表示的示例可以是玩家的相機上的血濺，以指示損害。 圖8反映了我以前的陳述。
Project Cherry Brawl 的UI主要屬于非敘述類，因為UI在游戲世界之外，角色不知道它存在。 有一個例外，即當(dāng)他們受到傷害時，出現(xiàn)在角色上方的數(shù)字。 這些數(shù)字屬于空間接口的類別，因為它們出現(xiàn)在游戲世界中，而人物仍然不知道數(shù)字【16】的存在。
在創(chuàng)建并測試了一個原型之后，其中Project Cherry Brawl的UI組件用Street Fight相同的方式顯示，我放棄了這個想法，因為玩家自己有時會用手阻擋屏幕的兩端。
當(dāng)前UI布局的想法來自希望盡可能清晰地向玩家顯示所有內(nèi)容。 在與Linda Karlsson會面之后，得出結(jié)論，UI如圖9所示。通過這種設(shè)計，玩家的信息顯示在他的前面，同時他的手在屏幕的每一側(cè)。 這不僅保持屏幕不混亂，而且給玩家更多的使用實際控制器的復(fù)古感覺。 此外，沒有一個UI元素將出現(xiàn)在實際的游戲玩法上，并且玩家不會如圖9和圖10所示的那樣阻止他自己的視線。
根據(jù)目前的設(shè)計，玩家失去了很少的活動空間，與之交換的是，角色和地圖略有縮小。 這樣玩家有更多的空間來玩，同時保持屏幕整潔，如圖10所示。
下一個問題是，游戲資產(chǎn)必須創(chuàng)建。 通常移動游戲必須提供不同的資產(chǎn)以支持多種寬高比。 這樣，同樣的游戲可以在流行的移動設(shè)備，如平板電腦和手機上享受。 由于資源和時間有限，項目必須關(guān)注某種類型的移動設(shè)備。 所選的寬高比為15：9，使游戲分辨率為480x800像素。 這樣，如果設(shè)備分辨率大于所選的480x800像素，設(shè)備將添加與上述類似的黑色邊框。 這是用Cocos2D-X[17]的多分辨率支持來實現(xiàn)的。
3.2 場景
本章進一步闡述了之前關(guān)于場景的說明，以及如何在Project Cherry Brawl中使用它們。 使用CCScene作為所有游戲不同CCNode的父級是一個很好的做法，如圖層。
在Project Cherry Brawl中有三種不同的場景，分別是初始場景，菜單場景和游戲場景。 它們用于包含不同的圖層和其他CCNodes，并對其進行排序。 在下面的章節(jié)中將簡要討論每個上述場景的創(chuàng)建過程。
Cocos2D-x和Cocos2D中init方法的區(qū)別在于Cocos2D-X中init方法返回一個布爾值，而在Cocos2D中它返回一個id。 現(xiàn)在做的是促進防御性編程。 以前，Cocos2D-X 【18】的開發(fā)人員編寫代碼來管理它的goto的清理：
define check(ret) if(!ret) goto cleanup;
void func() {
bool bRet = false;
bRet = doSomething();
check(bRet);
bRet = doSomethingElse();
check(bRet);
bRet = true;
cleanup:
// Do clean up here
return bRet;
}
代碼段1. 第一個版本的初始函數(shù)的實現(xiàn)
從上面的代碼可以發(fā)現(xiàn)，如果出現(xiàn)了任何錯誤，它將跳轉(zhuǎn)到函數(shù)結(jié)尾的清理功能。 每個對函數(shù)的調(diào)用都返回它是否成功。 然后，檢查宏用于查看bRet是否為true，如果不是，則直接跳轉(zhuǎn)到清除標(biāo)簽。 從技術(shù)上講，這沒有什么問題，但是他們遇到了一個問題，因為腳本語言沒有g(shù)oto指令。 這就是為什么它改為：
define CC_BREAK_IF(cond) if(!cond) break;
void func() {
bool bRet = false;
do {
bRet = doSomething();
CC BREAK IF (bRet);
bRet = doSomethingElse();
CC_BREAK_IF (bRet);
bRet = true;
} while (0)
// Do clean up here
return bRet;
}
代碼段2. 跨平臺的初始函數(shù)的實現(xiàn)
這有與以前完全相同的效果，但使用break作為goto機制跳到do while循環(huán)后的代碼。 盡管不可預(yù)見地使用所述軟件，但是一般來說，確保軟件的持續(xù)功能是良好的實踐。 這是因為Cocos2D-HTML5 / JS 【19】。
這可能略微偏離了主題的場景，但它是場景的一個必不可少的部分，必須詳細闡述。 為了防止出現(xiàn)不可預(yù)見的錯誤和錯誤，每個CCNode應(yīng)該以上述方式初始化。
3.2.1 初始場景
初始場景是打開任何程序/游戲時大多數(shù)時間看到的。 它顯示信用，公司名稱等，例如當(dāng)啟動windows時，會顯示W(wǎng)indows問候窗口，接著是登錄屏幕。
初始場景是Project Cherry Brawl的第一個組成部分，因為它充當(dāng)?shù)氖且粋€歡迎的部分。 在這個場景中，將加載一個標(biāo)志，顯示它，并在一定的時間后，調(diào)用director，切換到菜單場景。
上訴步驟按照以下順序完成。 初始化Splash圖層后，繼續(xù)創(chuàng)建CCScene，并將上述Splash圖層作為子級添加到它。 添加Splash圖層后，調(diào)用CCDirector更改場景不是最佳解決方案，因為這會立即更改場景。 我們期望的結(jié)果是讓Splash屏幕保持足夠長的時間，以便玩家讀取標(biāo)志，然后改變場景，如代碼段3中所示。
CCCallFunc* changeScene = CCCallFunc::create (this, cal-func_selector (SplashScene::DisplayScene));
CCDelayTime* delayAction = CCDelayTime::create (2.0f);
this->runAction (CCSequence::create(delayAction, changeScene, NULL));
代碼段 3. 在Project Cherry Brawl初始場景中更換場景的操作
此外，通過給Splash層一個CCAction，可以給予所有CCNode對象，使用delayAction實現(xiàn)所需的效果，使得動作在延遲兩秒后運行。
3.2.2 菜單場景
不像其他具有復(fù)雜菜單系統(tǒng)的游戲，這款游戲的菜單場景非常簡單。 菜單場景有兩個按鈕，它們將顯示Project Cherry Brawl的控件或切換場景到游戲場景。 用Splash場景相同的方式創(chuàng)建菜單場景被證明是有問題的。 問題在于，一些孩子CCNodes，如粒子效果和標(biāo)志，會以我們不希望的方式重疊。
圖11顯示了完成的菜單場景，演示了子節(jié)點的排序。
該問題通過將所有菜單的組件作為子節(jié)點添加到菜單場景中來解決。 這樣，孩子的顯示順序可以重新排序。 值越高，特定節(jié)點高于其他節(jié)點的越多。
3.2.3 游戲場景
這是整個游戲進行的主要場景。 創(chuàng)建的方法類似于前兩個場景。 與之前的初始場景和菜單場景不同，游戲場景中有很多子節(jié)點，用一層管理它不是一個選擇。 從長遠來看，它會導(dǎo)致代碼變得非常混亂，難以理解，最重要的是它將很難維護。
因此，需要創(chuàng)建單獨的層以包含更多的游戲?qū)ο螅T如HUD對象或游戲?qū)ο蟆?創(chuàng)建HUD層和游戲?qū)邮怯螒虻囊粋€重要組成部分。 HUD層將處理與UI相關(guān)的一切，而游戲?qū)泳S護與實際游戲世界相關(guān)的一切。 在下一章中進一步闡述了兩個層。
3.3 圖層
CCLayers是保持代碼清晰和容易理解，同時定義你的游戲外觀的必要條件。 圖層是CCNode類的子類，因此它們可能包含圖像，動畫，標(biāo)簽，按鈕，sprite等。關(guān)于圖層的定義因素是它們實現(xiàn)TouchEventsDelegate協(xié)議，這意味著玩家可以與觸摸事件 進行交互，如敲擊，滑動，保持和移動。
Project Cherry Brawl利用三個不同層的實現(xiàn)，每個層代表游戲的一個組成部分，如圖12所示。
HUD，游戲和D-Pad層完整的構(gòu)建以及如何放置它們可以在上圖中看到。 此外，它顯示了即使只有兩個主要層，也可以在一款游戲中有很多視覺深度。 藍色和綠色層代表游戲?qū)樱t色代表HUD層，黃色代表D-Pad層，更多的細節(jié)在下面的章節(jié)中闡述。
3.3.1 HUD圖層
在設(shè)計HUD布局時，必須考慮以下因素： 輕松訪問的玩家的技能按鈕，回到菜單場景按鈕和對話部分點擊繼續(xù)按鈕， 玩家和敵人名稱標(biāo)簽的圖標(biāo)，以及他們的肖像紋理。 動態(tài)處理游戲的對話狀態(tài)，意味著隱藏和顯示HUD層的特定子節(jié)點。 玩家健康條和能量條，并處理其更新。
因為HUD嚴(yán)重依賴于游戲?qū)樱越鉀Q方案是在HUD層中創(chuàng)建子節(jié)點，并根據(jù)它們的依賴關(guān)系初始化它們。 初始化HUD層中的用戶技能按鈕將使我創(chuàng)建游戲?qū)訉ο蟮膮⒖迹⑵鋫鬟f給HUD層。 這樣做的話，代碼將變得很難解釋，非常混亂。
在HUD層中初始化對象，例如對話框，命中點的背景，命中點的邊界，游戲?qū)υ捄兔Q標(biāo)簽以及D-Pad層。 而退出按鈕，玩家按鈕，玩家健康和能量條在游戲?qū)又谐跏蓟⒆鳛楹⒆犹砑拥紿UD層。 這樣，只有一個HUD層對象的引用必須傳遞給游戲?qū)印?這提供了從游戲?qū)虞p松訪問所有HUD層組件。 圖13分別示出了命中點的背景，命中點和命中點的邊界的順序。
對話狀態(tài)也在HUD層中處理。 通過創(chuàng)建兩個叫dialogModeOn和dialogueModeOff的函數(shù)，子節(jié)點可以動態(tài)設(shè)置不可見并回到可見。 玩家和敵人的對話圖片和名稱標(biāo)簽也在HUD層中處理。 當(dāng)調(diào)用dialogMode時，可以讓想要看到的的人談話，例如讓主角談話，此時會調(diào)用：
_hud->cherryTalks (true, 1); // frames from 1-4
代碼段 4
這些參數(shù)分別用于設(shè)置子節(jié)點可見和圖像框架，對敵人也有類似的功能。
3.3.2 游戲圖層
設(shè)計游戲?qū)邮潜卷椖恐蓄H具挑戰(zhàn)性的部分之一。 即使一切都在游戲場景內(nèi)播放，游戲?qū)颖仨毺幚碛螒虻乃羞壿嫞巧\動，瓷磚地圖和游戲效果。 以下功能必須存在于游戲圖層中：
游戲的循環(huán)和所有游戲?qū)ο蠛鸵恍〩UD層對象的初始化。 它必須處理加載瓷磚地圖和管理剪切的場景和對話。 顯示和更新所有子節(jié)點，如玩家的角色，敵人和HUD層組件，如玩家的角色健康狀態(tài)。 處理D-Pad上的玩家輸入，重新排序所有的孩子演員精靈位置，并更新玩家視點。 所以游戲?qū)涌梢员徽J(rèn)為是這個游戲的核心。 它擁有一切，并處理對象之間的交互。
幸運的是，CCLayer節(jié)點支持scheduleUpdate，它將一個調(diào)度更新添加到圖層。 通過重寫它將會提供的更新（deltaTime）函數(shù)，可以創(chuàng)建一個游戲循環(huán)。 從編程的角度來看，游戲循環(huán)[20]是游戲的中心組成部分。 它允許游戲保持運行，而不管是否有任何用戶輸入。
使用TexturePacker幫助保持Project Cherry Brawl的所有資產(chǎn)，并重新創(chuàng)建他們將使用的空間。 從圖14中可以看出，即使這樣的小游戲原型通常也可以具有許多紋理和資產(chǎn)。 通過將所有資產(chǎn)壓縮成一個圖片，可以實現(xiàn)批量節(jié)點的使用。
將所有資源添加到TexturePacker后，創(chuàng)建了一個sprite表。一旦加載了在共享精靈幀緩存中可用的資源，不僅會加快游戲加載紋理的時間，而且它也是使用CCSpriteBatchNode的一個重要部分。
在Project Cherry Brawl的早期迭代中，諸如玩家角色，敵人等游戲?qū)ο笞鳛楹⒆颖惶砑拥接螒驅(qū)印＿@使得代碼很難維護和更新。此外，即使在屏幕上一次只有十個敵人，游戲也會表現(xiàn)不佳。
批處理節(jié)點提供的是，如果它包含子節(jié)點，它將在一個單獨的OpenGL調(diào)用中繪制它們。這通常被稱為“分批抽取”。在沒有批處理節(jié)點的情況下，OpenGL繪制調(diào)用將被調(diào)用的次數(shù)與孩子的次數(shù)一樣多，如玩家角色和敵人這樣的sprite。
一個CCSpriteBatchNode只能引用一個紋理，圖像文件，紋理圖集或一個精靈表。將所有actor sprite添加到CCSpriteBatchNode中可以大大提高游戲的性能，即使在游戲可能提供給手機的最大可能壓力下，也可以給玩家所需的幀數(shù)。
首先重新排序精靈很難掌握。 在早期迭代的一個版本中，精靈設(shè)置了z值，這看起來非常不現(xiàn)實，如圖15所示。
該問題的另一迭代根據(jù)每個actor sprite在創(chuàng)建時的位置來設(shè)置它們的z值，但是產(chǎn)生了一樣的不想要的結(jié)果。 因為每個單獨的actor sprite是CCSpriteBatchNode的子節(jié)點，所以子節(jié)點的動態(tài)重定向是可能的，如在代碼段5中可以看到的。結(jié)果可以在圖16中看到。
CCObject *pObject = NULL;
CCARRAY_FOREACH (_actorsAtlas->getChildren (), pObject)
{
ActorSprite *sprite = (ActorSprite*) pObject;
_actorsAtlas->reorderChild (sprite, (_tileMap->getMapSize ().height * _tileMap->getTileSize ().height) - sprite->getPosition ().y);
}
代碼段 5. Project Cherry Brawl中的重新排序子函數(shù)
從0.8.1版本開始，Cocos2D-X提供了CCTMXTiledMap，它是一個知道如何解析和渲染TMX映射的CCNode。 在渲染每個圖塊時，它們將被創(chuàng)建為CCSprites。 這意味著每個圖塊可以隨意旋轉(zhuǎn)，移動，縮放，著色等。 由于瓦片地圖是從瓦片圖像創(chuàng)建的，因此它將被加載到自己的CCTextureCache中，從而加速加載時間和性能。 tilemap的每一層將使用CCTMXLayer CCSpriteBatchNode的子類創(chuàng)建。 通過在Tiled中創(chuàng)建tilemap，可以使用CCT-MXTiledMap節(jié)點輕松實現(xiàn)地圖的解析。
游戲地圖是在Tiled中創(chuàng)建的，使用兩層，墻壁和地板層。 就像Cocos2D-X中的圖層一樣，圖層中的圖層為用戶提供了在對象的頂部繪制對象的能力，使地圖具有深度感，如圖17所示。
如圖17所示，所有的墻磚被繪制在墻層上。 在圖18中，創(chuàng)建了游戲的地板組件。 因為該層在壁層下面，所以添加到地板層中的任何物質(zhì)都將在壁層下面。
![圖 18. Project Cherry Brawl中Tiled和地板的演示層].](http://upload-images.jianshu.io/upload_images/4086459-5c4fddc1eecd7f37.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
在規(guī)劃Project Cherry Brawl時，我的意圖是把它看做一個原型。它將展示游戲的核心力量。原型設(shè)計大約需要一到三分鐘的游戲時間來完成。進入項目的后期后，游戲的氣氛似乎相當(dāng)沉悶。Cherry Lyn沒有了戰(zhàn)斗的欲望，因此產(chǎn)生了為游戲創(chuàng)建故事前傳的需要。游戲的故事是通過在游戲中的戰(zhàn)斗或檢查點之間的小剪輯場景中進行的。
決定添加剪輯場景后，我為游戲創(chuàng)建了兩個狀態(tài)。對話狀態(tài)意味著敵人，玩家和老板會有腳本化的動作，而不是玩家控制輸入。運行狀態(tài)意味著敵人將根據(jù)他們的AI移動，玩家角色將基于玩家的輸入移動。
處理不同的剪切場景很棘手，但是當(dāng)游戲處于對話狀態(tài)時，在檢查點的幫助下，剪切的場景將無縫地從一個轉(zhuǎn)換到另一個。圖19展示了Cherry Lyn和敵人咕嚕之間游戲?qū)υ挼霓D(zhuǎn)換。
設(shè)置視點的中心被證明是自己的問題。 嘗試不同的方法來解決這個問題，最佳的方法似乎如下：
通過確定玩家角色的當(dāng)前位置，并將它與屏幕的寬度用MAX宏除以2進行比較，返回兩個上述變量之間的較大值。 可以使用上述值，并使用MIN宏將其映射到tilemaps寬度減去屏幕寬度除以2，該宏返回兩個變量中較小的值。 對視點的高度進行相同的過程。 使用ccpSub宏，它將減去屏幕中心和先前計算的變量x中的點，如代碼段6中所示。
int x = MAX(position.x, SCREEN.width / 2);
int y = MAX(position.y, SCREEN.height / 2);
x = MIN(x, (_tileMap->getMapSize ().width * _tileMap->getTileSize ().width) - SCREEN.width / 2);
y = MIN(y, (_tileMap->getMapSize ().height * _tileMap->getTileSize ().height) - SCREEN.height / 2);
CCPoint actualPosition = ccp(x, y);
CCPoint centerOfView = ccp (SCREEN.width / 2, SCREEN.height / 2);
CCPoint viewPoint = ccpSub (centerOfView, actualPosition);
this->setPosition(viewPoint);
代碼段 6. 相機位置更新
這樣，游戲的視角不會在HUD布局下，并且相機將跟隨玩家。
4. 討論和結(jié)論
在這篇論文中，Linda Karlsson和作者創(chuàng)建了一個游戲，從一開始到可以上架到Google Play商店，讓人們嘗試。在這個項目的過程中，面臨很多困難，因為這是一件以前沒有做過，沒有任何經(jīng)驗的工作。
當(dāng)用Cocos2D-X開發(fā)Project Cherry Brawl時，v2.2.3是Cocos2D-X最穩(wěn)定的版本。在游戲開發(fā)兩個月后，Co-cos2D-X團隊發(fā)布了v3.0的Cocos2D-X和更新的功能【21】，這是對以前版本的一個重大更新。不幸的是，由于這個項目的時間約束，有必要堅持使用v2.2.3。
在Project Cherry Brawl運行時，會出現(xiàn)隨機崩潰的情況。當(dāng)Eclipse被用作主要的IDE時，它給出的錯誤堆棧跟蹤是不可讀的，唯一的解釋是它與內(nèi)存分配有關(guān)。這就是為什么選擇繼續(xù)使用Visual Studio 2012開發(fā)的原因。使用Visual Studio，可以調(diào)試項目并擺脫隨機崩潰事件。 Cocos2D-X提供了關(guān)于游戲引擎如何工作及其工作流程的觀察。該信息可以被攜帶到諸如Unity或LibGDX的其他游戲引擎中。
Project Cherry Brawl的創(chuàng)造過程中是一個寶貴的經(jīng)驗，但這個項目可能做成不同的樣子。它試圖模仿使用一個控制器，在手機上玩一個控制臺游戲的感覺。但這已經(jīng)被證明了很多次，在移動設(shè)備上似乎并沒有很好的奏效。手機觸摸和手勢功能沒有被利用，但這是創(chuàng)作者的個人喜好，因為它的目的是模仿老式的游戲與控制器的游戲。
我不確定Project Cherry Brawl是否應(yīng)該在幾個Android市場（如Google Play Store和SlideMe [32]）上發(fā)布后繼續(xù)運行，但是在游戲結(jié)束一周后，我們的團隊收到了很多正面反饋。起初，教學(xué)者只教導(dǎo)游戲在控制臺或電腦平臺上運行，但很明顯，移動平臺上也存在需求。它在PC上運行得非常好，因為有一個鍵盤和鼠標(biāo)工作。因此，Project Cherry Brawl的開發(fā)者決定繼續(xù)為Android平臺開發(fā)，并最終擴展到其他移動設(shè)備，如iOS和Windows Phone。此外，由于最近發(fā)布的Cocos2D-X 3.0及其對C ++ 11和OpenGL 2.0的支持，該游戲?qū)⒃诘投嗽O(shè)備上表現(xiàn)更好，為玩家提供更流暢的體驗。
參考
1 http://yle.fi/uutiset/suurmenestys_supercellin_toimitusjohtaja_kaikki_lahtee_tekijatiimista/6584310 , 1.1.2014.
2 http://www.cocos2d-x.org/ , 5.1.2014.
3 http://www.cocos2d-x.org/wiki/Cocos2d-x , 7.1.2014.
4 http://www.cocos2d-x.org/wiki/Engine_Architecture, 3.2.2014.
5 http://www.cocos2d-x.org/reference/native-cpp/V2.2/d1/da4/classcocos2d_1_1_c_c_scene.html#ae3c0dadfbfae64c9dd1d5d9a6bec3d42, 3.3.2014.
6 http://www.mapeditor.org/, 4.3.2014.
7 https://github.com/bjorn/tiled/wiki/TMX-Map-Format, 15.4.2014.
8 http://www.codeandweb.com/texturepacker, 15.4.2014.
9 http://www.cocos2d-x.org/docs/tutorial/parkour-game-with-cocostudio/chapter1/en, 2.2.2014.
10 http://libgdx.badlogicgames.com/, 15.4.2014.
11 https://unity3d.com/, 15.4.2014.
12 http://unity3d.com/pages/2d-power?gclid=CLvjgp-j470CFasLcwodUp0A9g, 15.4.2014.
13 http://unity3d.com/unity/whats-new/unity-4.3, 15.4.2014.
14 http://www.learn-cocos2d.com/2013/11/mobile-game-engine-popularity-index/, 15.4.2014.
15 https://play.google.com/store/apps/details?id=com.letang.game103pp.cn, 22.3.2014.
16 http://www.gamasutra.com/view/feature/132674/game_ui_discoveries_what_players_.php, 16.1.2014
17 http://www.cocos2d-x.org/wiki/Multi_resolution_support, 3.1.2014.
18 http://www.cocos2d-x.org/forums/6/topics/16774, 4.3.2014.
19 http://www.cocos2d-x.org/wiki/Cocos2d-JS, 12.4.2014.
20 http://entropyinteractive.com/2011/02/game-engine-design-the-game-loop/, 16.4.2014.
21 http://slideme.org/ 1.5.2014.
