游戏引擎的碎念

西历07年7月16日夜，小白偶醉，一眼看过廿四年，有感而发，遂属文若此。通篇信口雌黄，大言不惭，乳臭未干，愿得高人指点教诲。

记得自己曾说过：“游戏向左，引擎向右”，现在想想，这大抵是对的。做项目的人可以不懂一个三角形是如何渲染的（当然懂了更好做项目），他只需要知道如何使用自己手上能掌握的资源，多快好、且扩展性强地完成自己的工作。他可能不会写导出器，但他只要会用导出插件，他可能不会写BSP，但他只要会导出BSP，他可能没听说过LOD，但他也不用去管LOD，总之，他可能很多东西都不会写，只是知道那回事儿，那么他就可以作游戏——更多的时候，他的代码更直接地接触游戏的本质，AI啊，伤害判定啊，魔法技能啊，UI逻辑啊（虽然UI逻辑实实在在不应该用Hard Code写），等等等等……。所以如果你想作游戏，而不是引擎，而且想更快就深入你自己的那套故事之中，那倒不防直接去下载个免费的游戏引擎，或者很便宜的商业引擎，或者商业引擎试用版。但，当然的，这不应该是我们逃避不去认识底层引擎和API的借口。

引擎有几个概念上的引擎：一个是狭义的，仅对API进行包装，使其满足自己需求的引擎，这基本上不应该叫做引擎的。一个是将这些包装统一到场景和游戏构架中来， 完成一个整体的FrameWork，类如OGRE。一个是将FrameWork升华成包括编辑器、工具、UtilCode在内的整一套商业引擎。它们的目的是不同的，使用的也是不同的手法，即便是为了同样的目的，完成的手段也可能不同。OGRE和Irrlicht的方案就不太一样，而一个习惯了OGRE的优雅的人，是很难接受HL2：Source的，道理一样。引擎是贪婪的，永远不能满足于目前能达到的结果，虽然不是一切都有可能，但是应试图在硬件允许的情况下，尽自己最大的可能。

引擎更多的时候不是在具体的DrawPrimitive上左右徘徊，而是在某个引擎模块的构架上挑三拣四。最多的时候，需要在多个方案之中做一个权衡。当手中只有一个方案——DrawPrimitive、SetRenderState、Lock－Unlock——的时候，你不会找不到方向，引擎开发之所以有难度，就是当多个方案同时错综复杂地涌现时，很可能会瞬间找不到北。很多时候，一个构架上的小小瑕疵，就可能在几个月后、甚至一年后，形成一场风暴。但一开始你还没有任何办法，只能碰运气地挑一个方案一头撞到底。在构架的过程中形成的经验——无论成功的还是失败的——这是那些商业引擎越做越勇，越做越自信的原因。因此加强交流是必要地，多看看别人的，成功或者失误，是提高自己的最好手段。

虽然很多时候，考虑到未来的情况，会对引擎的扩展性有很大的帮助。但是有时候，对于引擎的某些部分，并不是特别必要。过度设计反倒会给用户和扩展者带来麻烦。按照唯物辩证法的观点，“活”的东西必须立于“死”的之上，因此，探讨灵活性和扩展性的前提是探讨不变性。虽然给他们太少的选择是不负责任，然而，给用户太多的选择仍然依旧是对他们的不负责任，也会增加自己的维护成本。用户需要的是成熟的解决方案——大部分情况下，他不想去管一个Button是如何地千变万化，他仅需要捕获Button的按下消息。这就正如Windows开发一样，API可以说是最灵活的了，Windows可以做什么，API就能做什么，但是为什么还有人要去冒着被鄙视的危险使用.net呢？因为很多API，按照大部分认的要求，封装之后，也不过就是.net那样子！扩展性可考虑使用COM的方式，如果这个体系不能用了，就干脆整个换一套体系，只要接口安全即可。封装可以封装的，暴露有必要暴露的，接口的设计应以简单为主。简单不仅仅意味着健壮行的增强，也意味着可以在简单模块的基础上，通过多个简单模块扩展出一个复杂的模块。.net的很多类都非常简单，但并不影响其健壮和扩充性。

很多前辈们都不赞同新手把时间花在引擎上，而我可能现在也不是像几年前那么特别地赞同了。花那么大成本，做了一个那样的引擎，大部分是API包装，或者仅有一个简单的Frame Work，甚至没有地图编辑器，一般都高不成低不就，有什么用呢？能力强？一般要是要求高的项目都会不惜血本买来国外的引擎，或者国内非常有经验的引擎团队，你的引擎可以跟他们比吗？免费？你的引擎能竞争过才一台电脑钱的Torque Game Engine Advance吗？没有项目愿意采用，引擎就等于被判了无期徒刑。

但是，心平气和一些，我想，很多人都忽视了一点，就是，如果你做了一个引擎，你可能会后悔一两天，但如果你没有做这个引擎，你可能会后悔一辈子。原理上说，一开始不应该做引擎，这就正如原理上说，每个小康的人都能买到房子一样：在中国，很多事情是做不到的。行业本身的就不用说了，是人都知道怎么回事。而对于个人的培养而言，在还没有诞生一个不 那么迫切地为了钱 ，而是为国民的未来，国家的未来的正经八百的专门培训学校和专门培训专业之前，还有什么比做一个引擎更能让自己从一个小白更快地进入图形开发的实质呢？

另外在独立或者团队完成这个引擎的同时，我们每个人都从中汲取了丰富的营养，它让我们每个人都受益，都迅速地提高。有可能你在项目代码中调用了数千行SetTextureStageState，但还不如在写引擎的时候写一句SetTextureStageState，因为前者，这些调用往往隐藏在模型、地形等高层系统的后面，如非必要你根本不需要去理会，即便要理会你也会优先去查阅相应引擎的文档而不是DX9的文档；而后者则需要你认真地去查阅DX9的文档，看清楚到底这个函数有哪些需要注意的问题。

这或许也是我还在闲暇时间维护自己的那些个破玩艺儿的原因，你可以说它出自于我愤青般无聊的激情，但我更愿意相信那来自于我理性的激进。

引擎是商品，用户买你的引擎是因为他们相信你的引擎可以更快，更好地完成他们的目的。即便是再绚的引擎，但如果不好用，也不会得到用户的青睐的。

夜半小酌，独坐于榻，若有所思，歌月徘徊，舞影凌乱，得废话若干，贴于此，仅聊然以自娱耳。不值一笑，不值一笑……