A闪的 BLOG 技术与人文

这是我很久以前写的文章，我很喜欢，但是烂尾了，没有坚持下去。这里再把这个“残篇”放到这里，以作纪念吧。

 我在一家游戏公司从事研究性工作，我的工作内容并不是研究某一领域的前沿技术，而是对市面上的游戏引擎进行生产性评估。我所关心的并非是引擎使用了多么的高深，技术文档有多么的晦涩难懂，更重要的是游戏引擎的易用性以及友好程度。借这个机会我想把一些心得体会总结下来，仅供大家参考。

 在写这篇文章之前，我曾想把使用过或者接触过的引擎全部描述一边，但是我发现，这样偏离了我最初想讨论的内容。对于一款引擎，如果你有使用的需要，必须深入了解每一个技术细节，了解其每个模块的特性。但这应该是引擎编作者要告诉你的。你可以通过技术文档或者相关社区来获取这些信息。而我要告诉大家的是一种思想。即便如此，我还是希望通过一些实际的案例来给大家做一些分析。

 回过头来说说游戏引擎的选型，这才是这篇文章的重点。我没有过端游的研发经历，但却拥有几年的页游和手游的研发经验。我想从我的个人经历说起。对于页游的技术选型，我想很多人都会毫不犹豫选择flash技术。事实上我也实在想不出页游除了flash还有哪些种技术可以选择，也许过几年HTML5会成为主流。当遇到这种情况时（这种情况极为少见），我们考虑的重点则应该放到工作流上。你需要找到合适的工具和合理的流程，来帮助你快速的开发游戏。所有的选型都应该建立在flash技术基础之上，关心游戏框架和外部工具。flash也是个很特殊的例子，flash并非为游戏而生，我们可以把它理解为一个纯粹的media库。如果制作游戏，你需要在此基础之上封装一层适用于游戏的逻辑。手游则不太一样，由于iOS设备不再支持网页插件。所以，我们无法实用原有的技术来满足手游的需求，取而代之的则是cocos2d和unity这类新游戏引擎的成功。在后续的文章中我也将会带给大家更多的跨平台游戏引擎的分析。

 在选择游戏引擎之前，你需要对你的实际情况做出正确的判断。你的团队是否有能力来把控一个引擎。这非常重要，如果你夸大了团队的技术实力，那么后面的可能会给项目带来很大的灾难，如果你的团队技术实力一般，那么最好的办法就是选择主流游戏引擎。这类引擎社区资源较多，遇到问题也比较容易解决。唯一一点不好的地方是，你要转变的你的习惯，按照这种引擎的思路来开发游戏，最终你还是需要时间来摸索出一条适合自己的工作流。
 做选型应该从哪几方面入手？我进行了总结，对于每一条我都会详细的来解释。

 1、弄清你的需求
      很多时候我们被那些主流游戏引擎冲昏了头脑。当你搜索相关技术内容的时候，无论是社区还是其他媒体，都会对其进行报道。它会不断的给你灌输它的思想。让你无意识的认为，这就是你的全部需求，这么做也是非常合理的。久而久之，不论你做什么，都会按照它的思想来思考问题。这是一个糟糕的事实，我相信，当你接触其他引擎的时候，你会觉得非常另类，很不习惯，甚至恼羞成怒，认为其他的引擎设计非常的糟糕。所以，请清理你的思绪，认真的搞明白，哪些东西才是你真正需要的。在后续的文章中，我会根据一个固定的模式来分析不同的引擎。也许你会觉得这非常可笑，但在实际操作中真的非常有效，你会发现，你以前模糊的地带一下子变得清晰。
      很多人都认为自己需要一款极为强大的引擎，可以制作出各种类型的游戏。但是抱歉。事实上这种游戏引擎并不存在。每个引擎都有他的特点，有他擅长的地方。你不可能要求一个引擎能够做到面面俱到。千万不要冒险尝试让引擎做自己不擅长的事。当人们想要制作一款2D游戏时，谁都不会去寻找3D引擎。虽然市面上很多3D引擎功过正交相机可以制作出2D游戏，但很明显，2D部分不是它们擅长的领域。

 2、不要让语言成为你的绊脚石
      很多语言都会借助脚本语言来进行游戏逻辑的编写，使用最多的脚本语言非lua莫属。但一些引擎剑走偏锋，总是喜欢搞一些极为小众的语言作为引擎的脚本来使用。甚至有一些引擎自创一些脚本语言。很多技术人员都会因为脚本语言的因素，而提升一些引擎的分数。这往往也会导致在引擎选择时的一些主观因素作祟。千万不要把语言当作是考量引擎的重要指标只因，编程语言仅仅作为一个工具而已，更加重要的则是编程思路，你可以在选择时，更加偏向于OOP。但不要在心中引发语言的斗争。

（未完待续）

      现在你不需要针对每个功能细节做深入研究，你只需要判断，你的要求引擎是否能够实现即可。你需要自己建立一个表，用来记录你的研究成果。 

 2、目标平台
      对于手游，目标平台其实非常明确。最重要的两个平台是iOS与Android。至于winphone，我想可能很多人都不会将其考虑在内。一般跨平台的游戏引擎也都会优先支持iOS和Android。至于其他平台，可以在选型之初忽略不计。当然，如果需要将游戏移植到网页中，那么需要好好考虑一番了。这些简单的信息可以直接在引擎的官网中找到。

 3、目标功能
      未完待续

 4、引擎极限
      引擎的极限是很难前期预估出来的，这需要大量的经验支撑。最快捷的方法就是寻找这个引擎的案例，从案例中你可以发现一些相关信息。案例能达到的性能效果基本上你也应该可以达到。
      另外你也可以准备一些资源，花费一些时间来做一些极限测试。在2D中我们最常用的测试渲染性能的极限测试就是在场景中添加无数个sprite，使其选装。通过这种方法来测试最高帧频60fps的时候，场景中到底能添加多少个sprite，借此来估算它的渲染性能。
      如果你的项目是强联网类型，那么你还需要针对引擎的网络模块进行针对性测试，以证实网络功能确实可以支撑你的游戏。

 5、底层技术
      从我的经验来看，底层除了C/C++就没有其他语言可以支撑了。但有一点需要确认，你所使用的引擎，在一些细节功能上是否做的足够好。比如，文字渲染。是使用了开源的第三方库，如freetype还是自己编写，者都需要你来仔细斟酌。

 6、编辑器
      我曾经一度认为，编辑器比引擎本身更加重要，同时也一度认为，好看的编辑器比界面丑陋的编辑器更加重要。事实证明，我是错的。
      很多时候编辑器作为两种身份出现，一种是工作流的牵引者，另外一种是工作流的辅助者。不少引擎并不提供编辑器，或提供功能相对简单的编辑器，这种类型的引擎，我们可以把编辑器看做是工作流的辅助者，一般来说，这种工具都是给策划人员和美术人员准备的。方便他们制作适用于引擎的游戏资源。当你遇到了牵引者类型的编辑器时，那么你真的要对其进行仔细考虑。因为它会直接影响你的工作流程。我见过一些优秀的编辑器，也见过非常糟糕的编辑器。他们的区别不在于看上去是否优雅，也不在于学习起来是否顺手，更多的则是使用起来是否顺手。
      当你在使用这种类型编辑器的时候，你会感觉所有内容在你眼前展示的一览无余，非常直观，这种编辑器的典型代表就是unity。糟糕的编辑器则会把你带向无尽的深渊。你总是会不停的抱怨，编辑器不好用，甚至很多设计的细节是反人类的设计。
      如果你遇到了一个没有编辑器的引擎。那么，不要担心，一般这种类型的引擎，它的工作流可以让你自由安排。你拥有最大的灵活度来选择适合你的工具。

 7、工作流
      每个引擎都有自己的魂，脱离了魂，那么它就什么都做不成。这就和编程语言很像。每个语言都有自己的哲学。工作流会直接影响到你的开发效率，和不同工种之间的协同。谁都不希望每次美术人员预览效果的时候需要一个程序在旁边帮忙编译打包，为了解决这个问题，我们发明了可视化的编辑器（回到第六条，讨论过）。你应该竭尽全力的去了解不同人员的想法，让他们无障碍的使用你所选择的引擎。不要让技术成为他们的障碍。

 8、是否开源
      很多人选择引擎的第一条件就是是否开源。但从我的经验来说，这一条并不关键。即使是开源引擎，也很少有人去尝试修改引擎代码。除非遇到严重bug，或者引擎相对简单，不会因为修改而导致大面积坍塌。对于闭源引擎，我们一样可以放心选择使用。但唯一的问题是，无法像开源引擎一样随心所欲的修改扩展。