前言

我選擇開發(fā)一個(gè)游戲有很多原因崔泵。我覺得自己是“核心”玩家，過去的大部分時(shí)間我都花在玩游戲猪瞬，自己制作憎瘸、閱讀和游戲有關(guān)的項(xiàng)目上面。
　　編程陈瘦，或更具體地說幌甘，游戲“改裝”，來源于21世紀(jì)初的反恐精英1.6痊项。這一切都開始于我加入一個(gè)名為“SHMOD服務(wù)器20+英雄”的服務(wù)器锅风，它讓我對(duì)超級(jí)英雄mod和編程感興趣。其次鞍泉，這次項(xiàng)目的開發(fā)過程是一次有趣的和具有挑戰(zhàn)性的經(jīng)歷皱埠，因?yàn)槲乙郧皬膩頉]有用C++開發(fā)過大的工程。
　　芬蘭的游戲產(chǎn)業(yè)正在增長(zhǎng)咖驮，并且已經(jīng)發(fā)展得相當(dāng)大边器，不僅僅是因?yàn)樽罱皯嵟男▲B”的成功，還因?yàn)橐恍┬」就行蓿鏢upercell的游戲制作【1】忘巧。
　　我對(duì)游戲開發(fā)領(lǐng)域的工作很感興趣，我認(rèn)為這將是一個(gè)不錯(cuò)的學(xué)習(xí)機(jī)會(huì)睦刃。不管怎樣砚嘴，這是一個(gè)在編程和游戲設(shè)計(jì)上都很好的學(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)識(shí)符執(zhí)行的語句
HUD 作為游戲中用戶界面的一部分將信息可視地傳遞到玩家的方法（head-up
display）

1. 介紹

本論文的主題是用Cocos2D-X進(jìn)行游戲項(xiàng)目開發(fā)吃环。本論文涵蓋從游戲的想法到成品原型的整個(gè)過程也颤。其中包括對(duì)Cocos2D-X的介紹，游戲設(shè)計(jì)郁轻，UI設(shè)計(jì)翅娶，但不限于上述主題文留。
　　本次研究與Linda Karlsson密切合作進(jìn)行，她是 Novia應(yīng)用科學(xué)大學(xué)的平面設(shè)計(jì)專業(yè)的學(xué)生竭沫。她負(fù)責(zé)所有和游戲相關(guān)的想法燥翅，比如說繪畫（或者設(shè)計(jì)）人物、背景蜕提、敵人森书、UI等等。我負(fù)責(zé)游戲的設(shè)計(jì)和編程谎势。我們共享觀點(diǎn)和反饋凛膏，為了達(dá)成關(guān)于游戲的不同組件的決定的協(xié)議，例如視覺外觀和游戲玩法脏榆。
　　本論文首先會(huì)介紹Cocos2D-X的基礎(chǔ)理論猖毫，然后把它和其他流行的框架進(jìn)行對(duì)比。接著著手設(shè)計(jì)Project Cherry Brawl须喂，研究與它相關(guān)的背景吁断。最后介紹游戲開發(fā)的不同階段。

2. Cocos2D-X

Cocos2D-X【2】是iOS的Cocos2D引擎的C ++跨平臺(tái)端口坞生。它是一個(gè)根據(jù)MIT許可的開源游戲引擎仔役，使用它開發(fā)人員不僅可以開發(fā)游戲，還可以開發(fā)應(yīng)用和其他跨平臺(tái)GUI交互式程序是己，如動(dòng)畫背景又兵。
　　Cocos2D-x允許開發(fā)人員利用他們現(xiàn)有的C ++，Lua和Javascript知識(shí), 從原型到高性能游戲（應(yīng)用程序）開發(fā)跨平臺(tái)游戲（應(yīng)用程序）赃泡，從而節(jié)省時(shí)間和精力。
　　雖然Cocos2D-X在西方不像Unity3D那樣流行和出名乘盼，但在亞洲升熊，它非常受歡迎，可以保持大哥Cocos2D的水準(zhǔn)绸栅，甚至因?yàn)槠淇缙脚_(tái)的能力而超過Cocos2D【3】级野。
以下部分詳細(xì)討論Cocos2D-X的架構(gòu)，與Cocos2D-X兼容的工具粹胯，并將Cocos2D-X與其他框架進(jìn)行比較蓖柔。

2.1 架構(gòu)

Cocos2D-X的架構(gòu)可以分為三個(gè)主要層，每個(gè)主要層包含子層风纠。這三個(gè)主要層包括游戲/應(yīng)用程序况鸣，Cocos2D-X提供的組件和它分別運(yùn)行的平臺(tái)，如下圖1所示竹观。

圖 1. Cocos2D-X的架構(gòu)【4】

綠色圖層代表游戲?qū)痈渑酰怯螒蜷_發(fā)者創(chuàng)建的潜索。橙色圖層代表了Cocos2D-X提供的所有功能，并讓開發(fā)者構(gòu)建自己的產(chǎn)品懂酱，最后棕色層代表游戲和Cocos2D-X將運(yùn)行的平臺(tái)竹习。本章簡(jiǎn)要解釋了Cocos2D-X最常用的功能。
　　導(dǎo)演或CCDirector負(fù)責(zé)在項(xiàng)目中創(chuàng)建的所有場(chǎng)景列牺。CCDirector是一個(gè)共享的單例對(duì)象整陌，這意味著它只有一個(gè)實(shí)例在運(yùn)行。它知道哪個(gè)場(chǎng)景當(dāng)前是活動(dòng)的瞎领，并處理一堆場(chǎng)景以允許各種場(chǎng)景調(diào)用泌辫，例如暫停，將場(chǎng)景保持而另一個(gè)進(jìn)入默刚，然后返回到原始場(chǎng)景甥郑。簡(jiǎn)而言之，場(chǎng)景的推送荤西，彈出澜搅，替換和終止是由導(dǎo)演發(fā)出的。當(dāng)一個(gè)新的場(chǎng)景推入堆棧時(shí)邪锌，Director暫停前一場(chǎng)景勉躺，但將其保留在內(nèi)存中。 稍后當(dāng)頂部場(chǎng)景從堆棧彈出時(shí)觅丰，暫停的場(chǎng)景從其最后狀態(tài)恢復(fù)饵溅。
　　CCNode是Cocos2D中的主要元素，Cocos2D中幾乎所有的東西都繼承自CCNode妇萄，其中最流行的有CCScene, CCLayer, CCSprite和CCMenu蜕企，在這里簡(jiǎn)要介紹它們，在第三章會(huì)進(jìn)一步詳細(xì)討論冠句。CCNode的主要特征是它可以包含其他CCNode轻掩，它可以調(diào)度周期性回調(diào)（調(diào)度，非調(diào)度等）懦底，并且它可以執(zhí)行動(dòng)作唇牧。
　　Cocos2D或CCScene中的場(chǎng)景是應(yīng)用程序工作流程的獨(dú)立部分，基本上是“階段”聚唐，“級(jí)別”或電影中的一個(gè)場(chǎng)景丐重。它是之前說過的CCNode的一個(gè)子類。游戲中可以有很多場(chǎng)景杆查，但一次只能有一個(gè)場(chǎng)景處于活躍狀態(tài)扮惦。下面的圖2說明了CCScene的類圖。

圖 2. CCScene類圖 【5】.

Cocos2D-X中的一個(gè)層稱為CCLayer亲桦，它是一個(gè)CCNode径缅，它知道如何處理觸摸事件掺栅，繪制自己和添加到它的孩子。 圖層最常用于定義游戲的外觀和行為纳猪。
　　Cocos2D-X中的sprite氧卧，通常稱為CCSprite，像任何其他計(jì)算機(jī)sprite一樣氏堤。 它是一個(gè)2D圖像沙绝，可以移動(dòng)，旋轉(zhuǎn)鼠锈，縮放闪檬，動(dòng)畫等。CCSprite可以把其他sprite作為孩子购笆，這意味著當(dāng)父節(jié)點(diǎn)變換時(shí)粗悯，子節(jié)點(diǎn)也會(huì)跟著變換。
　　CCAction是給予CCNode對(duì)象的命令同欠。 這些操作可用于修改對(duì)象的屬性样傍，如位置，縮放铺遂，旋轉(zhuǎn)等衫哥。第3章會(huì)進(jìn)一步詳細(xì)介紹操作。

2.2 工具

本章簡(jiǎn)要介紹了與Cocos2D-X兼容并且在社區(qū)中廣泛使用的工具襟锐。這些工具提供給用戶一種簡(jiǎn)單的方式來處理不同的任務(wù)撤逢，例如打包textures，創(chuàng)建映射或有效管理復(fù)雜數(shù)據(jù)粮坞。 這些工具包括第三方程序蚊荣。
　　Tiled Map Editor是一個(gè)通用的tilemap編輯器【6】。 它是一個(gè)免費(fèi)的工具莫杈，允許輕松地創(chuàng)建地圖布局互例。 它是非常通用的，并允許用戶指定更多的抽象的東西姓迅，如碰撞區(qū)域和對(duì)象產(chǎn)生點(diǎn)敲霍。 它以TMX格式【7】保存此數(shù)據(jù)俊马。
　　TexturePacker為用戶提供了一個(gè)GUI和一個(gè)命令行工具來創(chuàng)建精靈表或精靈圖集丁存。 它是非常多才多藝，并與眾多的游戲引擎柴我，如Cocos2D-X和Unity工作解寝。 TexturePacker能產(chǎn)生很好的結(jié)果，同時(shí)具有很大的可調(diào)性【8】艘儒。

2.2.1 CocoStudio

CocoStudio【9】是CocosBuilder的對(duì)應(yīng)版本聋伦，兩者都是游戲開發(fā)工具包夫偶。
　　CocoStudio旨在將游戲開發(fā)中的任務(wù)分解為幾個(gè)不需要用戶知道如何編程的角色。這些角色包括：用于動(dòng)畫和圖形藝術(shù)家的動(dòng)畫編輯器觉增，用于UI圖形藝術(shù)家的UI編輯器兵拢，用于游戲設(shè)計(jì)者的場(chǎng)景編輯器和用于游戲設(shè)計(jì)者的數(shù)據(jù)編輯器。 圖3顯示了如何在CocoStudio中處理角色動(dòng)畫逾礁。

圖 3. CocoStudio動(dòng)畫部分的屏幕截圖

動(dòng)畫編輯器將骨骼動(dòng)畫帶到Cocos2D-X说铃。 與傳統(tǒng)幀動(dòng)畫相比，骨架動(dòng)畫提供了更低的內(nèi)存消耗嘹履，更小的文本大小腻扇，把動(dòng)畫混合在一起，并重用動(dòng)畫砾嫉。 然而幼苛，骨骼動(dòng)畫有限制，例如它不能創(chuàng)建爆炸或等長(zhǎng)字符焕刮。

2.3 比較

這是符合Project Cherry Brawl標(biāo)準(zhǔn)的游戲引擎之間的一個(gè)簡(jiǎn)短的比較舶沿。 游戲引擎的主要區(qū)別如下。 下面的圖4中的代表提供了本論文作者的個(gè)人意見济锄。

圖 4. 所選游戲引擎的比較表

LibGDX【10】是一個(gè)Java游戲開發(fā)框架暑椰，提供了一個(gè)統(tǒng)一的API，可以在所有支持的平臺(tái)上工作荐绝。 LibGDX框架為快速原型設(shè)計(jì)和快速迭代提供了一個(gè)環(huán)境一汽。
　　Unity3D【11】是一個(gè)完整的游戲開發(fā)IDE，它帶有一個(gè)強(qiáng)大的渲染引擎低滩，完全集成了一組直觀的工具召夹，更容易創(chuàng)建3D / 2D內(nèi)容和輕松的多平臺(tái)發(fā)布。 它還配備了自己的資產(chǎn)商店恕沫，用戶可以下載或購買由非常大的社區(qū)創(chuàng)建的資產(chǎn)监憎。
　　Unity2D 【12】是Unity的一個(gè)新增加，使開發(fā)人員更容易開發(fā)2D游戲婶溯。 它有很多新的特性鲸阔，對(duì)于2D開發(fā)是必不可少的，如一個(gè)新的資產(chǎn)類型被稱為精靈迄委，sprite包裝（專業(yè)版）褐筛，動(dòng)畫窗口等等【13】。
　　Cocos2D-X和LibGDX是免費(fèi)和開源的叙身，而Unity給開發(fā)者在免費(fèi)版和專業(yè)版之間的選擇渔扎。 Cocos2D-X面向2D，而Unity和LibGDX有很大的2D支持信轿，但更側(cè)重于3D晃痴。 所有三個(gè)競(jìng)爭(zhēng)者都有非常好的文檔残吩，它們?cè)趕tackoverflow標(biāo)簽流行度搜索中顯示非常高，如圖5所示倘核。

圖 5. Stackoverflow.com每月標(biāo)記問題 【14】.

Cocos2D-X和LibGDX提供了一個(gè)非常容易訪問和靈活的UI實(shí)現(xiàn)泣侮，Unity則沒有，與前兩個(gè)相比非常有限紧唱。 Cocos2D-X旁瘫，Unity和LibGDX提供了極好的跨平臺(tái)適應(yīng)性，并具有非常相似的開發(fā)周期琼蚯。 Cocos2D-X的主要編程語言是C ++酬凳，也支持使用Javascript和Lua的腳本，LibGDX使用Java遭庶，Unity支持C＃宁仔，Javascript和Boo中的腳本。
　　Cocos2D-X和LibGDX背后有一個(gè)龐大的社區(qū)和大量的用戶生成的教程和第三方加載項(xiàng)峦睡，而Unity有它的資源商店翎苫。 這些功能迅速縮短開發(fā)時(shí)間，并使圖形藝術(shù)家和游戲設(shè)計(jì)師可以從可下載的模板創(chuàng)建游戲榨了。

3. Project Cherry Brawl

Project Cherry Brawl是一款動(dòng)作游戲煎谍。 通常這種動(dòng)作游戲是主角（Cherry Lyn）和大量的能力低下的敵人之間的近身作戰(zhàn)。 游戲的運(yùn)行方式和大多數(shù)的動(dòng)作游戲一樣龙屉，玩家向前移動(dòng)（向右）呐粘，與敵人戰(zhàn)斗，擊敗他們转捕，最后擊敗boss完成關(guān)卡作岖。 游戲通過詳細(xì)闡述它的背景故事將玩家置于正確的心態(tài)。
　　Cherry Lyn五芝，一個(gè)有著超能力的女孩痘儡，因?yàn)楦忻岸鴱膶W(xué)校回家了一個(gè)星期枢步。當(dāng)Cherry Lyn回到學(xué)校時(shí)沉删，事情變得有些不太對(duì)勁。在她請(qǐng)假的時(shí)候醉途，學(xué)校的科學(xué)俱樂部開發(fā)了一臺(tái)可以用作耳機(jī)的電腦矾瑰。 在耳機(jī)的幫助下，學(xué)校的學(xué)生將變得更有效率结蟋，所以校長(zhǎng)允許生產(chǎn)這樣的耳機(jī)脯倚。沒有人知道的是渔彰，在耳機(jī)生產(chǎn)之前嵌屎，科學(xué)俱樂部對(duì)它進(jìn)行了改變推正。他們?cè)黾恿艘粋€(gè)額外的功能，來洗腦學(xué)生宝惰，從而控制學(xué)校植榕。Cherry Lyn現(xiàn)在必須從科學(xué)俱樂部的控制中解放學(xué)校的其他學(xué)生。

3.1 背景研究

自從游戲機(jī)和諸如任天堂娛樂系統(tǒng)之類的舊游戲機(jī)開始運(yùn)行以來尼夺，動(dòng)作游戲就一直存在尊残。 必須完成的研究是關(guān)于如何在手持設(shè)備上正確地模擬一個(gè)動(dòng)作游戲。 研究分為兩個(gè)不同的類別淤堵，第一個(gè)是如何正確使用移動(dòng)設(shè)備屏幕和適合游戲的所有組件寝衫。 第二類是如何在移動(dòng)設(shè)備上模擬控制器。
　　第一步是在谷歌Play商店中拐邪，嘗試盡可能多的被標(biāo)記為動(dòng)作慰毅、格斗類型的游戲。 注意到所有測(cè)試的游戲都有一些共同的關(guān)鍵因素扎阶。 每個(gè)游戲都是橫向模式汹胃，給玩家一個(gè)更廣泛的視野。 如果手機(jī)處于縱向模式东臀，它會(huì)縮小播放器的視野着饥，并不適合于一個(gè)動(dòng)作類型的游戲。
　　如圖6所示惰赋，大多數(shù)移動(dòng)抓取游戲都有非常雜亂的屏幕宰掉。 這意味著當(dāng)玩家將他的拇指放在屏幕上時(shí)，它將使玩家的視野重新減少大約40％赁濒。 另外贵扰，在屏幕上具有其他用戶界面組件進(jìn)一步減少了視野或者僅僅混淆了玩家。 另外流部，在屏幕的兩側(cè)周圍有按鈕會(huì)混淆玩家戚绕，因此它們將與背景混合。

圖 6. Google Play商店中游戲Street Fight【15】的屏幕截圖

圖7展出了之前說的關(guān)于玩家視野減小的情況枝冀。 玩家視野將受到玩家自己的手和UI組件以及背景的阻礙舞丛。 當(dāng)背景和敵人/ UI組件混合在一起時(shí)，可能發(fā)生進(jìn)一步的混亂果漾，使玩家不能區(qū)分它們球切，導(dǎo)致糟糕的游戲體驗(yàn)。

圖 7. Google Play商店中游戲Street Fight【15】的屏幕截圖绒障，玩家的視角

在游戲中有不同類型的UI吨凑，通常分為四類。 分別是敘事，非敘述鸵钝，空間和元糙臼。
　　包括在游戲世界中的界面是敘事的，即玩家的角色可以看到恩商，聽到它变逃。 比如任務(wù)指揮官的全息圖片，他解釋了玩家角色的使命怠堪。
　　非敘述意味著UI被呈現(xiàn)在游戲世界之外揽乱，并且僅對(duì)玩家本身而言是可見的或可聽見的，而不是角色粟矿。 比如Project Cherry Brawl的平視顯示器凰棉。
　　空間UI元素在游戲世界中呈現(xiàn)，但不必是游戲世界中的實(shí)體陌粹。 比如當(dāng)玩家的光標(biāo)懸停在任何物品或敵人上時(shí)渊啰，該物品將得到不同的輪廓。
　　元表示可以存在于游戲世界中申屹，但不被歸類為空間绘证。 元表示的示例可以是玩家的相機(jī)上的血濺，以指示損害哗讥。 圖8反映了我以前的陳述嚷那。

圖 8. 四類UI設(shè)計(jì)【16】

Project Cherry Brawl 的UI主要屬于非敘述類，因?yàn)閁I在游戲世界之外杆煞，角色不知道它存在魏宽。 有一個(gè)例外，即當(dāng)他們受到傷害時(shí)决乎，出現(xiàn)在角色上方的數(shù)字队询。 這些數(shù)字屬于空間接口的類別，因?yàn)樗鼈兂霈F(xiàn)在游戲世界中构诚，而人物仍然不知道數(shù)字【16】的存在蚌斩。
　　在創(chuàng)建并測(cè)試了一個(gè)原型之后，其中Project Cherry Brawl的UI組件用Street Fight相同的方式顯示范嘱，我放棄了這個(gè)想法送膳，因?yàn)橥婕易约河袝r(shí)會(huì)用手阻擋屏幕的兩端。
　　當(dāng)前UI布局的想法來自希望盡可能清晰地向玩家顯示所有內(nèi)容丑蛤。 在與Linda Karlsson會(huì)面之后叠聋，得出結(jié)論，UI如圖9所示受裹。通過這種設(shè)計(jì)碌补，玩家的信息顯示在他的前面，同時(shí)他的手在屏幕的每一側(cè)。 這不僅保持屏幕不混亂厦章，而且給玩家更多的使用實(shí)際控制器的復(fù)古感覺镇匀。 此外，沒有一個(gè)UI元素將出現(xiàn)在實(shí)際的游戲玩法上闷袒，并且玩家不會(huì)如圖9和圖10所示的那樣阻止他自己的視線。

圖 9. Project Cherry Brawl的UI原型

根據(jù)目前的設(shè)計(jì)岩梳，玩家失去了很少的活動(dòng)空間囊骤，與之交換的是，角色和地圖略有縮小冀值。 這樣玩家有更多的空間來玩也物，同時(shí)保持屏幕整潔，如圖10所示列疗。

圖 10. Project Cherry Brawl完整UI的截圖

下一個(gè)問題是滑蚯，游戲資產(chǎn)必須創(chuàng)建。 通常移動(dòng)游戲必須提供不同的資產(chǎn)以支持多種寬高比抵栈。 這樣，同樣的游戲可以在流行的移動(dòng)設(shè)備，如平板電腦和手機(jī)上享受孩等。 由于資源和時(shí)間有限璃哟，項(xiàng)目必須關(guān)注某種類型的移動(dòng)設(shè)備。 所選的寬高比為15：9产艾，使游戲分辨率為480x800像素疤剑。 這樣，如果設(shè)備分辨率大于所選的480x800像素闷堡，設(shè)備將添加與上述類似的黑色邊框隘膘。 這是用Cocos2D-X[17]的多分辨率支持來實(shí)現(xiàn)的。

3.2 場(chǎng)景

本章進(jìn)一步闡述了之前關(guān)于場(chǎng)景的說明杠览，以及如何在Project Cherry Brawl中使用它們弯菊。 使用CCScene作為所有游戲不同CCNode的父級(jí)是一個(gè)很好的做法，如圖層踱阿。
　　在Project Cherry Brawl中有三種不同的場(chǎng)景误续，分別是初始場(chǎng)景，菜單場(chǎng)景和游戲場(chǎng)景扫茅。 它們用于包含不同的圖層和其他CCNodes蹋嵌，并對(duì)其進(jìn)行排序。 在下面的章節(jié)中將簡(jiǎn)要討論每個(gè)上述場(chǎng)景的創(chuàng)建過程葫隙。
　　Cocos2D-x和Cocos2D中init方法的區(qū)別在于Cocos2D-X中init方法返回一個(gè)布爾值栽烂，而在Cocos2D中它返回一個(gè)id。 現(xiàn)在做的是促進(jì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. 第一個(gè)版本的初始函數(shù)的實(shí)現(xiàn)

從上面的代碼可以發(fā)現(xiàn)焰手，如果出現(xiàn)了任何錯(cuò)誤，它將跳轉(zhuǎn)到函數(shù)結(jié)尾的清理功能怀喉。 每個(gè)對(duì)函數(shù)的調(diào)用都返回它是否成功书妻。 然后，檢查宏用于查看bRet是否為true躬拢，如果不是躲履，則直接跳轉(zhuǎn)到清除標(biāo)簽。 從技術(shù)上講聊闯，這沒有什么問題工猜，但是他們遇到了一個(gè)問題，因?yàn)槟_本語言沒有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. 跨平臺(tái)的初始函數(shù)的實(shí)現(xiàn)

這有與以前完全相同的效果篷帅，但使用break作為goto機(jī)制跳到do while循環(huán)后的代碼。 盡管不可預(yù)見地使用所述軟件拴泌，但是一般來說魏身，確保軟件的持續(xù)功能是良好的實(shí)踐。 這是因?yàn)镃ocos2D-HTML5 / JS 【19】蚪腐。
　　這可能略微偏離了主題的場(chǎng)景叠骑，但它是場(chǎng)景的一個(gè)必不可少的部分，必須詳細(xì)闡述削茁。 為了防止出現(xiàn)不可預(yù)見的錯(cuò)誤和錯(cuò)誤宙枷，每個(gè)CCNode應(yīng)該以上述方式初始化。

3.2.1 初始場(chǎng)景

初始場(chǎng)景是打開任何程序/游戲時(shí)大多數(shù)時(shí)間看到的茧跋。 它顯示信用慰丛，公司名稱等，例如當(dāng)啟動(dòng)windows時(shí)瘾杭，會(huì)顯示W(wǎng)indows問候窗口诅病，接著是登錄屏幕。
　　初始場(chǎng)景是Project Cherry Brawl的第一個(gè)組成部分粥烁，因?yàn)樗洚?dāng)?shù)氖且粋€(gè)歡迎的部分贤笆。 在這個(gè)場(chǎng)景中，將加載一個(gè)標(biāo)志讨阻，顯示它芥永，并在一定的時(shí)間后，調(diào)用director钝吮，切換到菜單場(chǎng)景埋涧。
　　上訴步驟按照以下順序完成板辽。 初始化Splash圖層后，繼續(xù)創(chuàng)建CCScene棘催，并將上述Splash圖層作為子級(jí)添加到它劲弦。 添加Splash圖層后，調(diào)用CCDirector更改場(chǎng)景不是最佳解決方案醇坝，因?yàn)檫@會(huì)立即更改場(chǎng)景邑跪。 我們期望的結(jié)果是讓Splash屏幕保持足夠長(zhǎng)的時(shí)間，以便玩家讀取標(biāo)志呼猪，然后改變場(chǎng)景画畅，如代碼段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初始場(chǎng)景中更換場(chǎng)景的操作

此外郑叠，通過給Splash層一個(gè)CCAction夜赵，可以給予所有CCNode對(duì)象明棍，使用delayAction實(shí)現(xiàn)所需的效果乡革，使得動(dòng)作在延遲兩秒后運(yùn)行。

3.2.2 菜單場(chǎng)景

不像其他具有復(fù)雜菜單系統(tǒng)的游戲摊腋，這款游戲的菜單場(chǎng)景非常簡(jiǎn)單沸版。 菜單場(chǎng)景有兩個(gè)按鈕，它們將顯示Project Cherry Brawl的控件或切換場(chǎng)景到游戲場(chǎng)景兴蒸。 用Splash場(chǎng)景相同的方式創(chuàng)建菜單場(chǎng)景被證明是有問題的视粮。 問題在于，一些孩子CCNodes橙凳，如粒子效果和標(biāo)志蕾殴，會(huì)以我們不希望的方式重疊。
　　圖11顯示了完成的菜單場(chǎng)景岛啸，演示了子節(jié)點(diǎn)的排序钓觉。

圖11. Project Cherry Brawl主菜單屏幕，演示場(chǎng)景的不同元素的不同Z值

該問題通過將所有菜單的組件作為子節(jié)點(diǎn)添加到菜單場(chǎng)景中來解決坚踩。 這樣荡灾，孩子的顯示順序可以重新排序。 值越高瞬铸，特定節(jié)點(diǎn)高于其他節(jié)點(diǎn)的越多批幌。

3.2.3 游戲場(chǎng)景

這是整個(gè)游戲進(jìn)行的主要場(chǎng)景。 創(chuàng)建的方法類似于前兩個(gè)場(chǎng)景嗓节。 與之前的初始場(chǎng)景和菜單場(chǎng)景不同荧缘，游戲場(chǎng)景中有很多子節(jié)點(diǎn)，用一層管理它不是一個(gè)選擇拦宣。 從長(zhǎng)遠(yuǎn)來看胜宇，它會(huì)導(dǎo)致代碼變得非骋混亂，難以理解桐愉，最重要的是它將很難維護(hù)财破。
　　因此，需要?jiǎng)?chuàng)建單獨(dú)的層以包含更多的游戲?qū)ο蟠踊澹T如HUD對(duì)象或游戲?qū)ο蟆?創(chuàng)建HUD層和游戲?qū)邮怯螒虻囊粋€(gè)重要組成部分左痢。 HUD層將處理與UI相關(guān)的一切，而游戲?qū)泳S護(hù)與實(shí)際游戲世界相關(guān)的一切系洛。 在下一章中進(jìn)一步闡述了兩個(gè)層俊性。

3.3 圖層

CCLayers是保持代碼清晰和容易理解，同時(shí)定義你的游戲外觀的必要條件描扯。 圖層是CCNode類的子類定页，因此它們可能包含圖像，動(dòng)畫绽诚，標(biāo)簽典徊，按鈕，sprite等恩够。關(guān)于圖層的定義因素是它們實(shí)現(xiàn)TouchEventsDelegate協(xié)議卒落，這意味著玩家可以與觸摸事件 進(jìn)行交互，如敲擊蜂桶，滑動(dòng)儡毕，保持和移動(dòng)。
　　Project Cherry Brawl利用三個(gè)不同層的實(shí)現(xiàn)扑媚，每個(gè)層代表游戲的一個(gè)組成部分腰湾，如圖12所示。

圖 12. Project Cherry Brawl的圖層樣本

HUD疆股，游戲和D-Pad層完整的構(gòu)建以及如何放置它們可以在上圖中看到费坊。 此外，它顯示了即使只有兩個(gè)主要層押桃，也可以在一款游戲中有很多視覺深度葵萎。 藍(lán)色和綠色層代表游戲?qū)樱t色代表HUD層唱凯，黃色代表D-Pad層羡忘，更多的細(xì)節(jié)在下面的章節(jié)中闡述。

3.3.1 HUD圖層

在設(shè)計(jì)HUD布局時(shí)磕昼，必須考慮以下因素： 輕松訪問的玩家的技能按鈕卷雕，回到菜單場(chǎng)景按鈕和對(duì)話部分點(diǎn)擊繼續(xù)按鈕， 玩家和敵人名稱標(biāo)簽的圖標(biāo)票从，以及他們的肖像紋理漫雕。 動(dòng)態(tài)處理游戲的對(duì)話狀態(tài)滨嘱，意味著隱藏和顯示HUD層的特定子節(jié)點(diǎn)。 玩家健康條和能量條浸间，并處理其更新太雨。
　　因?yàn)镠UD嚴(yán)重依賴于游戲?qū)樱越鉀Q方案是在HUD層中創(chuàng)建子節(jié)點(diǎn)魁蒜，并根據(jù)它們的依賴關(guān)系初始化它們囊扳。 初始化HUD層中的用戶技能按鈕將使我創(chuàng)建游戲?qū)訉?duì)象的參考，并將其傳遞給HUD層兜看。 這樣做的話锥咸，代碼將變得很難解釋，非诚敢疲混亂搏予。
　　在HUD層中初始化對(duì)象，例如對(duì)話框弧轧，命中點(diǎn)的背景雪侥，命中點(diǎn)的邊界，游戲?qū)υ捄兔Q標(biāo)簽以及D-Pad層劣针。 而退出按鈕校镐，玩家按鈕亿扁，玩家健康和能量條在游戲?qū)又谐跏蓟嗟洌⒆鳛楹⒆犹砑拥紿UD層。 這樣从祝，只有一個(gè)HUD層對(duì)象的引用必須傳遞給游戲?qū)印?這提供了從游戲?qū)虞p松訪問所有HUD層組件襟己。 圖13分別示出了命中點(diǎn)的背景，命中點(diǎn)和命中點(diǎn)的邊界的順序牍陌。

圖 13. Project Cherry Brawl中命中點(diǎn)的條的順序擎浴。 分別顯示命中點(diǎn)的背景，命中點(diǎn)和命中點(diǎn)的邊界

對(duì)話狀態(tài)也在HUD層中處理毒涧。 通過創(chuàng)建兩個(gè)叫dialogModeOn和dialogueModeOff的函數(shù)贮预，子節(jié)點(diǎn)可以動(dòng)態(tài)設(shè)置不可見并回到可見。 玩家和敵人的對(duì)話圖片和名稱標(biāo)簽也在HUD層中處理契讲。 當(dāng)調(diào)用dialogMode時(shí)仿吞，可以讓想要看到的的人談話，例如讓主角談話捡偏，此時(shí)會(huì)調(diào)用：

_hud->cherryTalks (true, 1); // frames from 1-4

代碼段 4

這些參數(shù)分別用于設(shè)置子節(jié)點(diǎn)可見和圖像框架唤冈，對(duì)敵人也有類似的功能。

3.3.2 游戲圖層

設(shè)計(jì)游戲?qū)邮潜卷?xiàng)目中頗具挑戰(zhàn)性的部分之一银伟。 即使一切都在游戲場(chǎng)景內(nèi)播放你虹，游戲?qū)颖仨毺幚碛螒虻乃羞壿嫽娓悖巧\(yùn)動(dòng)，瓷磚地圖和游戲效果傅物。 以下功能必須存在于游戲圖層中：
　　游戲的循環(huán)和所有游戲?qū)ο蠛鸵恍〩UD層對(duì)象的初始化夯辖。 它必須處理加載瓷磚地圖和管理剪切的場(chǎng)景和對(duì)話。 顯示和更新所有子節(jié)點(diǎn)董饰，如玩家的角色楼雹，敵人和HUD層組件，如玩家的角色健康狀態(tài)尖阔。 處理D-Pad上的玩家輸入贮缅，重新排序所有的孩子演員精靈位置，并更新玩家視點(diǎn)介却。 所以游戲?qū)涌梢员徽J(rèn)為是這個(gè)游戲的核心谴供。 它擁有一切，并處理對(duì)象之間的交互齿坷。
　　幸運(yùn)的是桂肌，CCLayer節(jié)點(diǎn)支持scheduleUpdate，它將一個(gè)調(diào)度更新添加到圖層永淌。 通過重寫它將會(huì)提供的更新（deltaTime）函數(shù)崎场，可以創(chuàng)建一個(gè)游戲循環(huán)。 從編程的角度來看遂蛀，游戲循環(huán)[20]是游戲的中心組成部分谭跨。 它允許游戲保持運(yùn)行，而不管是否有任何用戶輸入李滴。
　　使用TexturePacker幫助保持Project Cherry Brawl的所有資產(chǎn)螃宙，并重新創(chuàng)建他們將使用的空間。 從圖14中可以看出所坯，即使這樣的小游戲原型通常也可以具有許多紋理和資產(chǎn)谆扎。 通過將所有資產(chǎn)壓縮成一個(gè)圖片，可以實(shí)現(xiàn)批量節(jié)點(diǎn)的使用芹助。

圖14. 由TexturePacker創(chuàng)建的Project Cherry Brawl的資產(chǎn)Sprite表

將所有資源添加到TexturePacker后堂湖，創(chuàng)建了一個(gè)sprite表。一旦加載了在共享精靈幀緩存中可用的資源状土，不僅會(huì)加快游戲加載紋理的時(shí)間无蜂，而且它也是使用CCSpriteBatchNode的一個(gè)重要部分。
　　在Project Cherry Brawl的早期迭代中声诸，諸如玩家角色酱讶，敵人等游戲?qū)ο笞鳛楹⒆颖惶砑拥接螒驅(qū)印＿@使得代碼很難維護(hù)和更新彼乌。此外泻肯，即使在屏幕上一次只有十個(gè)敵人渊迁，游戲也會(huì)表現(xiàn)不佳。
　　批處理節(jié)點(diǎn)提供的是灶挟，如果它包含子節(jié)點(diǎn)琉朽，它將在一個(gè)單獨(dú)的OpenGL調(diào)用中繪制它們。這通常被稱為“分批抽取”稚铣。在沒有批處理節(jié)點(diǎn)的情況下箱叁，OpenGL繪制調(diào)用將被調(diào)用的次數(shù)與孩子的次數(shù)一樣多，如玩家角色和敵人這樣的sprite惕医。
　　一個(gè)CCSpriteBatchNode只能引用一個(gè)紋理耕漱，圖像文件，紋理圖集或一個(gè)精靈表抬伺。將所有actor sprite添加到CCSpriteBatchNode中可以大大提高游戲的性能螟够，即使在游戲可能提供給手機(jī)的最大可能壓力下，也可以給玩家所需的幀數(shù)峡钓。
　　首先重新排序精靈很難掌握妓笙。 在早期迭代的一個(gè)版本中，精靈設(shè)置了z值能岩，這看起來非常不現(xiàn)實(shí)寞宫，如圖15所示。

圖15. Project Cherry Brawl拉鹃，沒有z排序辈赋。 紅色圓圈表示錯(cuò)誤。

該問題的另一迭代根據(jù)每個(gè)actor sprite在創(chuàng)建時(shí)的位置來設(shè)置它們的z值毛俏，但是產(chǎn)生了一樣的不想要的結(jié)果炭庙。 因?yàn)槊總€(gè)單獨(dú)的actor sprite是CCSpriteBatchNode的子節(jié)點(diǎn)饲窿，所以子節(jié)點(diǎn)的動(dòng)態(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ù)

圖16. Project Cherry Brawl,敵人/陰影sprite重排阀溶。.

從0.8.1版本開始，Cocos2D-X提供了CCTMXTiledMap鸦泳，它是一個(gè)知道如何解析和渲染TMX映射的CCNode银锻。 在渲染每個(gè)圖塊時(shí)，它們將被創(chuàng)建為CCSprites做鹰。 這意味著每個(gè)圖塊可以隨意旋轉(zhuǎn)击纬，移動(dòng)，縮放钾麸，著色等更振。 由于瓦片地圖是從瓦片圖像創(chuàng)建的炕桨，因此它將被加載到自己的CCTextureCache中，從而加速加載時(shí)間和性能肯腕。 tilemap的每一層將使用CCTMXLayer CCSpriteBatchNode的子類創(chuàng)建献宫。 通過在Tiled中創(chuàng)建tilemap，可以使用CCT-MXTiledMap節(jié)點(diǎn)輕松實(shí)現(xiàn)地圖的解析实撒。
　　游戲地圖是在Tiled中創(chuàng)建的姊途，使用兩層，墻壁和地板層知态。 就像Cocos2D-X中的圖層一樣捷兰，圖層中的圖層為用戶提供了在對(duì)象的頂部繪制對(duì)象的能力，使地圖具有深度感负敏，如圖17所示寂殉。

圖17. Project Cherry Brawl中Tiled和墻壁的演示層

如圖17所示，所有的墻磚被繪制在墻層上原在。 在圖18中友扰，創(chuàng)建了游戲的地板組件。 因?yàn)樵搶釉诒趯酉旅媸粒蕴砑拥降匕鍖又械娜魏挝镔|(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í)，我的意圖是把它看做一個(gè)原型浮庐。它將展示游戲的核心力量甚负。原型設(shè)計(jì)大約需要一到三分鐘的游戲時(shí)間來完成。進(jìn)入項(xiàng)目的后期后审残，游戲的氣氛似乎相當(dāng)沉悶梭域。Cherry Lyn沒有了戰(zhàn)斗的欲望，因此產(chǎn)生了為游戲創(chuàng)建故事前傳的需要搅轿。游戲的故事是通過在游戲中的戰(zhàn)斗或檢查點(diǎn)之間的小剪輯場(chǎng)景中進(jìn)行的病涨。
　　決定添加剪輯場(chǎng)景后，我為游戲創(chuàng)建了兩個(gè)狀態(tài)璧坟。對(duì)話狀態(tài)意味著敵人既穆，玩家和老板會(huì)有腳本化的動(dòng)作，而不是玩家控制輸入雀鹃。運(yùn)行狀態(tài)意味著敵人將根據(jù)他們的AI移動(dòng)幻工，玩家角色將基于玩家的輸入移動(dòng)。
　　處理不同的剪切場(chǎng)景很棘手黎茎，但是當(dāng)游戲處于對(duì)話狀態(tài)時(shí)囊颅，在檢查點(diǎn)的幫助下，剪切的場(chǎng)景將無縫地從一個(gè)轉(zhuǎn)換到另一個(gè)。圖19展示了Cherry Lyn和敵人咕嚕之間游戲?qū)υ挼霓D(zhuǎn)換踢代。

Figure 19. Project Cherry Brawl中, 從對(duì)話狀態(tài)到游戲狀態(tài)的過渡.

設(shè)置視點(diǎn)的中心被證明是自己的問題先鱼。 嘗試不同的方法來解決這個(gè)問題，最佳的方法似乎如下：
　　通過確定玩家角色的當(dāng)前位置奸鬓，并將它與屏幕的寬度用MAX宏除以2進(jìn)行比較焙畔，返回兩個(gè)上述變量之間的較大值。 可以使用上述值串远，并使用MIN宏將其映射到tilemaps寬度減去屏幕寬度除以2宏多，該宏返回兩個(gè)變量中較小的值。 對(duì)視點(diǎn)的高度進(jìn)行相同的過程澡罚。 使用ccpSub宏伸但，它將減去屏幕中心和先前計(jì)算的變量x中的點(diǎn)，如代碼段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. 相機(jī)位置更新

這樣更胖，游戲的視角不會(huì)在HUD布局下，并且相機(jī)將跟隨玩家隔显。

4. 討論和結(jié)論

在這篇論文中却妨，Linda Karlsson和作者創(chuàng)建了一個(gè)游戲，從一開始到可以上架到Google Play商店括眠，讓人們嘗試彪标。在這個(gè)項(xiàng)目的過程中，面臨很多困難掷豺，因?yàn)檫@是一件以前沒有做過捞烟，沒有任何經(jīng)驗(yàn)的工作。
　　當(dāng)用Cocos2D-X開發(fā)Project Cherry Brawl時(shí)当船，v2.2.3是Cocos2D-X最穩(wěn)定的版本题画。在游戲開發(fā)兩個(gè)月后，Co-cos2D-X團(tuán)隊(duì)發(fā)布了v3.0的Cocos2D-X和更新的功能【21】德频，這是對(duì)以前版本的一個(gè)重大更新苍息。不幸的是，由于這個(gè)項(xiàng)目的時(shí)間約束抱婉，有必要堅(jiān)持使用v2.2.3档叔。
　　在Project Cherry Brawl運(yùn)行時(shí)，會(huì)出現(xiàn)隨機(jī)崩潰的情況蒸绩。當(dāng)Eclipse被用作主要的IDE時(shí)，它給出的錯(cuò)誤堆棧跟蹤是不可讀的铃肯，唯一的解釋是它與內(nèi)存分配有關(guān)患亿。這就是為什么選擇繼續(xù)使用Visual Studio 2012開發(fā)的原因。使用Visual Studio，可以調(diào)試項(xiàng)目并擺脫隨機(jī)崩潰事件步藕。 Cocos2D-X提供了關(guān)于游戲引擎如何工作及其工作流程的觀察惦界。該信息可以被攜帶到諸如Unity或LibGDX的其他游戲引擎中。
　　Project Cherry Brawl的創(chuàng)造過程中是一個(gè)寶貴的經(jīng)驗(yàn)咙冗，但這個(gè)項(xiàng)目可能做成不同的樣子沾歪。它試圖模仿使用一個(gè)控制器，在手機(jī)上玩一個(gè)控制臺(tái)游戲的感覺雾消。但這已經(jīng)被證明了很多次灾搏，在移動(dòng)設(shè)備上似乎并沒有很好的奏效。手機(jī)觸摸和手勢(shì)功能沒有被利用立润，但這是創(chuàng)作者的個(gè)人喜好狂窑，因?yàn)樗哪康氖悄７吕鲜降挠螒蚺c控制器的游戲。
　　我不確定Project Cherry Brawl是否應(yīng)該在幾個(gè)Android市場(chǎng)（如Google Play Store和SlideMe [32]）上發(fā)布后繼續(xù)運(yùn)行桑腮，但是在游戲結(jié)束一周后泉哈，我們的團(tuán)隊(duì)收到了很多正面反饋。起初破讨，教學(xué)者只教導(dǎo)游戲在控制臺(tái)或電腦平臺(tái)上運(yùn)行丛晦，但很明顯，移動(dòng)平臺(tái)上也存在需求提陶。它在PC上運(yùn)行得非常好采呐，因?yàn)橛幸粋€(gè)鍵盤和鼠標(biāo)工作。因此搁骑，Project Cherry Brawl的開發(fā)者決定繼續(xù)為Android平臺(tái)開發(fā)斧吐，并最終擴(kuò)展到其他移動(dòng)設(shè)備，如iOS和Windows Phone仲器。此外煤率，由于最近發(fā)布的Cocos2D-X 3.0及其對(duì)C ++ 11和OpenGL 2.0的支持，該游戲?qū)⒃诘投嗽O(shè)備上表現(xiàn)更好乏冀，為玩家提供更流暢的體驗(yà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.