引擎设计与商业模式
这篇文章摘自“免费打工仔”在www.gameres.com上的发言，虽然字数不多，但对几个引擎的评价却一语中的。
引擎设计与商业模式
包括我在内的很多朋友都喜欢看国外引擎的代码，并比较引擎之间的优劣。但是你会发现，每种引擎的设计都是于他开发者和用户及其相关，优秀的引擎不仅是设计上的优秀，更重要的是适应自身的商业（社区）模式。在这篇文章里我们着重讨论一下卡马克的Quake 3引擎，Epic的Unreal 3，开源界的Ogre3D图形引擎以及相应的Orz扩展框架。
一、Quake3=天才模式
在很早以前，我们只能接触这款游戏引擎的代码。可以说卡马克是中国游戏图形界的导师。我的很多前辈都是从这款引擎开始学起，并立志开发一款中国人自己的图形引擎。后面介绍的虚幻引擎和Ogre3D引擎都或多或少的被这款引擎所影响。
提起Quake3引擎就不能不了解id公司和他的天才程序员卡马克大神。约翰·卡马克被称为3D游戏之父，因为其开创性的把3D渲染运用到了实时技术中来。他是图形学界的牛顿，所有开发游戏的人的偶像之一（另外一个是宫本茂）。有一本书《Doom启示录》就是讲卡马克和他的id公司的故事。在这本书中，你会发现卡马克对于程序技术的痴迷胜过一起（甚至超过成 人录像带）。
所以Quake3以及其他id公司的图形引擎产品，（曾经）唯一的目的是开发出最棒最新的图形技术，把卡马克的天才发挥到极致。id是卡马克的公司，Quake3也是卡马克的引擎。如同乔布斯和苹果一样，任何人也无法漠视卡马克和Quake3之间的联系。
1 Quake3 极其重视效率，这样可以便于在硬件支持前实现未来的图形效果。
2 Quake3 代码短小精湛，卡马克对其不断优化。
3 Quake3 不如其他引擎注重模块化，卡马克一个人就能搞定。
4 Quake3 不需要重构，卡马克擅长在最短的时间内重写整个引擎。
5 Quake3 对使用者极其简单，但扩展很难。如果需要扩展，卡马克会重写一个引擎。
Quake3以及同系列的引擎，在游戏历史上的价值是无可厚非的。但是你会发现，如果要修改这个引擎，基本上要了解所有的代码。这些东西很紧密，如果你希望换一个图形场景管理算法，你会发现基本上要修改整个引擎。你可以很容易做出和《雷神之锤3》一样的游戏，但是很难把它修改成其他类型游戏。（你会理解当年要卡马克做RPG的时候甚至用辞职来威胁id管理层。）
国内有很多朋友企图模仿Quake3的结构来实现一款图形引擎或者游戏引擎，但大部分都失败了，另外的一部分也没有获得成功（挣扎中）。不是说Quake3引擎不好，是因为中国很难有类似的环境。Quake3的商业环境是，你需要一个靠技术来赚钱而不是靠产品的公司，另外还需要一个天才如卡马克一样的程序大师来驱动。基于这两点，可以说Quake3的成功是无法复制的。
二、Epic的Unreal 3引擎 = 商业模式
很多朋友都有Unreal 3引擎的代码，但我没有读过。我只是从一些看过Unreal 3的朋友的口中了解一些相关的信息。这些信息包括，
1 Unreal 3开发游戏，如果不是极其复杂，只需要脚本和编辑器就好了。它有极其强大的脚本和编辑器系统。（上海育碧的一些朋友说的）。
2 Unreal 3代码中有很多违反常规知识的地方，比如充斥着菱形继承（C++虚拟继承）。（一个看过代码的朋友说的）
3 Unreal 3代码写的很难看（一个开发类似Quake国产引擎的朋友说的）。
4 Unreal支持大量平台，图形效果非常好。
上面有很多条款我是没办法证实的，但是我们姑且就认为都是对的。
在《游戏人》中有一段描写Unreal诞生的故事，老板并不看好为《虚幻竞技场》重新开发一款引擎，因为已经有了一款卡马克的了。要超越卡马克的图形技术太困难了。但是他们发现自己在编辑器的功能上可以领先id公司很多。基本上从那往后的10年里，Unreal依靠这一点成为了最成功的商业引擎，在商业领域上击败了卡马克。
1 Unreal 3 具有强大的脚本和编辑器，这是为了给购买引擎的公司节约开发成本。
2 Unreal 3 有一些菱形继承和紧凑的代码。这是为了商业上的紧凑型，就算开放一部分源代码，你也需要得到另外的授权，你无法单独使用。（上面提及的朋友告诉我的）
3 Unreal 3目标是当前的，漂亮的图形效果，更多的平台支持，是最重要的。
这些因素代表了Unreal 3的成功，一些其他的商业引擎，比如GameBro也很注重编辑器，而不是更优秀代码质量。与其提供良好的结构，不如实现更多的效果。他们也都在各自的定位上获得了相应的成功。
三、Ogre3D图形引擎 = 开源模式
Ogre3D图形引擎（http://ogre3d.cn）是开源界最出名的图形引擎（没有之一），包括国内的《天龙八区》、《成吉思汗》等，以及国外的《火炬之光》商业作品都是使用这款图形引擎作为开发基础。和Ogre3D同期的开源游戏引擎，包括IrrLight等，都不如Ogre3D这般成功。
Ogre3D最重要的是从设计之初就目标开源社区，而不是商业或者技术。
Ogre3D 好的结构带来更多的功能，而反之则不能。 开源社区需要好的结构让更多的人来参与，而不需要商业引擎的工期，所以有充足的时间发展（十年甚至更多），而不争朝夕。
Ogre3D 采用插件化结构，这样做的好处是让一些社区开发者，不用了解和改变整个引擎，就能扩充其功能，同样开源的Quake3就很难达到这一点。
Ogre3D 只做图形引擎，不做其他部分。
这样做首先是利用了开源社区其他的成果，比如OIS或者CEGUI等良好的开源产品。更重要一点是因为不涉任何游戏逻辑部分，核心模块只有5M左右大小，功能性引擎之间可以组合使用，这样做可以让Ogre3D适应不同领域，不仅是游戏可以使用，在各种仿真领域都可以大展拳脚。同时期的IrrLight反而因为提供太多游戏相关的东西，虽然学期曲线较缓，但是应用领域反而被闲置了。
Ogre3D在技术细节上 实现了场景图中节点和内容分离，场景管理器因此可以作为插件使用，这是Ogre3D设计的初衷。
Ogre3D 因为运用了大量软件工程知识，导致在计算机运算比较差的环境下和其他引擎效率有一些差距。但因为开源引擎的持续性，随着硬件性能的提高，十年后的今天，这些问题已经不再存在。
Ogre3D 和其他开源产品一样，对开发者要求较高（和一些商业领域的产品比较而言），不过Ogre3D也因此吸引了众多开源开发者（黑客）的参与。
基于以上几点，Ogre3D在开源界得到了前所未有的成功，这种引擎开发模式，在商业领域反而不能成功。
四、Orz游戏开发框架 = 分布模式
Orz游戏开发框架(http://bbs.ogre3d.cn)是国内Ogre3D社区开发的游戏框架，他利用了Ogre3D拒绝开发图形之外代码的基础。提供了一系列开发工具以及对各种功能型引擎的粘合。不得不说Orz在游戏引擎中采用了一种极端取巧的办法。他把底层功能性引擎的开发交给了其他开源界的产品，专注于逻辑和接口的实现。相对于其他部分而言，这部分的代码很少会受到硬件升级的影响。所以可以用较少的精力，不断优化已有的代码。但Ogre3D社区内也同时存在诸多开发框架，包括比较出名的yake和Goof等。Orz凭什么能在这些框架中脱颖而出呢？
传统上软件开发的组织结构的基本问题是布洛克法则：“在延期的项目添加程序员只会延期更久”。普遍来讲，布洛克法则认为，随着开发人员数目的增加，项目的复杂程度和通讯成本按平方增加，而业绩仅以直线增加。在上面图中左面提供了一个传统开发合作模式的示意图，在这个结构中，因为每个程序员必须了解其他人员开发的模块接口，导致问题随开发者之间通讯路径的数目增加，而后者与开发者数目是平方关系（更准确地说，遵从公式N*(N – 1)/2，这里N是开发者的数目）。依照开源软件的经验，如果你有一个足够大的项目，需要足够多的人合作，你唯一的办法是尽量降低程序员之间的依赖性。
Orz提出一个理想的分布式开发模型。在这个模型中，我们定义了一个公共的知识库，里面定义了交互的规则（消息等信息），所有的程序员按照这里提供的约定完成自己的代码，完全没有和其他程序员的直接交互。在这种情况下，增加程序员的数量并不会导致过度增加开发者之间通讯的成本。
在一些需要确定性结果的程序中，比如科学计算程序，很难达到理想的分布式开发模型，这是因为程序员之间要紧密的配合才能得到一个肯定的结果。然而对于游戏程序而言，它的目的是带来娱乐性和未知现实的模拟，就如同生活一样，你根本不需要（也不可能）知道别人想了什么和做了什么。只要大家遵守相同的规则，那么就是一个不错的体系，甚至越不可预测的结果给人带来的惊喜和愉悦感越大。而这正是我们分布式开发所具有的，比如你写了一只狗，他写了一只猫，我们按照宠物的知识来通信，你根本不用确定它们是成为朋友还是进行战争。就算加入一个宠物猪进来，我们也能正确的和它沟通——只要他遵守规矩。
Orz的目的就是基于这种分布式开发模型而设计，这和它的梦想相一致。顶尖的黑客定义游戏规则，大家来遵守，成千上万的程序员和他们的代码来组成一个真正的虚拟世界。
Orz通过一系列工具和手段来接近这个目的，基于插件来组合程序员们的代码，提供消息系统和ID管理器来确定公共知识库。
Orz框架是一个可以完成商业产品的游戏开发框架，但却走的更远。它在保证足够运行效率的前提下，尽可能的增加结构的离散性质。所有的游戏内容都可以被定义成不同种类的实体，这些实体可以通过插件系统在运行期动态载入，它们通过“及其强大”的消息系统相互沟通协作。任何一个开发游戏实体的程序员，都不需要了解其他实体的逻辑。只要他们共同遵守一个消息体系，就可以在这个基础上进行协作。
但不得不说，这是一个没有经过证实的理想而已。是否能达到这个目标还让我们拭目以待。
综上所述，所有游戏引擎都需要放置在具体的商业环境中来评价其是否成功。你可以说Quake3写得太僵化，Unreal代码难看，Ogre3D运行速度不快，Orz只是一个东拼西凑的烂番茄。但是他们这些问题都是对他们所在领域的取舍。我认为，就如同人一样，如果排除环境而言，世界上并不存在绝对的完美。引擎也是如此，他们都是希望在各自的环境和条件下尽量完美。如果我们对这些客观的实时视而不见，那么对引擎的评价也是不公正的。
