游戏引擎碎念 2

    上次在《游戏引擎碎念》中，我提交了那个时候对于引擎的一些看法，这篇文字不准备革命，只是准备打个补丁。我过去对于引擎的认识，总是底层+工具+框架，底层就是平台api以及基本数据结构和算法的封装；工具就不用说了地球人都知道；框架呢？就是用作“粘合剂”，粘合游戏系统与底层的层次。各个层次按照什么组织，那不是问题，问题是，结构就是这样的结构，很少有变化。

    我最近遇到了一个很死很烦人的结构，在这个结构里，任何对于结构的破坏，都必须发生在结构所允诺的范围内，必须使用结构所要求你使用的技术来对之进行破坏。一开始我很心烦，心烦的结果就是上一篇文章：《新年了，说点什么吧还是……》，但是，能怎么办呢？大家都有事情忙，都被这东西郁闷了，难道我们这些做具体工作的也能像别人那样潇洒地过来骂一声：“这东西就是个垃圾”，然后去做别的事情么？！显然不能。不能的结果就是，我们必须想好该怎么办，必须习惯于神秘的探索，必须立足于脚踏实地的前进，必须做出具体的解决方案。这东西再是个垃圾，我们却也无法避免，那么，何不就这样，想一下为什么别人要这么做，我们可以怎样来做呢？

    人把底层设计得很复杂，有些人把底层设计得很独立，有些人把底层设计得很好很强大，有些人把底层设计得很傻很天真——其实没有什么不同，因为底层的结构不可能脱离其所依据的平台而存在。举例而言：DX10结构和DX7结构就很有不同，底层设计是否可以独立于这种平台api的强硬限制呢？再比如说，windows io和linux io也有所不同，windows wchar_t和linux wchar_t也有所不同，底层的平台io函数和locale是否可以独立于这些平台api存在呢？那是不可能的。所以，如上篇文章所说，我现在自己也不会太赞成底层过于复杂的设计了。

    再说结构，有些人把结构设计得很灵活，却很难组织，有些人把结构设计得很好组织，却很死板，到底哪种好？我觉得这个事情没有绝对，每个人的感觉都不同，但是，必须强调一点，框架结构无论如何——它所完成的任务，只不过是转嫁工作量而已。对于一个游戏而言，两个水平相当的小组，使用相近的技术，完成他所花费的功夫基本是一致的。对于这基本一致的功夫而言，框架多做一点，引擎的使用者就可以少做一点，框架少做一点，引擎的使用者就必须被迫多做一点。因此一个引擎如果没有框架还在那里沾沾自喜——那就准备好迎接一大堆受虐狂吧——不过中国的程序员有受虐狂么？引擎的使用者才不会去管你引擎这里那里怎样怎样，他们只关注游戏的质量和开发速度。

    公正点说，底层的设计，这个做的是复杂了，这主要是因为GC的引入和多线程，如果这些还都可以忍受，那么框架也做得太复杂了，这主要是因为框架层希望控制的事情太多，这就比较郁闷了。而这些事情在我们的项目中，却又恰恰不能按照他们所预想的道路发展——因为我们的项目还有另外一套体系。最为致命的是，对框架层的修改被迫不得不使用它强制的方式来进行，而对这种方式的学习中我们悲惨的发现这个过程是痛苦和扭曲的。因此，尽管这个引擎口碑不错，我仍然不得不表达一下自己心中的想法：它确实不适合我们的项目……真怀疑它是怎么适合你们的项目的？！

    我讨厌强制，强制意味着弱小，强大的引擎应该不至于沦落到强制用户必须这么这么，必须那么那么的地步。诚然，结构本身就是强制的，他代表着整个体系的健壮、安全和稳定，如果它不强制，那么整个体系就无从保证。但是强制也不能强制到对于风吹草动也要紧张的地步。结构犹如管理国家，文火慢煮，旁敲侧击永远是重要的，只有对于最顽固的敌人，才能进行正面对抗。两套水土不服的体系互相勾心斗角，苦了一大群被夹在中间无力反抗的人们，好在现在已经略有些进展，甚至能够游刃有余在两套体系之间。但，引擎的体系过于强硬，还是让我们感觉到无限的压力和困难。

    一个引擎对于项目的普适性或许是更加重要的，我总这么认为。一个oo的企业框架已经能供各种各样的企业去完成自己的功能，为什么一个oo的游戏引擎却还是只能消化一两种游戏类型？这个很让人觉得愤懑。都说搞游戏的开发者都是一帮牛人，可我真的没有觉得在结构设计上，我们到底比那些企业项目的设计师们牛到哪里去。即便是某些自诩oo的引擎，也走的是那种强奸民意的自以为oo路线，一件事情只要不准备发生在它的体系下，那么这套体系就变得一塌糊涂，甚至一无是处了。在这上面，这些oo引擎和我们现在用到的这个不自我标榜oo的几乎是一丘之貉，只不过更小更精悍更底层，不会遇到像我们现在的问题罢了。oo有时候并不是简简单单的模式，而是模式之外，对于整个体系结构的清醒认识。——这上面ogre做得还算可以，只可惜底层的设计上走得有点远，离一个游戏引擎差得也还太远了……

    或许我们还真的有很长的路要走……