游戏引擎演化史

一、什么是引擎

游戏的引擎直接控制玩家所体验到的剧情、关卡、美工、音乐、操作等内容，它扮演着中场发动机的角色，把游戏中的所有元素捆绑在一起，在后台指挥它们同时、有序地工作。简单地说，引擎就是“用于控制所有游戏功能的主程序，从计算碰撞、物理系统和物体的相对位置，到接受玩家的输入，以及按照正确的音量输出声音等等。如今的游戏引擎已经发展为一套由多个子系统共同构成的复杂系统，从建模、动画到光影、粒子特效，从物理系统、碰撞检测到文件管理、网络特性，还有专业的编辑工具和插件，几乎涵盖了开发过程中的所有重要环节，以下就对引擎的一些关键部件作一个简单的介绍。

首先是光影效果，即场景中的光源对处于其中的人和物的影响方式。游戏的光影效果完全是由引擎控制的，折射、反射等基本的光学原理以及动态光源、彩色光源等高级效果都是通过引擎的不同编程技术实现的。

其次是动画，目前游戏所采用的动画系统可以分为两种：一是骨骼动画系统，一是模型动画系统，前者用内置的骨骼带动物体产生运动，比较常见，后者则是在模型的基础上直接进行变形。引擎把这两种动画系统预先植入游戏，方便动画师为角色设计丰富的动作造型。

引擎的另一重要功能是提供物理系统，这可以使物体的运动遵循固定的规律，例如，当角色跳起的时候，系统内定的重力值将决定他能跳多高，以及他下落的速度有多快，子弹的飞行轨迹、车辆的颠簸方式也都是由物理系统决定的。

碰撞探测是物理系统的核心部分，它可以探测游戏中各物体的物理边缘。当两个3D物体撞在一起的时候，这种技术可以防止它们相互穿过，这就确保了当你撞在墙上的时候，不会穿墙而过，也不会把墙撞倒，因为碰撞探测会根据你和墙之间的特性确定两者的位置和相互的作用关系。

渲染是引擎最重要的功能之一，当3D模型制作完毕之后，美工会按照不同的面把材质贴图赋予模型，这相当于为骨骼蒙上皮肤，最后再通过渲染引擎把模型、动画、光影、特效等所有效果实时计算出来并展示在屏幕上。渲染引擎在引擎的所有部件当中是最复杂的，它的强大与否直接决定着最终的输出质量。

引擎还有一个重要的职责就是负责玩家与电脑之间的沟通，处理来自键盘、鼠标、摇杆和其它外设的信号。如果游戏支持联网特性的话，网络代码也会被集成在引擎中，用于管理客户端与服务器之间的通信。

通过上面这些枯燥的介绍我们至少可以了解到一点：引擎相当于游戏的框架，框架打好后，关卡设计师、建模师、动画师只要往里填充内容就可以了。因此，在3D游戏的开发过程中，引擎的制作往往会占用非常多的时间，《马科斯·佩恩》的MAX-FX引擎从最初的雏形Final Reality到最终的成品共花了四年多时间，LithTech引擎的开发共花了整整五年时间，耗资700万美元，Monolith公司（LithTech引擎的开发者）的老板詹森·霍尔甚至不无懊悔地说：“如果当初意识到制作自己的引擎要付出这么大的代价的话，我们根本就不可能去做这种傻事。没有人会预料得到五年后的市场究竟是怎样的。”

正是出于节约成本、缩短周期和降低风险这三方面的考虑，越来越多的开发者倾向于使用第三方的现成引擎制作自己的游戏，一个庞大的引擎授权市场已经形成。

二、引擎的进化

曾经有一段时期，游戏开发者关心的只是如何尽量多地开发出新的游戏并把它们推销给玩家。尽管那时的游戏大多简单粗糙，但每款游戏的平均开发周期也要达到8到10个月以上，这一方面是由于技术的原因，另一方面则是因为几乎每款游戏都要从头编写代码，造成了大量的重复劳动。渐渐地，一些有经验的开发者摸索出了一条偷懒的方法，他们借用上一款类似题材的游戏中的部分代码作为新游戏的基本框架，以节省开发时间和开发费用。根据马老先生的生产力学说，单位产品的成本因生产力水平的提高而降低，自动化程度较高的手工业者最终将把那些生产力低下的手工业者淘汰出局，引擎的概念就是在这种机器化作业的背景下诞生的。

每一款游戏都有自己的引擎，但真正能获得他人认可并成为标准的引擎并不多。纵观九年多的发展历程，我们可以看出引擎最大的驱动力来自于3D游戏，尤其是3D射击游戏。尽管像Infinity这样的2D引擎也有着相当久远的历史，从《博德之门》（Baldur’s Gate）系列到《异域镇魂曲》（Planescape：Torment）、《冰风谷》（Icewind Dale）直至今年夏天将要发布的《冰风谷2》，但它的应用范围毕竟局限于“龙与地下城”风格的角色扮演游戏，包括颇受期待的《夜在绝冬城》（Neverwinter Nights）所使用的Aurora引擎，它们都有着十分特殊的使用目的，很难对整个引擎技术的发展起到推动作用，这也是为什么体育模拟游戏、飞行模拟游戏和即时策略游戏的引擎很少进入授权市场的原因，开发者即便使用第三方引擎也很难获得理想的效果，采用《帝国时代2》（Age of Empires）引擎制作的《星球大战：银河战场》（Star Wars：Galactic Battleground）就是一个最好的例子。

二、游戏引擎的总概

1. Tools/Data （工具/数据）

在开发过程中，你总是需要一些数据，但不幸的是这并不象写文本文件或是定义一个立方体那么简单。至少，你得需要3d模型编辑器，关卡编辑器，以及图形程序。你可以通过购买，也可以在网上找一些免费的程序满足你的开发要求。不幸的是你可能还需要一些更多的工具可你却根本无法获得（还不存在呢），这时你只得自己动手去写。最终你很可能要自行设计编写一个关卡编辑器，因为你更本不可能获得你所需。你可能也会编写一些代码来为大量的文件打个包，整天面对应付成百上千个文件倒是非常痛苦的。你还必须写一些转换器或是插件将3d模型编辑器的模型格式转换成你自己的格式。你也需要一些加工游戏数据的工具，譬如可见度估算或是光线贴图。

一个基本的准则是，你可能要为设计工具而置入比游戏本身等量甚至更多的代码。开始你总能找到现成的格式和工具，但是经过一段时间以后你就能认识到你需要你的引擎有很大的特性，然后你就会放弃以前的撰写方式。

也许目前非常流行利用的第3方工具辅助开发，所以你必须时刻注意你的设计。因为一旦当你将你的引擎发布为opensouce或是允许修改，那也许在某天中会有某些人来应用你的开发成果，他们将其扩展或者做某些修改。

或许你也应该花大量时间去设计美术，关卡，音效，音乐和实体模型，这就和你设计撰写游戏，工具以及引擎一样。

2. System （系统）

系统(system)是引擎与机器本身做通信交互的部件。一个优秀的引擎在待平台移植时，它的系统则是唯一需要做主要更改（扩加代码）的地方。我们把一个系统分为若干个子系统，其中包括：图形（Graphics）、输入（Input）、声音（Sound）、记时器（Timer）、配置（Configuration）。主系统负责初始化、更新、以及关闭所有的子系统。

图形子系统（Graphics Sub-System）在游戏里表现得非常直观，如果想在屏幕上画点什么的话，它（图形子系统）便干这事儿。大多数来讲,图形子系统都是利用OpenGL,Direct3D, Glide或是软件渲染（software rendering）实现。如果能更理想一些，你甚至可以把这些API都给支持了，然后抽象出一个“图形层”并将它置与实现API之上，这将给了客户开发人员或是玩家更多的选择，以获取最好的兼容性、最佳的表现效果。

输入子系统（Input Sub-System）需要把各种不同输入装置（键盘、鼠标、游戏板[Gamepad]，游戏手柄[Joystick]）的输入触发做统一的控制接收处理。（透明处理） 比方说，在游戏中，系统要检测玩家的位置是否在向前移动，与其直接地分别检测每一种输入装置，不如通过向输入子系统发送请求以获取输入信息，而输入子系统才在幕后真正地干活（分别检测每一种输入装置），这一切对于客户开发人员都是透明的。用户与玩家可以非常自由地切换输入装置，通过不同的输入装置来获取统一的行为将变的很容易。

声音子系统（sound system）负责载入、播放声音。该子系统功能非常简洁明了，但当前很多游戏都支持3D声音，实现起来会稍许复杂一些。

3D游戏引擎中很多出色的表现都是基于“时间系统”(time)的。因此你需要一段时间来为时间子系统（Timer sub-system）好好构思一番。即使它非常的简单，（游戏里）任何东西都是通过时间触发来做移动变化，但一份合理的设计将会让你避免为实现而一遍又一遍地撰写大量雷同的控制代码……

配置系统（Configuration）位于所有子系统的顶端。它负责读取配置记录文件，命令行参数，或是实现修改设置(setup)。在系统初始化以及运行期间，所有子系统都将一直与它保持通讯。切换图象解析度（resolution），色深（color depth），定义按钮（key bindings），声音支持选项（sound support options），甚至包括载入游戏，该系统将这些实现显得格外的简单与方便。把你引擎设计得更为可设置化一些，这将为调试与测试带来更大的方便；玩家与用户也能很方便地选择他（她）们喜欢的运行方式。

3. Console （控制台）

所有人可能都乐意去跟风做一个象Quake那样的控制台（console）系统。但这的确是一个非常好的想法。通过命令行变量与函数，你就能够在运行时改变你的游戏或是引擎的设置，而不需要重启。开发期间输出调试信息它将显得非常的有效。很多时间你都需要测试一系列变量的值，将这些值输出到控制台上要比运行一个debugger速度显然要快得多。你的引擎在运行期间，一旦发现了一个错误，你不必立即退出程序；通过控制台，你可以做些非常轻便的控制，并将这个错误信息打印出来。假如你不希望你的最终用户看见或是使用该控制台，你可以非常方便地将其disable，我想没人能看得见它。

4. Support （支持）

支持系统（Support）在你引擎中任何地方都将被使用到。该系统包含了你引擎中所有的数学成分（点，面，矩阵等），（内）存储管理器，文件载入器，数据容器（假如你不愿自己写，也可以使用STL）。该模块任务显得非常基础与底层，或许你会将它复用到更多别的相关项目中去。

5. Renderer/Engine Core （渲染/引擎 内核）

可能所有的人都热爱3D图象渲染！因为这边有着非常多的不同种类的3D世界渲染方式，可要为各类拥有不同工作方式的3D图形管道做出一个概要描述也是几乎不可能的。不管你的渲染器如何工作，最重要的是将你的渲染器组件制作得基化（based）与干净（clean）。首先可以确定的是你将拥有不同的模块来完成不同的任务，我将渲染器拆分为以下几个部份：可见裁减（Visibility）、碰撞检测与反馈（Collision Detection and Response）、摄像器（Camera）、静态几何体（Static Geometry）、动态几何体（Dynamic Geometry）、粒子系统（Particle Systems）、布告板（Billboarding）、网格（Meshes）、天空体（Skybox）、光线（Lighting）、雾（Fogging）、节点阴影（Vertex Shading）和输出（Output）。

6. Game Interface （游戏介质）

一个3D（游戏）引擎很重要的部分便是------它是一个游戏引擎。但这并不是一个游戏。一个真正的游戏所需的一些组件永远不要将它包含到游戏引擎里。引擎与游戏制作之间的控制介质能使代码设计变得更清晰，应用起来也会更舒服。这虽是一些额外的代码，但它能使游戏引擎具有非常好重用性，通过设计架够游戏逻辑（game logic）的脚本语言（scripting language）也能使开发变的更方便，也可以将游戏代码置入库中。如果你想在引擎本身中嵌入你的游戏逻辑系统设计的话，大量的问题与大量修改一定会让你打消复用这个.