从表征上看，可以完全不修改 C++ 代码，只额外加上一些东西，便可以在 lua 中得到一个类对象，从语法上相当接近的使用 C++ 的类，并可以对其继承，用 lua 重载其虚函数。甚至可以实现多重继承。

由于项目组隔的比较远，所以直到最近一个月，我才拿到这套东西的文档和源码。我的直觉告诉我，这属于过厚的粘合层，是绝对需要抛弃的。如果不是无双内测初期频频的出现 bug ，可能不会有太多人赞同我这个观点。但事实上，即使这个粘合层实现的绝无问题，完全正确的使用它也几乎是不可能的。这么厚的粘合层很难做到 robust 。

这段时间，在开发维护人员的不懈努力（不包括我，在为这个项目修 bug 的工作上，我只是一打酱油的）下，主要的 bug 也修的差不多了，但是做一些适度的改造也必须开展。跟 engine 的前开发人员聊过，我很能理解这个东西被做成这个样子，以及为什么做这样一个东西的必然性：对 lua 的不熟悉，以及迫切的需要复用 C++ 代码。但是我依然想说，解决问题之道在于，先仔细考虑问题存不存在。不做是最好的做法。

表面上看起来，这个粘合层是设计的是很精妙的，它隐藏了 lua 虚拟机的细节。C++ 程序员在写代码的时候，并不需要实际上也的确是，不知道 lua 的存在。而 lua 程序也不需要关心那个类是用 C++ 实现的。在 lua 中，可以按照 C++ 的对象模型继续对类进行继承扩展。一切都展现的完美无缺。

C++ 的代码从某种程度上也显得非常有水准，template 的灵活使用，可以在可能存在的领域重复利用发挥出功效，大量使用的 stl 容器以及智能指针保证了底层领域的健壮。

如果不是这个粘合层的对象生命期管理出了一点设计上的小问题。在 C++ 的引用计数和 lua 的 gc 管理之间有点搅和不清，我想，这个东西可能就一直用下去了。我也不会被派来对这些代码做 code review 。

没错，代码的 bug 最终都可以改过来，这个设计点上的错误也可以想办法用比较小的代价纠正。但是，仔细的考虑一下，整件事情应该去做吗？在 lua 里实现一个 C++ 的面向对象的对象模型？

面向对象不是 C++ 语言向我们展示的那些东西。这不是 C++ 语言的错，因为 C++ 只是在用它的方式去表达而已。我们可以去寻求 lua 的表达方式，正像 ROR 追寻 ruby 的表达方式一样。

诚然，培养新的语言的程序员，比把一门语言模拟成另一种要困难的多。如果我们用写 C++ 程序的思考方式去写 lua 程序，那么当我们决定把游戏用 lua 重新实现一次。除了性能，我们还会失去很多。

前段时间去广州出差，和西游组的同事吃饭。据说最近一年来，他们改进了大话和梦幻的服务器设计，把处理连接的部分独立出来放到单独的进程中 ，使服务器性能大大提高。梦幻西游的服务器，已经可以做到单台机器支持一万人同时在线。

可惜的是，大话 3 的服务器，依然徘徊在单机三千人左右。表面上最大的区别是，梦幻西游的游戏逻辑是用一种类 C 的脚本语言 LPC 写的，而大话3 则是用的 lua 。

刨除大话 3 更为复杂的逻辑处理的因素，追根到底是，lua 的表达能力更强，导致了程序员用更 C++ 的方式去用 lua 。而原来的 LPC 的代码更接近 C 一些。

不是说 C++ 比 C 慢，对于编译语言来说 C++ 甚至比 C 的执行性能更高。但是对于解释型的动态语言。那种看起来更 C++ 的风格会拖垮运行性能许多。对于开发人员来说 lua 5 以后加入的 meta table 是个好东西，但是任何强大的特性都可能被滥用。有幸 lua 还是门简洁的语言，如果有一天 ruby 在游戏开发圈子里流行起来，我都不敢想会发生怎样的事情 ;)

对于那些新接触 lua 的 C/C++ 程序员来说，我的第一条建议通常是：看看 lisp/scheme 吧，可能 lua 的血统里，scheme 的成分比 C 更多一些。要不玩一下 Haskell ，增进对函数式编程的了解。C++ 借助 template 是可以玩玩函数式编程，但很少有人真的去用。进入 lua 的领域后，你得正正经经的理解一下了。

关于 dt2 engine ，这几天我为之做的最多的事情是重新实现了一个 timer tick 的系统，这个东西很早以前就做过，也有现成的代码。不过 200 行。

但是，重新实现一个的意义在于：把这个子模块剥离出来，绕过原来的厚粘合层。而不是先前的那种设计：在 C++ 里实现一个 CTick 类，然后从 lua 中继承它，再注册回 C++ 中的 CTickMgr 。

可能下一步还会协助开发组的同事把连接管理分离出来，并改进数据库的访问。

最后友情做一个广告：大唐无双 这个游戏还是不错的。美术和玩法方面都有了长足的进步。技术问题我相信在大家的努力下都会慢慢的解决。网易的开发团队还是很强的。