Game Engine Architecture by Jason Gregory：1.6 实时游戏引擎架构(1)

一个游戏引擎一般是由工具集和一个运行时组件组成。下面部分我们将首先研究这个运行时组件，然后再看工具集。
图片1.11展示了组成一个典型的3D游戏引擎的主要的组成部件。没错，它非常宏大！而且这张图片并没有把所有的工具都包含进来。游戏引擎绝对是一个大的软件系统。
就像其它所有的软件系统一样，游戏引擎是分层次结构的。一般来说上层依赖下层，但反过来不一定成立。当下层也依赖上层的时候，我们就说这是一个循环依赖。循环依赖在所有的软件系统中都是需要尽量避免的，因为它们导致系统联接关系不明，让软件变得不可测试，阻止代码重用。这个对大规模系统如游戏引擎尤其正确。

 

图片1.11 Runtime game engine architecture

现在是图1.11中对话框中描述的组件的一个概览。本书剩下的部分将对这些组件进行一个更加深入的探讨，并学习这些组件如何被整合成一个功能齐全的完整的系统的。


1.6.1 目标硬件
目标硬件层，在图1.12中单独列出来的，是将运行游戏的电脑系统或者主机。典型的平台包括运行Windows或者Linux的PC，苹果iPhone和苹果电脑，微软的Xbox和Xbox 360，　索尼的PlayStation，PS2, PSP, PS3，任天堂的DS, GameCube, 还有Wii.这本书中大部分主题都是平台无关的，不过我们将会讲到一些针对PC或者主机的不同设计上的考虑，在某些有比较大的差别的地方。


1.6.2 硬件驱动
如图1.13描述的一样，硬件驱动是比较底层的由操作系统或者硬件开发商提供的软件组件。硬件驱动管理硬件资源，把操作系统与引擎上层跟无数不同的可用的硬件细节操作隔离开来。


1.6.3 操作系统
在PC上，操作系统是一直运行着的。它指挥着多个程序在一台电脑上运行，其中就包括你的游戏。操作系统如微软的Windows采用时间片的方法来让多个运行程序分享硬件资源，这个就是广为人知的抢占式多任务(pre-emptive multitasking).　这个表示一个PC游戏永远不能假定它对硬件有着完全的控制 - 它必须跟系统中的其它程序“和平共处”.
在主机上，操作系统一般只是一个很小的直接链接到你的游戏运行程序的库。在主机上，游戏一般完整的“拥有”整个硬件。不过，根据Xbox 360和PS3的介绍，并不是严格的这种情况了。例如，这些主机的操作系统可以打断你的游戏的运行，或者取得某些系统资源来显示在线信息，或者允许玩家暂停游戏，调出PS3的Xross Media Bar或者Xbox 360的dashboard。不管怎样，所有主机和PC上面的开发的差别在慢慢的缩小。


1.6.4 第三方SDK和中间件
大多数游戏引擎都使用了许多第三方的SDK和中间件，SDK提供的或者或者接口一般称之为应用程序接口(API).我们来看一些例子.

1.6.4.1 数据结构和算法
如同其它任何软件系统一样，游戏也非常需要一堆数据结构和算法来帮助处理。这是一些第三方提供的这些功能的例子。
* STL. C++标准模板库提供了大量的代码和算法来处理数据，字符串和I/O流
* STLport. 这是一个轻量级的简化过的STL的实现版本
* Boost. Boost是一个强大的处理数据结构和算法的库，被设计成STL的风格。(在线的Boost文档还是一个学习计算机科学的好地方。)
* Loki. Loki是一个强大到让你头痛的通用编程模板库。

游戏开发者在是否在引擎中使用模板库如STL上产生了分歧。有些人觉得STL的内存分配模式并不高效并导致内存碎片(看5.2.1.4节)，这使得STL在游戏中不适用。另外一些人觉得STL的强大和方便足以掩盖它的缺点。而且事实上大部分问题都可以解决。我的个人意见是STL在PC上面使用是没有问题的，因为它的高级的虚拟内存机制对于小心的内存分配不是那么严格(但仍然需要小心)。在主机上，由于受限的或者根本就没有虚拟内存机制，还有昂贵的cache miss开销，你最好自己写一个具有可预测的或者极少内存分配的自定义数据结构(在PC项目上这样做的话也不会错到哪去).


1.6.4.2 图形
大部分游戏引擎是建立在这些硬件接口库上面的：
* Glide. 这是一个给老式Voodoo显卡的3D图形SDK. 它在硬件坐标转换和光照加速(hardware T&L)也就是DX8出现的时代非常流行。
* OpenGL. 一个广泛使用的轻便的3D图形SDK.
* DirectX. 微软的3D图形SDK，OpenGL的主要竞争对手。
* libgcm是一个底层的直接面向PS3的RSX显卡的接口，是索尼提供的一个比OpenGL更高效的选择。
* Edge是一个由Naughty Dog还有索尼为PS3提供的强大的渲染和动画引擎，它被许多第一方及第三方游戏工作室采用。(译者按：第一方工作室，first-part studio，与某家游戏机制作商签约的专门为他们制作游戏的工作室)


1.6.4.3 碰撞和物理
碰撞检测及刚体物理(在游戏开发交流中简称为“物理”)由下面这些有名的SDK提供支持：
* Havok. 一个非常流行的工业水准的物理及碰撞引擎
* Phy X. 另外一个具有工具水准的物理及碰撞引擎，可以从NVIDIA那免费下载。
* Open Dynamic Engine.(ODE) 是一个非常流行的开源物理/碰撞模块。


1.6.4.4 角色动画
这里有许多商业的动画包，包括但不限于：
* Granny. Rad Game Tool的非常游戏的Granny toolkit包括了能支持所有主流3D制作软件包括Maya和3DMax的性能优良的3D模型及动画导出插件，一个能读取和操作导出的模型及动画数据的实时库，还有一个强劲的运行时动画系统。在我看来，所有商业的或者私有的库中，Granny SDK有是最着最好的设计及最符合逻辑的动画API，特别是它对时间的天才的处理。
* Havok Animation. 随着角色变得越来越真实，物理及动画之间的界线变得越来越模糊。那个开发了游戏的Havok物理SDK的公司决定制作一个免费附送的动画SDK，它使得物理及动画之间的连接变得从未有的简单。
* Edge. Edge库是Naughty Dog的ICE team为PS3开发的，他们是Sony Computer Entertainment America的工具及技术团队，Sony在欧洲的高级技术团队开发了一个强劲的高效的动画引擎，还有一个为了渲染的高效的几何处理引擎。


1.6.4.5 人工智能(artificial interlligence, AI)
* Kynapse. 一直到最近，人工智能一直是由每个游戏自定义的。不过，有家叫Kynogon的公司制作了一个中间层的SDK叫作Kynapse.这个SDK提供低级的AI模块，包括寻路，绕开静态和动态的物体，发现某块区域内的弱点(例如，某个开着的窗户可能就是埋伏的好地方)，还有一个合理的关于AI及动画的接口。


1.6.4.6 生物的角色模型(Biomechanical Character Models)
* Endorphin and Euphoria. 这些是用真实人类移动的高级生物模型制作的角色动画包。

我们在前面提到过，角色动画及物理之间的界线越来越模糊。Havok Animation这种工具包试图把物理和动画通过传统方式结合起来，也即是通过Maya这类工具做出用真人动画来提供主要的动画，而通过给出物理参数进行实时的运算。不过最近一家叫做natural Motion Ltd的公司制作了一个产品试图重新定义游戏中或者其它数字媒体中如何处理角色动画。

它的首款产品，Endorphin，是一个Maya插件，它允许动画师对角色进行完全的生物模拟并导出就如同手动动画制作一样的结果。这个生物模型计算重心，角色重量分布，以及一个真实的人在重力及其它作用力影响下如何保持平衡及移动的细节。

它的第二个产品，Euphoria，是一个Endorphin的实时版，它试图产生在不可预测作用力影响下实时的精确的物理及生物动画。