游戏引擎的评估

转载自https://mp.weixin.qq.com/s/a5hy2Ie_v0KNNjdMESFAUg

三个必问问题

• 是否有经过验证的(同品类)产品
• 好招人吗
• 是否有源码(开源)

定义引擎和游戏的关系

• 类库式(classlibrary-style)
  • 低耦合，接触面小，对游戏约束小，升级负担轻
  • 间接层带来的开发和运行效率的损失
• 框架式(framework-style)
  • 高度相互依赖，当引擎有较大更新时适配工作量大
  • 从原型到产品迭代速度快

考虑因素(一级)

• 特性集与需求的匹配度
  特性集 (feature set) 是引擎“能帮你解决的问题的集合”。正如一个 CPU 的指令集那样，引擎的原生实现不仅能帮你省去自己实现这些特性的时间，而且往往是在特定环境下 (给定的问题域内) ，在这个引擎上所能实作出的最佳实践 (Best Practice)。有两个因素会把这种价值给迅速放大：第一，普通游戏开发团队的平均技术水准，通常是低于他们所使用的引擎的研发团队的；第二，普通游戏开发团队对引擎的熟悉程度和运用能力，在一定程度上同样也低于对应的引擎研发团队。所以已有的特性集与目标项目的匹配情况，是我们格外关注的焦点。
• 工具链完备性
  工具链 (tool-chain) 是引擎提供的“团队工作流程的内部骨架”。缺乏工具链或工具链不成熟的引擎是双刃剑，需要显著高于平均水准的团队才能有效驾驭。Gamebryo 和 OGRE 这两款引擎设计优良，但在工具链上很弱，是两个很好的例子。虽然很多团队淹没在工具制作的泥潭里，但这种不成熟也恰恰给了那些强力团队一个难得的机会，围绕着特定的业务模型构建出以业务为导向的工具链，形成了真正的团队级的核心竞争力，而这种核心竞争力是那些有着成熟工具链的引擎的团队极度难以形成的。总得来说，能力强，不怕延期，敢于投入的团队，才有机会扭转，获得业务导向的工具链带来的红利。
• 最小迭代时间
  迭代时间 (iteration time) 是日常开发中无可争议的 No. 1 Time Killer，直接影响你的工程效率。我在 Unreal 3 上工作时，有大量的场合 (如 Console Build) 是需要静态链接的，而 UE3 的链接奇慢无比，即使在中高配的电脑上也需要不下 10 分钟。而编译速度也很让人抓狂，即使有 Incredibuild 的分摊，一旦不幸改到头文件也是相当感人。运气不好的时候，一个小时改个两三次就一闪而过了。由于在头文件的包含传染性和预编译的物理依赖关系上有欠考虑，不当依赖导致修改时的重编传染性极强，进而导致我们深入研究出一系列“避免动到头文件就能搞定需要的功能”的偏门神功，实在是说多了都是泪。好吧，反正这里已经黑了一把 UE3，干脆再来一个，负负得正吧。UnrealScript 是 Epic 专为虚幻引擎实现的脚本语言，无奈这货跟 C++ 的关系实在太紧密了 (如只要在涉及 native 的情况下改动变量就得重编 C++)，紧密到运行时的动态能力已经损失殆尽，几乎已经没法拿来当脚本用了 (比如像 Lua 或 Python 那样轻松地在运行时 make change / run / reload )。好在 UE4 里已经把它去掉了，这里就不多说了。

考虑因素(二级)

• 异常耐受力
  什么是耐受力？简单说就是对非正常流程的处理能力。能够使用系统性的策略，而不是事到临头草草地 assert 来处理非法输入；能够结构性地把自己可以识别和处置的错误从无数的未定义行为中区分出来。说白了，耐受力意味着“工程上的安全感”。
  举个例子，同样是使用未初始化变量，在C/C++里你可能啥事儿没有，也可能直接宕机，也可能在极为偶然的情形下宕机，也可能看起来没啥事儿没有过很长时间以后宕机。而在 Lua 里不会有任何问题，并不是后者比前者高明，而仅仅是因为它对这一类问题有良好的定义。
  再比如说，一个编辑器，指定的操作稍微没有按照事先定义的流程来，立刻 assert ，非常敏感，一有风吹草动就 halt。很多程序员喜欢辩解说“尽早崩溃”是最佳实践——在遇到问题的第一时刻报错，报得越早越好，毕竟越接近问题发生的第一现场越方便他们调试。这个说法本身当然是没问题的——如果你用个默认值糊弄一下，或者是写某种容错逻辑来忍耐了破坏假定的行为，那么错误很有可能会蔓延到之后更加远离出问题的地方才爆发，那时丢失了源头和上下文，查错的成本会变得非常高。关于尽早崩溃在游戏引擎开发的适用性，见另一篇文章的详解。
• 充分的可见性
  可见性也是重要的考虑因素。如果引擎能充分揭示自己的业务流程 (如何运作)，生成的各类数据 (如何存储)，关键模块的性能开销 (如何优化)，那对各类基于引擎的二次开发才能更有信心，才能够最大限度地避免依赖了错误的假定。当出现问题时，也更容易查找和比对。而如何在维护最大的可见性的同时保持良好的封装和较低的耦合，同样是一个很大的话题，这里就不再细说了。

考虑因素(三级)

• 工作流的可定制性
• 对团队规模变化是否友好
  不少引擎的工具链适应不了团队级的开发，尤其是大规模团队的开发。这类问题会在团队规模迅速增长，对引擎的平均理解程度迅速降低时暴露出来
• 对第三方库是否友好
  商业引擎通常会有不少与第三方中间件的交互。考察这种交互的一个简单方法是观察那些“三不管”的薄弱地带。此前工作在 Unreal 上时，我曾短期地维护过一个模块，那个模块的业务逻辑依赖于 Unreal / Scaleform / Bink 这三方的适配。因为它们各自为政，在两两集成时，本来就是形式胜于实质，三方交互时就更为薄弱了。当大批量数据需要高频地在不同的中间件之间传递时，潜在的问题就会很容易集中爆发
• 对行业标准是否友好
  使用行业标准这一条就不多说了，我曾在一个游戏项目里见过七八个有着不同的 internal representation 的字符串类 (还不包括 std::string) 。光是字符串转换之间的各种细节，潜规则，优化手段，都够得上出本书了~ 想想你的工程师把他们宝贵的脑力消耗在这些事情上，实在是惊人的浪费~
• 社区问题解答能力，互相作用方式