首先声明，本人只对前端引擎层等相关支持性的技术内容比较熟悉。这里讨论不涉及到除前端外的其他方面。希望各位不要断章取义，另外，因为水平有限。有说的不对的地方，欢迎各位拍砖。
想来用Lua + C/C++的方式做游戏也有些年头了。刚开始第一次是在诺基亚上使用Lua开发（挺佩服当时公司的CTO的），后来开始研发智能机手游的时候，早期的cocos2dx的坑我就不多说了，使用过的童鞋应该深有体会。不过渲染那块和跨平台相关的还是没什么毛病的，至少用起来是没什么毛病的。因此，签于之前的经历，当时就抽象了cocos2dx之上的另一层封装（PS：刚开始做的时候，quick是没有出来的，做到一半的时候，出来了，但是感觉很不好用，因此所有拓展接口的抽象以及模块解耦都是自己做的。）
深受当时在诺基亚上使用Lua经历的影响，鉴于当时那套接口的耦合度相当低，功能小巧而稳定，接口分离而五脏俱全。所以当时在设计接口的时候是参考了前辈（那个公司的CTO）的思想的，这里致谢。
以下是个人的观点，不喜就喷。只讲两点，也是我看到很多童鞋使用中最频繁的两点。没有涉及到太细节的技术，仅仅是思路上的一点点探讨。
功能解耦
各个功能模块的解耦在我看来是非常重要的一件事情。最基本的就是逻辑于功能模块的解耦，这一点，无论是在C层（我C++不好），还是在Lua层，从设计上，都应该得到体现。举个当时开发时候的栗子吧，因为早期的2dx版本不客气的说，实在是不太适合大型一点的网络游戏开发。跟进代码后，你会发现，很多网络（或者说单机）游戏的开发，提升体验的时候，要么是假的接口（也就是似是而非），要么是完全没有这个功能。异步读取文件创建精灵对象对于游戏而言，应该是很常见的功能了吧。有些方式是直接在C层来整个实现这个过程，然后再回调Lua，如下：
定义：
FileUtils::asyncRead(..., void (*callback)(unsigned char *data)); // 文件异步接口
上面这个接口是通用的。
...
void callback(unsigned char *data) {
if (data) {
Sprite *s = Sprite:create(data);
// callback Lua
...
}
}
Sprite:asyncCreate(...) {
FileUtils::asyncRead(..., callback);
}
然而相较这种方式，我更倾向于将文件和异步接口都丢给Lua，然后由Lua来完成这个组合，也更方便。例如：
-- Lua代码
FileUtils::asyncRead(..., function (data)
if (data) then
local s = Sprite:create(data)
xxx:addChild(s)
end
end
)
个人觉得，既方便了修改，又便于维护引擎层的稳定性（功能越单一，可能的BUG就越小），功能层给出的应该是功能模块，而不是具体的解决方案。具体如何去组合，在我看来应该是脚本层的事情。好比炼铁的接口给你了，之于生产出的铁是用于造锤子还是钉子，是消费者的事情，也就是脚本层的任务。
第一种方式看似脚本方便了，这次是造把锤子，以后要造口锅，你不是又得去修改引擎层代码？一来二去，可复用性受到影响，稳定性和耦合度也会打折吧。
所以，个人认为，功能层最重要的目标就是功能模块的单一化，最好不负载任何逻辑。要异步网络接口有异步网络接口，要数据解析接口有数据解析接口，这样，给脚本发挥的余地和空间都很大。虽然对于脚本使用者而言难度会提高，但是也留有充分的余地，这一层稳定了，类似要搭建第一种方案的情况下，完全可以在本层的基础上再做一层拓展。类似于3D引擎中基础渲染和上层渲染层的关系一样，基础渲染只负责最基本的shader处理，而上层渲染则可以在软件层面上进行顶点处理、模型剔除、空间划分等软件层的优化。
脚本化程度和使用思路
另外见到的一种比较多的情形，是脚本化程度的问题。一种是觉得脚本不安全。这个问题通常加个密就好了，别说脚本了，你其他的资源没什么特殊的话，一般也要加个密吧。现成的加密算法库很多，用起来不难。什么？等cocos2dx？其实加解密资源这东西，你要是做的不复杂的话，真没什么难的。想到Lua的问题，无非就是脚本加密后怎么Load的问题。找个Lua手册读一读，方案不就出来了。一切的问题就是——你不钻研，满足于表面。
另外，安全的话，要是别人妥妥的把你的加密脚本破解了，你觉得他反编译你的可执行文件（也就是引擎层）、动态或静态连接库，再分析分析，难度会很高么？其实有些文本资源用一些高强度算法加密后的破解难度比反编译要高的多。
安全的话就牵扯到另外一个话题，有些敏感信息之类的。有些脚本不彻底的就在脚本处理的时候，把一些类似支付啊、访问地址啊、密码啊什么的放在C层，其实完全没有必要（前提是脚本加密了）。能截取数据包的一样截取数据包，想依赖C这个壳，简直是痴人说梦。半开半闭的脚本模式是我觉得最恶心的模式，用的闹心！要么全开，要么全封闭（这里的全封闭是类似3DMMORPG在端游的做法，脚本有少量的接口，挂NPC、场景、副本等等，基本上是起到一个控制作用，其他的模型地图什么的资源读取渲染，都是按照特定的流程从配置文件中加载，完全不关脚本的事），半开半闭恶心死人。
举个栗子：
C++实现逻辑部分socket，但是连接哪个服务器，开几个连接，成功与否等等脚本全不知情...
...
一系列C++层的初始化
连接
duangduangduang操作后
...
-- Lua
local session = client:getSession();
session:registerXXX(function (data) ... end) -- 注册一个收到xxx消息的回调
session:sendXXX(data); -- 发送一个xxx消息
有什么问题？于是乎，C++层充满了网络指令的不确定性，我们要新增工会功能，好吧，新增一个sendXXX1消息，我们要查看好友信息功能，再新增一个sendXXX2消息。于是你用Lua热更？开玩笑吧。
最关键的地方在于，Lua层注册的回调函数里面，有相当的为了“我们是自由的（热更）”的效果，一大堆readInt8/16/32/String等等放在这里，Lua层和C++层充斥着大量的重复定义的消息宏。导出给Lua就可以了啊。是的，有变化的时候再导一次？关键的问题，不是read的问题，问题是没write啊，好比核心的封包处理其实还是在C++层，换个Lua一下，没什么意义。
另外一个是语言特点的问题。好像不是问题，只是我不喜欢这样。你一大堆的C++结构噼里啪啦的直接就往Lua层导，有没有考虑过Lua的感受？更有甚者，连std::map<xxx, xxx>这种都往里面丢，连带一大堆的map操作符，什么insert等等。我想说的是，不是不行，而是你就不能转成table push给Lua么？
每个语言有每个语言的特点和优劣，对象之间可以相互转换的就应当适当的转换类型。一是消费环境好用，二是减少生产环境的浪费。下次你是不是再导个std::list<xxx>啊？int和string还得弄俩。
关于封包处理，我个人比较喜欢Protocol Buffer这种。引擎层的处理不需要改动，丢给描述文件就是了。生产出的Message实例转换一次Push给脚本就好。
其实，这是一篇最近看到很蛋疼的东西的吐槽。就到这里。有不同观点的，大家可以讨论交流。
