前言

　　《歡樂坦克大戰(zhàn)》是一款支持 3V3 實時對戰(zhàn)并首批參與上線的微信小游戲中的作品。因為該游戲為微信小游戲中的重度之作，項目開發(fā)周期非常短，所以游戲復雜度、開發(fā)難度、性能挑戰(zhàn)也是挺大的；項目組在一個月內(nèi)就完成了單機、網(wǎng)絡(luò)對戰(zhàn)玩法的開發(fā)。

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

　　架構(gòu)

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

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

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

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

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

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

　　挑戰(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，為了解決這個問題，我們和 cocos 引擎開發(fā)商溝通了下，又參考 cocos 在 1.7 版本（當時尚未發(fā)布）中的修改，修改了一些源碼，解決了此問題。

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

　　正如標題所示，微信小程序嚴格要求了大小，為了解決這個問題，我們又想了不少辦法。

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

　　措施2：圖片壓縮

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

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

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

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

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

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

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

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

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

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

　　3、性能優(yōu)化

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

　　優(yōu)化

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

　　DrawCall

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

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

　　mask

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

　　碰撞檢測

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

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

　　對象池

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

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

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

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

　　裁剪

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

　　機型適配

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

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

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