作者：paladin career

　　如果把网络游戏客户端以经典的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加密，商店相关调用等。

锐亚教育，游戏开发论坛|游戏制作人|游戏策划|游戏开发|独立游戏|游戏产业|游戏研发|游戏运营| unity|unity3d|unity3d官网|unity3d 教程|金融帝国3|8k8k8k|mcafee8.5i|游戏蛮牛|蛮牛 unity|蛮牛