正文
回到时间线中，我们可以发现，Unreal 和 Unity 对两次行业的演化有着强烈的预期和精准的判断——在这些决定命运的转折点上，他们要么在巨变来临前就做好了充分的准备，在行业变迁中始终屹立不倒，要么凭借着顺应趋势的特性集和服务乘风而起。
现在我们重点来看一看 Gamebryo 、CryEngine 和 Turque，它们是在第一次行业演化中崛起的佼佼者，在各自的量级上均是罕有敌手。
Gamebryo 的标准材质 (NiStandardMaterial) 对应着可编程流水线在现代商业引擎中最简易和灵活的实现，是那个年代 (2006) 最容易上手的商业引擎之一；
CryEngine 的图形表现在孤岛危机时代是最强的引擎之一 (这里的两个“之一”二字仅仅是意思一下)；
而 Torque 更是为小型独立开发者提供了极易上手的编辑器和非常丰富的着色器开发套件 (基本上可以认为他们自己弄了个内置的低配版 Asset Store)。所有这些让它们在第一次行业演化中脱颖而出，在devmaster.net (这是那个年代的一个专注游戏引擎和中间件目录的开发网站) 上成为提及率最高的几个商业引擎。
然而时过境迁，在推出了若干有影响力的版本之后，它们不约而同地在 2011 年前后平静了下来。很明显的是，它们并没有意识到时代的趋势，在移动平台崛起时，它们没有做出任何反应，反而把精力用在了事后看起来无关紧要的改进上。
Gamebryo 的用户希望引擎能提供更好的编辑器和工具链，而 Gamebryo 前后尽力做出的两版编辑器虽然看起来很不错但并未达到工业级的成熟度 (很像后期的 cocos2d-x) ——在拥有成功项目的支撑和回馈之前就陷入了兼容性的泥潭。
而 CryEngine 似乎落入了“为了强大而强大”的漩涡，并未意识到在图形技术日趋成熟的时代，由于边际效应递减，图形上的优势越来越难以形成差异化。与老对手 Unreal 为 iOS 专门打造的瘦身版 UDK 截然相反的是，CryTek 精心打造的“新版” (Rebranded) CryEngine 甚至似乎刻意在逃避移动平台——它的主要特性是支持 Linux 和下一代主机 (PS4 / XBox One / Wii U)。
Torque 则是这三者中最为惋惜的。按照现在的眼光看，它是商业引擎中最便宜的 (~$200)，它的目标群体是小型独立开发者和团体，它的编辑器像 Unity Editor 那样亲切好用，它的脚本 TorqueScript 神似 C#，它甚至有一个 Torque 3D Store （可以看做是 Asset Store 的前身，现在仍然可以访问）。
在 StackOverflow 上，你甚至能看到 (2009 年) 这样一个有趣的比较：“Unity vs Torque game engines and IDE environment” 但是，由于对移动平台的无视，Torque 的用户源源不断地流向了 UDK 和 Unity。
Gamebryo 、CryEngine 和 Turque是三款定位迥异的游戏引擎，却有着极为相似的起落周期——在第一次演化中提供了各自领域最有价值的服务而崛起，和对第二次演化的无视甚至逃避导致的衰落。这三款引擎所有的有影响力的版本均在我们框定的第一次演化和第二次演化之间。在移动平台普及之后，这三款引擎再也没有推出一个有影响力的版本。
我们拉近视角，近距离观察 Unreal 这个贯穿十年，历经波折却仍然稳步前行的游戏引擎，看看它的步调和动作是如何与时代趋势相匹配的。在图中我们不难看出，Unreal 总是能够捕捉并提前准备好对应的发布——细究每一条细节，Epic Games 在十年里完整地向我们诠释了
“与时俱进”
的真义——在行业需要深度的时候提供足够的深度，在行业需要广度的时候提供足够的广度。（呃，一不留神成了 Epic 吹了~~）
接下来是第一部分的结论——
不是最强的，也不是最新最酷的，更不是最贵的，而是最适应变化的，活了下来。
这个结论是由达尔文的进化论金句略作修改而来，原文见下面的方框。
如果想要各种姿势自顶向下自底向上巨细无遗地了解游戏引擎的方方面面，可以看 Milo 老师的游戏程序员的学习之路（链接：http://dwz.cn/57AaPH），这里就不多说了。我们抓一下挈领，把游戏引擎的评估放在最重要的位置，试着解决一下关于 “How” 的几个问题——“How to evaluate” (评估)、“How to use” (运用)、“How to extend” (改造)。
游戏引擎的评估
此前我曾写过一篇文章：如何判断一个技术(中间件/库/工具)的靠谱程度？（链接：http://gulu-dev.com/post/2014-07-28-tech-evaluation）这篇文章里我集中讨论了评估中间件需要注意的一些情况，在文末我写道，
“对中小规模的技术而言，上面的“望，闻，问，切”已经足以应付了。而对大型代码库/框架/引擎而言，又有一套不大一样的评估标准，另有曲径可探，咱们择日另行讨论，此处暂且按下不表。”
当时给自己挖了个不大不小的坑。两年多过去，现在这个坑终于可以填上了。
关于引擎评估，首当其冲的是三个简短的问题，我们一个一个来看。
首先，
“是否经受过同类产品的考验”
是一个决定性的因素，这不仅仅意味着能否按时交付，技术风险高低——更多时候，这是你的团队不会因为计划外因素而意外搁浅的重要保障。我们知道，捡到一个存折带来的喜悦远远低于丢失一个等额的存折带来的痛苦，
同样的，在幻想你的游戏大卖之前，先尽一切可能确保你的项目不会因为无法控制的因素夭折显然更有意义。
没有经过考验的引擎就像是一杆没上过战场真刀真枪考验过的枪
，在它有效地为你杀敌之前，先祈祷它不会伤到自己吧。这也是市场上看到的山寨产品 (对国产游戏而言) 和续作 (对 3A 游戏而言) 这么多的直接原因。
其次，
“好招人吗”
。这个问题表面上看是一个团队管理和人员招聘问题，而实际上却是一个学习曲线和培养成本的问题。在 Unreal 推出 UDK 之前，很多用 Unreal 引擎的小团队在快速出了原型之后都难以为继，这是因为那时的 Unreal 技术人员的培养成本很高，培养时间很长，在人员快速扩充时期，小团队很难消化新手和准新手给团队带来的负担。
这就造成了巨大的反差：两三个高手可以拿着 Unreal 在两个月内迅速出一个华丽的原型，在期望值迅速提高之后，弄来一大票人吭哧了一年多，在项目节点上老板一看，哎哟我去，这可不还是那个原型吗~~等等，好像还不如刚开始那时候稳定了~
最后，“是否有代码”。这个问题在此前文章（http://gulu-dev.com/post/2014-07-28-tech-evaluation）里已有表述，这里引用一下：
最后说一下这里面一条我认为比较重要的，也是当年带队的MMO项目里，被我列为头条编程规范的原则：
绝对，绝对，绝对不要使用没有100%提供源码的第三方技术。
这是一条红线，不管这个技术有多强大，都绝对木有例外。
程序猿们或多或少都有感触，在编程的世界里，CPU时序的不确定，存储IO的阻塞，其他进程对CPU/内存资源占用造成的扰动，后台进程如杀毒软件偶尔的锁定文件访问，公网路由的拥塞，都为运行着的程序施加了太多不可预知，不可控制的因素。而在这些不可控制的因素里面，允许在自己进程的地址空间内运行一些无法得知其本来面目的代码，是其中最危险也是最容易失控的那一类。反面例子太多，我就不举了，也免得触物伤怀，影响心境。
