移動網遊客戶端框架

  如果把網絡遊戲客戶端以經典的MVC模式看待，本地及網絡數據相當於M，一切玩家能接觸到的東西（比如渲染）相當於V，客戶端承擔的複雜度側重於構建一個簡潔靈活的框架，及一個穩定高效的C。移動應用一般都要掛到商店中供下載，而各個商店的版本更新流程頗耗時，網遊比單機會有更頻繁的版本更新，如何做到快速的自動更新是移動網遊特有的問題。

　　我們的遊戲客戶端基於cocos2d-x。它是一個需要精簡的地方做的冗餘，想替調用者操心很多東西卻沒有做恰當的很差的實現。對它的改進最好單獨寫一篇博客出來，這次就不敘述了。但不管怎樣，作爲開源庫，一個小的修訂版本號的變更引起多處接口的修改這一點行徑都是會引起報怨和諷刺的。

　　我的做法是C/C++只暴露底層接口給Lua，比如網絡消息收發、渲染對象控制、資源路徑管理等，不在native代碼中寫任何gameplay相關邏輯；所有gameplay我都認爲是易變的，都放在Lua代碼中實現。這樣就相當於M、V在native代碼中，C在Lua中。cocos2d-x自帶了Lua綁定，沿用並擴展比較容易。主循環等效率敏感的東西依然跑在native中，Lua腳本的執行時機主要有兩方面，一是某一時刻執行一次創建渲染對象，二是用戶操作或網絡事件驅動執行一段邏輯代碼，觸發式的功能放在腳本里在性能上完全沒問題。對於gameplay開發者來說，這套東西更像一種事件驅動的UI系統。腳本像其它資源一樣可自動更新而不走商店的流程，這再快捷不過了。

　　我只用C++寫了少量控件輔助類，所有控件的實現都直接用Lua來封裝。若以C++來封裝控件，最終仍然要綁定給Lua使用，除了額外的C++代碼，運行時還需要更多的時間和空間生成對應的Lua結構，這是得不償失的。如果不做動畫的話，佈局和回調就是UI系統的兩大功能，自適應分辨率又是佈局中非常重要的功能。我使用經典的絕對數據+停靠方式+縮放模式的形式實現可組合的靈活佈局。

　　對於需要大量活動對象的遊戲類型，也可沿用這套方案，甚至將邏輯對象數據結構都完全放到Lua腳本中。

　　資源路徑管理我使用了一種文件名即ID的方式，在全局索引時它不允許重名文件，後被遍歷到的文件信息會覆蓋先前的數據，而在（按子文件夾路徑命名組）分組索引時則沒有全局重名問題。這套實現可以做得很精簡。遊戲的資源會分成兩個文件夾，一個是隨初始安裝包裝好的默認資源，另一套是自動更新到一個可寫文件夾下的最新資源，資源路徑管理器每次會先遍歷默認資源再遍歷最新資源。如果程序安裝包將資源排除在外，流程上會更簡單一點。

　　主要的思路只有這些。還有些瑣碎的雜事就按需定製了，比如：http通信，遊戲狀態機，高效定時器，持久化，分級資源緩存，Lua require流程的hack，Lua加密，商店相關調用等。