cocos2d-x並不是乙個適合網遊客戶端（mmo）的遊戲引擎，越是大型遊戲，這個小引擎就越無法駕馭（雖然它非常受歡迎）。 之前我在原來的公司使用的是自主研發的c3引擎，已經對外開放（尚未開源），後面如果我有提到c3引擎，那麼指的就是這個2.5d遊戲引擎。
我想起我上個月剛離職的時候，c3的首席研究員（應該也是引擎圈內的乙個大牛）對我說cocos2d-x沒有什麼技術含量，我還不以為然，當時我想的是，如果我自己開發乙個遊戲，首選必然是cocos2d-x。但是真正到新的公司接觸了使用cocos2d-x開發的乙個類似神仙道的mmo才感覺cocos2d-x對於乙個mmo引擎來說，差的很多。與c3相比，差就差在幾年，十餘款mmo，上千位開發者的檢驗。雖然cocos2d-x的開發社群很龐大，但是它適合初學者去開發乙個憤怒的小鳥、水果忍者，並不適合乙個網遊公司去開發乙個mmo。雖然基於cocos2d-x有很多不錯的mmo，比如忘仙、神仙道。但是我認為那是一群牛x的開發者通過自己的努力彌補了cocos2d-x的不足。
可以認為我不是乙個牛人，但是乙個團隊能有乙個牛人就已經萬幸了，能有兩個就可遇而不可求了，乙個好的遊戲引擎比如c3正是被我們這些普通開發者來使用，它可以不次時代，可以不物件導向，但是它會非常易於使用，並且非常難被誤用。
牢騷發完了，下面是具體的優化：
1、去掉libxml2，改用rapidxml來解析xml檔案。 rapidxml簡直是乙個大殺器，解析xml的速度甚至比純文字解析和json格式還要快。其解析速度比libxml2快5倍，即便cocos2d-x中使用的是sax模型，而rapidxml是dom模型，使用rapidxml依然要快非常多。我們的遊戲是所有配置檔案都用xml來描述，其實大可不必，但是為了跟網頁版本配置統一，方便今後的維護，暫時沒有對配置格式進行修改。而cocos2d-x底層對xml使用最頻繁的地方就是plist檔案的解析了。ios平台下還好，nsdictionary速度也很快（但是依然比rapidxml慢一倍），但是android下效果就非常明顯了。遊戲啟動時間大大縮短。 所以，為什麼cocos2d-x還要用libxml2呢？
2、遊戲資源打包。 這個雖然是可以自己擴充套件的，但是卻是需要引擎提供支援的。因為所有的讀取都是屬於引擎的內部**。 當然不是所有的遊戲都需要資源打包，但是乙個實用（mmo向）的遊戲引擎這個是必然要考慮的。 這一塊兒牽扯到很多東西，比如遊戲資源更新，資源讀取規則，讀取失敗後的異常處理，多執行緒載入時的同步機制等等。
3、修改ccassert，增加日誌記錄功能。 作為乙個遊戲引擎，cocos2d-x內部**很不健壯，很多資源不存在或者是不小心的誤用都會讓程式掛掉。 這個對乙個mmo來說是不可接受的。 ccassert原來是乙個簡單的assert，這個在ios和android下就直接掛掉了，後面雖然修改為ccmessagebox的提示，但是依然不夠方便，因為這些彈出框都很卡很慢。接觸過mmo客戶端開發的應該都有體會資源不存在是經常發生的事情，尤其是大家一起開發功能的時候，資源總是最後才正確且完整。 這個時候記錄個log不就完了。而cocos2d-x卻並沒有提供任何log記錄功能（實際檔案log而不是開發時用的cclog）。 而引擎內部有大量的assert，斷定檔案一定是存在的，斷定某個配置一定是正確的，斷定某個frame一定是存在的，這個造成的問題就是一旦有配置錯誤，那麼程式很可能就崩潰掉了。而作為乙個mmo，尤其是已經對外發布的情況下，這個時候出現表現異常(比如不顯示)而不是崩潰會更加合理。
4、資源非同步載入。雖然cocos2d-x有提供texture的資源非同步載入，但是這並不夠用。 我們修改為這樣的形式，ccspritecache快取的時候非同步載入，這個時候可以獲取到正確的ccsprite,只不過裡面的cctexture並沒有附上乙個正確的紋理id，當載入完畢，這個id就正確了，那麼ccsprite在下一次draw的時候自然就會渲染出正確的（這裡要做下判斷，如果紋理id不正確那麼就不進行渲染操作）。 還有需要注意的就是只有乙個執行緒載入是不夠用的，根據需要可能要開3~5個執行緒來載入，才會起到非同步載入的最佳體驗。 當然，如果僅僅是怕載入卡主主線程而不關心載入速度，那麼就不需要這麼麻煩了。
5、新增乙個快速渲染的ccfont，無論是哪個平台生成字形紋理的過程都是非常慢的。如果乙個mmo中有大量的文字、聊天等等，光生成字形的時間可能就要500~600ms，那這個遊戲給人的感覺就是時不時一卡一卡的。 這個新的ccfont思路非常簡單，生成字形的時候乙個文字乙個文字的進行生成，把生成的字形儲存到乙個512*512的紋理上，然後渲染的時候取這個生成好的字形進行繪製。
6、計畫中： 人物使用骨骼動畫切片處理，這個其實應該比什麼js指令碼更應該加到引擎內部。這個要提供的不僅僅是**的支援，這個是從生產到結果的一站式技術支援。 不能引導生產流程的引擎不能說是遊戲引擎，不能成為生產線的遊戲引擎不能說是遊戲引擎。
優化進行中。。。。。。。
最後再牢騷下，我敢打賭cocos2d-x的js指令碼支援並不是乙個正確的選擇，如果是吸引html的開發者，我勉強認同cocos2d-html5，但是說實話，用html來開發網頁遊戲在幾年內都不會是乙個正確選擇。而cocos2d-html5更像是給html開發人員的玩具，並且悲劇的是這個玩具還有些難，大多數html開發者無法掌握這個玩具，只能用它寫寫鬥地主之類的小遊戲。有能力用它寫出捕魚達人的開發者要麼是頂尖的html開發者，要麼會像我一樣更習慣用c++來寫**。
正確的跨網頁平台方向應該是像c3或者是unity3d一樣，內部使用llvm把c++**直接編譯成flash或html5**，這樣現有的遊戲只要經過非常簡單的移植就可以在網頁上面跑了。像unity3d那樣支援js固然不錯，但是這個不是必須的，我如果用unity3d，我選擇指令碼語言會是c#而不會是js，相信很多遊戲開發者都會做出這樣的選擇。所以cocos2d-x費了那麼大力氣搞js，完全是走彎路了。有這個時間還不如把發布做好，把c#支援加進來（不加也無所謂，lua也湊合，就比c#慢幾倍而已）。如果cocos2d-x不能在mmo相關功能上提供更多的支援的話，那麼它對我而言就是乙個玩具，而不是乙個強力**
基於cocos2d x的連連看遊戲
基於cocos2d x的簡單連連看遊戲demo。作者說 源自 基於cocos2d的連連看遊戲 這份基於 cocos2d iphone 的版本。感謝原作者 煥德 說明 這次移植是基於了解 cocos2d 系列而作的動手系列。音訊處理還不完善，背景 還得深入了解。這份cocos2d x 是 for io...
cocos2d x 遊戲優化方案
優化的方案 引擎底層優化 紋理優化 渲染優化 資源快取 記憶體優化.紋理優化 cocos2d x 底層是opengl es實現的。對於圖案片載入的記憶體是2的冪次方。使用的是100 128 會被轉為128 128。如此浪費一定的空間。色深優化 png a8r8g8b8 a1r5g5b5 argb44...
cocos2dx遊戲優化方向
優化方向 一 引擎底層優化 cocos2dx版本選擇 二 紋理優化 png格式，乙個畫素4位元組 1.二的冪次方拼圖 由於底層的opengl是按二的冪次方申請記憶體的，然後再吧這個存在記憶體中，如果 乙個480 480 4的要存入記憶體，那麼它的實際占用記憶體是512 512 4。所以為節約記憶體，...