前言

　　《歡樂坦克大戰(zhàn)》是一款支持 3V3 實(shí)時(shí)對戰(zhàn)并首批參與上線的微信小游戲中的作品。因?yàn)樵撚螒驗(yàn)槲⑿判∮螒蛑械闹囟戎鳎?xiàng)目開發(fā)周期非常短，所以游戲復(fù)雜度、開發(fā)難度、性能挑戰(zhàn)也是挺大的；項(xiàng)目組在一個(gè)月內(nèi)就完成了單機(jī)、網(wǎng)絡(luò)對戰(zhàn)玩法的開發(fā)。

　　同時(shí)，因?yàn)榭蛻舳碎_發(fā)團(tuán)隊(duì)的核心成員有多年的 Cocos2d-x 引擎開發(fā)經(jīng)驗(yàn)，所以項(xiàng)目組決定使用 Cocos Creator v1.6.1 版本的引擎進(jìn)行開發(fā)。而對于微信小游戲平臺采用的 javascript 語言，開發(fā)團(tuán)隊(duì)基本上是從 0 開始做，邊學(xué)邊做，對自身挑戰(zhàn)很大。

　　架構(gòu)

　　網(wǎng)絡(luò)通信方面項(xiàng)目采用了 WebSocket 協(xié)議進(jìn)行通信，而通信格式是 json。為了迎合 tdr 的 xml 協(xié)議，項(xiàng)目組自己開發(fā)了 tdr->json 的轉(zhuǎn)換工具。

　　為了方便策劃同學(xué)使用 excel 表格進(jìn)行數(shù)據(jù)配置，項(xiàng)目組又開發(fā)了將 excel 轉(zhuǎn)換成 json 文件的工具，以便供客戶端讀取配置文件。

　　地圖方面我們沒有使用 cocos 引擎自帶的 TileMap，而是自己實(shí)現(xiàn)了一個(gè)類 TileMap 機(jī)制。策劃同學(xué)可以在 excel 中配置地圖信息，使用工具將 excil 轉(zhuǎn)換成 json 格式的地圖文件供客戶端加載。

　　由于開發(fā)進(jìn)度緊張，需要同時(shí)開發(fā)單機(jī)和 PVP 玩法。所以我們封裝了一個(gè)命令層(CMD 層)來進(jìn)行戰(zhàn)斗邏輯驅(qū)動。比如使用搖桿控制坦克運(yùn)動，是由表現(xiàn)層發(fā)送 CMD 命令給邏輯層進(jìn)行處理，在單機(jī)模式下 CMD 會存儲于客戶端本地列表，然后由命令管理器 CMDMgr 在 Update 時(shí)讀取本地命令列表驅(qū)動邏輯層進(jìn)行處理。而在對戰(zhàn)模式中，CMD 命令會被發(fā)往服務(wù)器，由服務(wù)器廣播給所有玩家，玩家客戶端的命令管理器 CMDMgr 在 Update 時(shí)驅(qū)動邏輯層進(jìn)行處理。引入命令層(CMD 層)之后，戰(zhàn)斗邏輯層是抽象獨(dú)立的，開發(fā)不需要關(guān)心當(dāng)前的玩法模式，可以方便的復(fù)用，減少了開發(fā)成本。

　　我們 PVP 實(shí)時(shí)對戰(zhàn)采用的是 c/s 模式的同步架構(gòu)，客戶端做碰撞檢測，將碰撞檢測結(jié)果通知服務(wù)器，服務(wù)器進(jìn)行校驗(yàn)并做傷害計(jì)算，然后廣播給其他玩家。游戲支持?jǐn)嗑€重連、客戶端 crash 重連機(jī)制，服務(wù)器擁有戰(zhàn)斗中的所有狀態(tài)數(shù)據(jù)，重連時(shí)將所有數(shù)據(jù)發(fā)送給客戶端，客戶端進(jìn)行戰(zhàn)斗場景還原。

　　玩家位置同步采用了基于時(shí)間戳的位置點(diǎn)同步算法。這個(gè)算法原先應(yīng)用于《全民飛機(jī)大戰(zhàn)》的雙打模式、對抗模式中。《全民飛機(jī)大戰(zhàn)》中實(shí)時(shí)對戰(zhàn)采用的是 UDP 通信。而在《歡樂坦克大戰(zhàn)的》WebSocketTCP 環(huán)境下也取得了不錯(cuò)的效果。算法原理如下：

　　挑戰(zhàn)

　　在開發(fā)過程中，我們也遇到了不少挑戰(zhàn)，但是我們都一一解決了，具體遇到的問題如下：

　　1、微信小游戲平臺增加了動態(tài)執(zhí)行代碼的限制

　　微信小游戲平臺增加了動態(tài)執(zhí)行代碼的限制，比如：eval (‘console.log (1)’)、new Function (‘console.log (1)’)、setTimeout (‘console.log (1)’) 等調(diào)用方式無法調(diào)用。而在 Cocos Creator v1.6.1 源碼中大量使用了 Function，為了解決這個(gè)問題，我們和 cocos 引擎開發(fā)商溝通了下，又參考 cocos 在 1.7 版本（當(dāng)時(shí)尚未發(fā)布）中的修改，修改了一些源碼，解決了此問題。

　　2、微信小游戲不允許超過 4M

　　正如標(biāo)題所示，微信小程序嚴(yán)格要求了大小，為了解決這個(gè)問題，我們又想了不少辦法。

　　措施1：引擎定制裁剪去掉不必要的模塊減少引擎體積，這塊通過設(shè)置引擎模塊即可。

　　措施2：圖片壓縮

　　使用 png 圖片壓縮工具 pngquant，可以有效的減小 png 圖片的文件大小（通常能壓縮 60%-70%）左右。

　　通過以上 2 個(gè)措施，資源仍然會超標(biāo)，只能采用資源動態(tài)下載的方案了。

　　措施3：資源動態(tài)下載

　　我們在游戲中增加了一個(gè)資源更新場景。游戲啟動時(shí)，場景進(jìn)行資源更新時(shí)游戲業(yè)務(wù)模塊都沒有創(chuàng)建，等到游戲場景中再進(jìn)行業(yè)務(wù)模塊的創(chuàng)建和初始化工作，然后再進(jìn)行場景切換。具體方案如下：

　　1. 先下載一個(gè)資源更新配置文件，此文件中有待資源下載列表、資源校驗(yàn) MD5 信息。

　　2. 根據(jù)資源下載列表，將校驗(yàn) MD5 和本地文件進(jìn)行對比，如果相同則不下載，如果不同則下載。

　　3. 下載完畢后，進(jìn)行 MD5 校驗(yàn)，如果校驗(yàn)不通過則刪除本地文件，重新走下載流程。這里的 MD5 校驗(yàn)，不僅可以校驗(yàn)資源下載是否正確；對于防止資源被惡意修改，資源反作弊也有一定作用。

　　4. 修改 cocos 引擎源碼， 在 load-pipeline 中，將資源讀取替換成讀取本地的下載文件。

　　由于游戲運(yùn)營中可能會有 Bug 發(fā)生，需要下發(fā)客戶端補(bǔ)丁。資源更新配置文件可能會被多次修改，而 CDN 更新會有延遲問題，導(dǎo)致部分玩家下載的配置文件可能是較舊的版本。而且有部分中小運(yùn)營商，為了成本考慮，會緩存舊的文件。以往的項(xiàng)目在發(fā)生這種情況時(shí)，一般是聯(lián)系玩家進(jìn)行定位，發(fā)現(xiàn)是運(yùn)營商問題再反饋給運(yùn)維同學(xué)，由網(wǎng)絡(luò)部門的同事推動運(yùn)營商進(jìn)行修改，效率不高。為了減少這種情況發(fā)生的可能性，我們使用了雙 CDN 策略。

　　具體的做法是，對于同名文件增加版本號機(jī)制，更新文件時(shí)將文件內(nèi)部存儲版本號 +1，并在 2 個(gè)不同的 CDN 進(jìn)行更新。客戶端下載時(shí)，下載 2 份文件，取版本號大的為準(zhǔn)。這樣當(dāng)更新配置文件時(shí)，2 個(gè)不同 CDN 只要有一個(gè)同步到即可，既能減少了 CDN 更新延遲，又降低了運(yùn)營商緩存問題出現(xiàn)的概率。

　　3、性能優(yōu)化

　　和一般的游戲不同的是，微信小游戲平臺本身的 js 腳本執(zhí)行效率較弱，iOS 環(huán)境小游戲 javascript 引擎目前使用的是 JavaScriptCore，默認(rèn)沒開 jit 優(yōu)化，js 執(zhí)行速度會比手機(jī) safari 慢，從簡單測試結(jié)果來看，速度會慢兩倍左右。從 Profiler 來看，js 腳本執(zhí)行時(shí)間會占到 80% 左右。因此減少腳本的計(jì)算量也是性能優(yōu)化一個(gè)重要的方面。

　　優(yōu)化

　　為了解決這些問題，項(xiàng)目組做了以下優(yōu)化

　　DrawCall

　　渲染批次合并和大多游戲項(xiàng)目類似，需要合理的規(guī)劃圖集的使用，將同一個(gè)層次的 GameObj 使用的圖片資源進(jìn)行拼圖。

　　可以分為地圖背景層、地表、地圖物件、坦克、子彈、特效、UI 等拼圖，盡量確保同一個(gè)層次的游戲?qū)ο笫褂孟嗤膱D集，相鄰的精靈使用的材質(zhì)相同。

　　mask

　　游戲中會顯示玩家的圓形頭像，而微信平臺下載的頭像是矩形。原先頭像顯示使用的是 cocos 的 mask 組件進(jìn)行渲染，效率較低。我們自己實(shí)現(xiàn)了一個(gè)基于 mesh 的控件，將一個(gè)圓等分為 n 個(gè)三角形，給這些三角形頂點(diǎn)賦予相應(yīng)的 UV，從而畫出一個(gè)圓形頭像。減少了頭像渲染時(shí)的批次開銷。

　　碰撞檢測

　　Cocos Creator 自帶的碰撞系統(tǒng)效率不高，沒有做空間劃分，不適合大量單位的碰撞檢測。并且每幀都需要更新碰撞體的碰撞盒。我們游戲地圖中存在大量的靜態(tài)物件（如地圖中的磚塊、主基地、鋼板等），而玩家在場景中移動時(shí)，是通過移動攝像機(jī)達(dá)到地圖視野的變化，所以大量的地圖靜態(tài)物件的世界坐標(biāo)是不變的，他們的碰撞盒只需要計(jì)算一次即可。

　　為了解決這個(gè)問題，我們給 cocos 的 node 增加了一個(gè)屬性 static，static 節(jié)點(diǎn)的計(jì)算結(jié)果可以緩存起來，避免重復(fù)計(jì)算。

　　對象池

　　游戲中的坦克、子彈、磚塊等采用對象池，進(jìn)入戰(zhàn)斗場景時(shí)有足夠數(shù)量的預(yù)加載，戰(zhàn)斗過程中進(jìn)行復(fù)用，避免實(shí)時(shí)的對象創(chuàng)建與銷毀。

　　避免場景、節(jié)點(diǎn)更新

　　分析 Cocos Creator 的源碼發(fā)現(xiàn)，當(dāng)有節(jié)點(diǎn)發(fā)生 active，會觸發(fā)遞歸遍歷場景，開銷較大。

　　為了避免這類開銷，游戲中的物體死亡時(shí)，不會將其從場景中移除或禁用，而是設(shè)置死亡狀態(tài)，通過移動坐標(biāo)到很遠(yuǎn)的地方，代碼中不執(zhí)行相應(yīng)的邏輯處理。盡量保持幀率平穩(wěn)，避免性能曲線的毛刺

　　裁剪

　　當(dāng)物體不在主角視野范圍內(nèi)并且不是持久播放的特效和聲音可以進(jìn)行裁剪不播放。

　　機(jī)型適配

　　對于美術(shù)資源進(jìn)行了高、中、低 3 檔分級，由策劃在資源表格中配置不同分級下的資源名稱。游戲過程中，根據(jù)機(jī)型和實(shí)際性能表現(xiàn)，選擇一種檔次進(jìn)行表現(xiàn)。

　　圖中橫坐標(biāo)是時(shí)間（單位秒），縱坐標(biāo)是 FPS，可以看出 FPS 有了明顯提升。通過一系列的優(yōu)化措施，最終保證了低端機(jī) iphone5S 基本能滿足游戲需要。

　　以上就是《歡樂坦克大戰(zhàn)》微信小游戲開發(fā)總結(jié)，有興趣的小伙伴可以一起來交流哦~