AI:从游戏引擎--到AI

原文连接：http://blog.csdn.net/left_la/article/details/6358911#t9

　这是我在Gameres上看到的一篇文章，文章很长，全文分为11个部分，看后感受写的很是好，对我启迪很大，特此推荐。做者是国外的一名老程序员，相信对于刚接触或者想要接触游戏引擎的同窗，这篇文章可以带领大家步入游戏引擎的世界！下面就开始吧：

 

原文做者：Jake Simpson
译者： 向海
Email：GameWorldChina@myway.com

第1部分:游戏引擎介绍， 渲染和构造3D世界

介绍
　　自Doom游戏时代以来咱们已经走了很远。 DOOM不仅是一款伟大的游戏，它同时也开创了一种新的游戏编程模式:游戏 "引擎"。这种模块化，可伸缩和扩展的设计观念可让游戏玩家和程序设计者深刻到游戏核心，用新的模型，场景和声音创造新的游戏，或向已有的游戏素材中添加新的东西。大量的新游戏根据已经存在的游戏引擎开发出来，而大多数都以ID公司的Quake引擎为基础，这些游戏包括Counter  Strike， Team Fortress， Tac Ops， Strike Force，以及Quake Soccer。Tac Ops和Strike Force 都使用了Unreal Tournament引擎。事实上， "游戏引擎"已经成为游戏玩家之间交流的标准用语，可是究竟引擎止于何处，而游戏又从哪里开始呢?像素的渲染，声音的播放，怪物的思考以及游戏事件的触发，游戏中全部这一切的幕后又是什么呢？若是你曾经思考过这些问题， 并且想要知道更多驱动游戏进行的东西，那么这篇文章正好能够告诉你这些。本文分多个部分深刻剖析了游戏引擎的内核， 特别是Quake引擎，由于我最近工做的公司Raven Software已经在Quake引擎的基础上开发出了多款游戏，其中包括著名的Soldier of Fortune 。

开始
　　让咱们首先来看看一个游戏引擎和游戏自己之间的主要区别。 许多人们会混淆游戏引擎和整个游戏。这有点像把一个汽车发动机和整个汽车混淆起来同样 。 你可以从汽车里面取出发动机， 建造另一个外壳，再使用发动机一次。 游戏也像那。 游戏引擎被定义为全部的非游戏特有的技术。 游戏部份是被称为 '资产'的全部内容 (模型，动画，声音，人工智能和物理学)和为了使游戏运行或者控制如何运行而特别须要的程序代码，好比说AI--人工智能。

　　对于曾经看过 Quake 游戏结构的人来讲， 游戏引擎就是 Quake。exe，而游戏部分则是 QAGame。dll和 CGame。dll。 若是你不知道这是什么意思， 也没有什么关系；在有人向我解释它之前，我也不知道是什么意思。 可是你将会彻底明白它的意思。 这篇游戏引擎指导分为十一个部份。 是的， 从数量上来讲，总共是十一个部份!每一个部分大概3000字左右。如今就从第一部分开始咱们的探索吧，深刻咱们所玩游戏的内核，在这里咱们将了解一些基本的东西，为后面的章节做铺垫。。。

渲染器
　　让咱们从渲染器来开始游戏引擎设计的探讨吧， 咱们将从游戏开发者(本文做者的背景)的角度来探讨这些问题。事实上，在本文的各个段落，咱们将经常从游戏开发者的角度探讨，也让您像咱们同样思考问题!

　　什么是渲染器，为何它又这么重要呢？好吧，若是没有它，你将什么也看不到。它让游戏场景可视化，让玩家/观众能够看见场景，从而让玩家可以根据屏幕上所看到的东西做出适当的决断。尽管咱们下面的探讨可能让新手感到有些恐惧，先别去理会它。 渲染器作些什么？为何它是必须的？咱们将会解释这些重要问题。

　　当构造一个游戏引擎的时候， 你一般想作的第一件事情就是建造渲染器。由于若是看不见任何东西 – 那么你又如何知道你的程序代码在工做呢?超过 50% 的 CPU处理时间花费在渲染器上面； 一般也是在这个部分，游戏开发者将会受到最苛刻的评判。若是咱们在这个部分表现不好，事情将会变得很是糟糕， 咱们的程序技术，咱们的游戏和咱们的公司将在 10天以内变成业界的笑话。 它也是咱们最依赖于外部厂商和力量的地方，在这里他们将处理最大限度的潜在操做目标。如此说来， 建造一个渲染器确实不象听起来那么吸引人（事实如此），但若是没有一个好的渲染器， 游戏或许永远不会跻身于排行榜前10名。

　　现在，在屏幕上生成像素，涉及到 3D加速卡， API ，三维空间数学，对 3D 硬件如何工做的理解等等。对於主机（游戏机）游戏来讲，也须要相同类型的知识，可是至少对于主机，你没必要去尝试击中一个移动中的目标。 由于一台主机的硬件配置是固定的 "时间快照"，和PC（我的计算机）不一样， 在一台主机的生命期中，它的硬件配置不会改变。

　　在通常意义上，渲染器的工做就是要创造出游戏的视觉闪光点，实际上达到这个目标须要大量的技巧。3D图形本质上是用最少的努力创造出最大效果的一门艺术，由于额外的 3D 处理在处理器时间和和內存带宽方面都是极为昂贵的。它也是一种预算， 要弄清楚你想在什么地方花费处理器时间，而你宁愿在什么地方节省一些从而达到最好的总体效果。接下来咱们将会介绍一些这方面的工具，以及怎样更好的用它们让游戏引擎工做。

建造3D世界
　　最近，当我和一位从事计算机图形方面工做长达数年之久的人会谈时，她向我吐露道， 当她第一次看到实时操纵计算机 3D图象时， 她不知道这是怎么实现的， 也不知道计算机如何可以存储 3D图象。 今天这对于在大街上的普通人来讲或许是真实的，即便他们时常玩 PC游戏， 游戏机游戏， 或街机游戏。

　　下面咱们将从游戏设计者的角度讨论创造 3D世界的一些细节，你也应该看一看 Dave Salvator 所写的“3D管线导论“，以便对3D图象生成的主要过程有一个总体的了解。

　　3D 物体（对象）被储存成 3D世界中的一系列点(被称为顶点)，彼此之间有相互关系，因此计算机知道如何在世界中的这些点之间画线或者是填充表面。 一个立方体由8个点组成，每一个角一个点。立方体有6个表面，分别表明它的每个面。 这就是 3D对象储存的基础。 对于一些比较复杂的 3D物体， 好比说一个 Quake 的关卡，将有数以千计(有时数以十万计)的顶点，和数以千计的多边形表面。

　　参见上图的线框表示（注：原文在这里有一幅图）。 本质上与上面的立方体例子相似， 它仅仅是由许许多多的小多边形组成的一些复杂场景。模型和世界如何储存是渲染器的一部份功能，而不属于应用程序/游戏部份。 游戏逻辑不须要知道对象在內存中如何表示， 也不须要知道渲染器将怎样把他们显示出来。游戏只是须要知道渲染器将使用正确的视野去表示对象， 并将在正确的动画幀中把正确的模型显示出来。

　　在一个好的引擎中，渲染器应该是能够彻底被一个新的渲染器替换掉，而且不须要去改动游戏的一行代码。许多跨平台引擎， 并且许多自行开发的游戏机引擎就是这样的，如 Unreal引擎， --举例来讲， 这个游戏 GameCube 版本的渲染器就能够被你任意的替换掉。

　　让咱们再看看内部的表示方法—除了使用坐标系统，还有其余方法能够在计算机內存里表示空间的点。在数学上，你能够使用一个方程式来描述直线或曲线，并获得多边形， 而几乎全部的 3D显示卡都使用多边形来做为它们的最终渲染图元。 一个图元就是你在任何显示卡上面所能使用的最低级的绘制（渲染）单位，几乎全部的硬件都是使用三个顶点的多边形(三角形)。新一代的 nVidia 和 ATI显卡能够容许你以数学方式渲染(被称为高次表面)，但由于这不是全部图形卡的标准， 你还不能靠它做为渲染策略。

　　从计算的角度来看，这一般有些昂贵，但它时常是新的实验技术的基础，例如，地表的渲染，或者对物件锐利的边缘进行柔化。咱们将会在下面的曲面片小节中更进一步介绍这些高次表面。

剔除概观
　　问题来了。 我如今有一个由几十万个顶点/多边形描述的世界。我以第一人称视角位于咱们这个 3D 世界的一边。在视野中能够看见世界的一些多边形， 而另一些则不可见， 由于一些物体， 好比一面看得见的墙壁， 遮挡住了它们。即便是最好的游戏编码人员， 在目前的 3D显卡上， 在一个视野中也不能处理 300，000个三角形且仍然维持 60fps (一个主要目标)。显卡不能处理它， 所以咱们必须写一些代码，在把它们交给显卡处理以前除去那些看不见的多边形。这个过程被称为剔除。

　　有许多不一样的剔除方法。 在深刻了解这些以前，让咱们探讨一下为何图形显示卡不能处理超高数量的多边形。我是说，最新的图形卡每秒钟不能处理几百万个多边形吗？它不该该可以处理吗? 首先，你必须理解市场销售宣称的多边形生成率和真实世界的多边形生成率。 行销上宣称的多边形生成率是图形显示卡理论上可以达到的多边形生成率。

　　若是所有多边形都在屏幕上， 相同的纹理，相同的尺寸大小，正在往显示卡上传送多边形的应用程序除了传送多边形之外什么也不作， 这时显卡能处理多少多边形数量，就是图形芯片厂商呈现给你的数字。

　　然而，在真实的游戏情形中，应用程序时常在后台作着许多其余的事情 --多边形的 3D 变换， 光照计算， 拷贝较多的纹理到显卡內存， 等等。不只纹理要送到显示卡， 并且还有每一个多边形的细节。一些比较新的显卡容许你实际上在显卡內存自己里面储存模型/世界几何细节，但这多是昂贵的，将会耗光纹理正常能够使用的空间，因此你最好能肯定每一幀都在使用这些模型的顶点， 不然你只是在浪费显示卡上的存储空间。 咱们就说到这里了。 重要的是，在实际使用显卡时，并没必要然就能达到你在显卡包装盒上所看到的那些指标，若是你有一个比较慢速的CPU， 或没有足够的內存时，这种差别就尤其真实。

基本的剔除方法
　　最简单的剔除方式就是把世界分红区域， 每一个区域有一个其余可见区域的列表。那样， 你只须要显示针对任何给定点的可见部分。 如何生成可见视野区域的列表是技巧所在。 再者， 有许多方法能够用来生成可见区域列表，如 BSP 树， 窥孔等等。

　　能够确定，当谈论 DOOM或 QUAKE 时，你已经听到过使用 BSP这个术语了。 它表示二叉空间分割。

　　BSP 是一种将世界分红小区域的的方法，经过组织世界的多边形，容易肯定哪些区域是可见的而哪些是不可见的 –从而方便了那些不想作太多绘制工做的基于软件的渲染器。它同时也以一种很是有效的方式让你知道你位于世界中的什么地方。

　　在基于窥孔的引擎 ( 最先由 3D Realms 已经取消的 Prey项目引入游戏世界 )里，每一个区域( 或房间) 都建造有本身的模型，经过每一个区域的门 ( 或窥孔 )可以看见另外的区段。渲染器把每一个区域做为独立的场景单独绘制。 这就是它的大体原理。足以说这是任何一个渲染器的必需部份，并且很是重要。

　　尽管一些这样的技术归类在 "遮挡剔除"之下，可是他们所有都有一样的目的:尽早消除没必要要的工做。 对於一个FPS游戏(第一人称射击游戏)来讲，视野中时常有许多三角形，并且游戏玩家承担视野的控制，丢弃或者剔除不可见的三角形就是绝对必要的了。 对空间模拟来讲也是这样的， 你能够看见很远很远的地方 –剔除超过视觉范围外面的东西就很是重要。 对于视野受到限制的游戏来讲 –好比 RTS (即时战略类游戏)--一般比较容易实现。一般渲染器的这个部份仍是由软件来完成， 而不是由显卡完成，由显卡来作这部分工做只是一个时间问题。

基本的图形管线流程
　　一个简单的例子，从游戏到多边形绘制的图形管线过程大体是这样:
　　　　· 游戏决定在游戏中有哪些对象，它们的模型， 使用的纹理， 他们可能在什么动画幀，以及它们在游戏世界里的位置。游戏也决定照相机的位置和方向。

　　　　· 游戏把这些信息传递给渲染器。以模型为例，渲染器首先要查看模型的大小 ，照相机的位置， 然後决定模型在屏幕上是否所有可见， 或者在观察者 (照相机视野)的左边，在观察者的后面，或距离很远而不可见。它甚至会使用一些世界测定方式来计算出模型是不是可见的。 (参见下面这条)

　　　　· 世界可视化系统决定照相机在世界中的位置，并根据照相机视野决定世界的哪些区域 /多边形是可见的。有许多方法能够完成这个任务， 包括把世界分割成许多区域的暴力方法，每一个区域直接为"我能从区域 D看见区域 AB & C"， 到更精致的 BSP(二叉空间分割)世界。全部经过这些剔除测试的多边形被传递给多边形渲染器进行绘制。

　　　　· 对於每个被传递给渲染器的多边形，渲染器依照局部数学 ( 也就是模型动画)和世界数学(相对于照相机的位置?)对多边形进行变换，并检查决定多边形是否是背对相机 (也就是远离照相机)。背面的多边形被丢弃。非背面的多边形由渲染器根据发现的附近灯光照亮。而后渲染器要看多边形使用的纹理，而且肯定 API/图形卡正在使用那种纹理做为它的渲染基础。 在这里，多边形被送到渲染 API，而后再送给显卡。

　　很明显这有些过度简单化了，但你大概理解了。 下面的图表摘自Dave Salvator's 3D 管线一文，能够给你多一些具体细节:

　　3D 管线
　　- 高层的概观
　　　[来源：GameRes.com]1.应用程序/ 场景
　　·场景/几何数据库遍历
　　·对象的运动，观察相机的运动和瞄准
　　·对象模型的动画运动
　　·3D 世界内容的描述
　　·对象的可见性检查，包括可能的遮挡剔除
　　·细节层次的选择 (LOD)

　　2. 几何
　　·变换 (旋转，平移，缩放)
　　·从模型空间到世界空间的变换 (Direct3D)
　　·从世界空间到观察空间变换
　　·观察投影
　　·细节接受/拒绝 剔除
　　·背面剔除 (也能够在后面的屏幕空间中作)
　　光照
　　·透视分割 -变换到裁剪空间
　　·裁剪
　　·变换到屏幕空间

　　3. 三角形生成
　　·背面剔除 (或者在光照计算以前的观察空间中完成)
　　·斜率/角度计算
　　·扫瞄线变换

　　4. 渲染 /光栅化
　　·着色
　　·纹理
　　·雾
　　·Alpha 透明测试
　　·深度缓冲
　　·抗锯齿 (可选择的)
　　·显示

　　一般你会把全部的多边形放到一些列表内， 然後根据纹理对这个列表排序(这样你只须要对显卡传送一次纹理，而不是每一个多边形都传送一次)， 等等。在过去，会把多边形按照它们到相机的距离进行排序，首先绘制那些距离相机最远的多边形， 但如今因为 Z缓冲的出现，这种方法就不是那么重要了。 固然那些透明的多边形要除外，它们要在全部的非半透明多边形绘制以后才可以绘制，这样一来，全部在它们后面的多边形就能正确地在场景中显现出来。 固然，象那样，实际上你必须得从后到前地绘制那些多边形。但时常在任何给定的 FPS 游戏场景中，一般没有太多透明的多边形。 它可能看起来像有，但实际上与那些不透明的多边形相比，其比率是至关低的。

　　一旦应用程序将场景传递到 API， API就能利用硬件加速的变换和光照处理 (T&L)，这在现在的 3D 显卡中是很日常的事情。这里不讨论涉及到的矩阵数学(参见Dave的 3D管线导论)，几何变换容许 3D显卡按照你的尝试，根据相机在任什么时候间的位置和方向，在世界的正确角度和位置绘制多边形。

　　对于每一个点或顶点都有大量的计算， 包括裁剪运算，决定任何给定的多边形其实是否可见，在屏幕上彻底不可见或部分可见。光照运算，计算纹理色彩明亮程度，这取决于世界的灯光从什么角度如何投射到顶点上。 过去，处理器处理这些计算，但如今，当代图形硬件就能为你作这些事情，这意谓着你的处理器能够去作其余的事情了。很明显这是件好事情 (tm) ，因为不能期望市面上全部的 3D 显卡板上都有T & L，因此不管如何你本身将必须写全部的这些例程 (再一次从游戏开发者角度来讲)。你将在本文各处的不一样段落看到 "好事情 ( tm)"这个词汇。 我认为，这些特征为使游戏看起来更好做出了很是有用的贡献。绝不使人吃惊，你也将会看见它的对立面；你猜到了，那就是“坏事情 (tm)”。我正在尝试争取这些词汇的版权， 你要使用他们就得支付一笔小小的费用哟。

曲面片（高次表面）
　　除了三角形，曲面片的使用如今正变得更广泛。 由于他们能用数学表达式来描述几何 (一般涉及某种曲线的几何形体) ，而不只仅只是列出大量的多边形以及在游戏世界中的位置，因此曲面片 ( 高次表面的另外一个名称)很是好。 这样，你实际上就可以动态地根据方程式来创建(和变形 )多边形网格， 并决定你实际想要从曲面片上看到的多边形数量。 所以，举例来讲，你能够描述一个管道，而后在世界中就能够有这种管道的许多样例。 在一些房间中， 你已经显示了 10，000个多边形，你能够说，"由于咱们已经显示了大量的多边形，并且任何更多的多边形将会使幀速率降低，因此这个管道应该只有 100 个多边形"。但在另一个房间中， 视野中只有 5，000个可见的多边形，你能够说，"由于咱们尚未达到预算能够显示的多边形数量， 因此，如今这个管道能有 500个多边形"。 很是美妙的东西 --但你必须首先知道全部这些，并创建网格，这不是无足轻重的。经过 AGP 传送同一个对象的曲面方程确实要比传送其大量顶点节省成本。 SOF2就使用了这个方法的一种变体来创建它的地表系统。

　　事实上如今的 ATI 显卡具备 TruForm， 它能带一个以三角形为基础的模型，并将该模型转换为基于高次表面的模型，使其平滑 —接着再用十倍三角形数量把模型转换回基于大量三角形的模型 (被称为retesselation)。而后模型送往管线作进一步的处理。实际上 ATI 仅仅在 T & L引擎以前增长了一个阶段来处理这个过程。这里的缺点是，要控制哪些模型须要被平滑处理而哪些又不须要。你经常想要一些边缘比较尖锐，好比鼻子，但它却被不恰当的平滑过了。 这仍然是一种很好的技术，并且我能预见它在未来会被更多的应用。

　　这就是第一部份 -- 咱们将会在第二部分继续介绍光照和纹理，下面的章节会更加深刻。

第2部份: 3D环境的光照和纹理

世界的灯光
　　在变换过程当中， 一般是在称为观察空间的坐标空间中， 咱们遇到了最重要的运算之一: 光照计算。 它是一种这样的事情， 当它工做时，你不关注它，但当它不工做时， 你就很是关注它了。有不少不一样的光照方法，从简单的计算多边形对于灯光的朝向，并根据灯光到多边形的方向和距离加上灯光颜色的百分比值，一直到产生边缘平滑的灯光贴图叠加基本纹理。并且一些 API实际上提供预先建造的光照方法。举例来讲，OpenGL 提供了每多边形，每顶点，和每像素的光照计算。

　　在顶点光照中，你要决定一个顶点被多少个多边形共享，并计算出共享该顶点的全部多边形法向量的均值（称为法向量），并将该法向量赋顶点。一个给定多边形的每一个顶点会有不一样的法向量，因此你须要渐变或插值多边形顶点的光照颜色以便获得平滑的光照效果。你没有必要用这种光照方式查看每一个单独的多边形。 这种方式的优势是时常能够使用硬件转换与光照（T & L）来帮助快速完成。不足之处是它不能产生阴影。 举例来讲，即便灯光是在模型的右侧，左手臂应该在被身体投影的阴影中，而实际上模型的双臂却以一样的方式被照明了。

　　这些简单的方法使用着色来达到它们的目标。 当用平面光照绘制一个多边形时， 你让渲染（绘制）引擎把整个多边形都着上一种指定的颜色。这叫作平面着色光照。 (该方法中，多边形均对应一个光强度，表面上全部点都用相同的强度值显示，渲染绘制时获得一种平面效果，多边形的边缘不能精确的显示出来)。

　　对于顶点着色 ( Gouraud着色) ，你让渲染引擎给每一个顶点赋予特定的颜色。在绘制多边形上各点投影所对应的像素时，根据它们与各顶点的距离，对这些顶点的颜色进行插值计算。 (实际上Quake III模型使用的就是这种方法， 效果好的使人惊奇)。

　　还有就是 Phong 着色。如同 Gouraud 着色，经过纹理工做，但不对每一个顶点颜色进行插值决定像素颜色值，它对每一个顶点的法向量进行插值，会为每一个顶点投影的像素作相同的工做。对于 Gouraud着色，你须要知道哪些光投射在每一个顶点上。对于 Phong 着色，你对每一个像素也要知道这么多。

　　一点也不使人惊讶， Phong着色能够获得更加平滑的效果，由于每一个像素都须要进行光照计算，其绘制很是耗费时间。平面光照处理方法很快速， 但比较粗糙。Phong 着色比 Gouraud着色计算更昂贵，但效果最好，能够达到镜面高光效果("高亮")。这些都须要你在游戏开发中折衷权衡。

不一样的灯光
　　接着是生成照明映射，你用第二个纹理映射（照明映射）与已有的纹理混合来产生照明效果。这样工做得很好， 但这本质上是在渲染以前预先生成的一种罐装效果。若是你使用动态照明 (即，灯光移动，或者没有程序的干预而打开和关闭)，你得必须在每一幀从新生成照明映射，按照动态灯光的运动方式修改这些照明映射。灯光映射可以快速的渲染，但对存储这些灯光纹理所需的内存消耗很是昂贵。你能够使用一些压缩技巧使它们占用较少的的内存空间，或减小其尺寸大小，甚至使它们是单色的 (这样作就不会有彩色灯光了)，等等。若是你确实在场景中有多个动态灯光， 从新生成照明映射将以昂贵的CPU周期而了结。

　　许多游戏一般使用某种混合照明方式。 以Quake III为例，场景使用照明映射，动画模型使用顶点照明。 预先处理的灯光不会对动画模型产生正确的效果 --整个多边形模型获得灯光的所有光照值 -- 而动态照明将被用来产生正确的效果。使用混合照明方式是多数的人们没有注意到的一个折衷，它一般让效果看起来"正确"。这就是游戏的所有 – 作一切必要的工做让效果看起来"正确"，但没必要真的是正确的。

　　固然，全部这些在新的Doom引擎里面都不复存在了，但要看到全部的效果，至少须要 1GHZ CPU和 GeForce 2 显卡。是进步了，但一切都是有代价的。

　　一旦场景通过转换和照明， 咱们就进行裁剪运算。不进入血淋淋的细节而，剪断运算决定哪些三角形彻底在场景 (被称为观察平截头体)以内或部份地在场景以内。彻底在场景以内的三角形被称为细节接受，它们被处理。对于只是部分在场景以内的三角形， 位于平截头体外面的部分将被裁剪掉，余下位于平截头体内部的多边形部分将须要从新闭合，以便其彻底位于可见场景以内。 (更多的细节请参考咱们的 3D流水线指导一文)。

　　场景通过裁剪之后，流水线中的下一个阶段就是三角形生成阶段(也叫作扫描线转换)，场景被映射到2D屏幕坐标。到这里，就是渲染（绘制）运算了。

纹理与MIP映射
　　纹理在使3D场景看起来真实方面异常重要，它们是你应用到场景区域或对象的一些分解成多边形的小图片。多重纹理耗费大量的内存，有不一样的技术来帮助管理它们的尺寸大小。纹理压缩是在保持图片信息的状况下，让纹理数据更小的一种方法。纹理压缩占用较少的游戏CD空间，更重要的是，占用较少内存和3D显卡存储空间。另外，在你第一次要求显卡显示纹理的时候，压缩的(较小的)版本通过 AGP 接口从 PC主存送到3D 显卡， 会更快一些。纹理压缩是件好事情。 在下面咱们将会更多的讨论纹理压缩。

MIP 映射（多纹理映射）
　　游戏引擎用来减小纹理内存和带宽需求的另一个技术就是 MIP 映射。 MIP映射技术经过预先处理纹理，产生它的多个拷贝纹理，每一个相继的拷贝是上一个拷贝的一半大小。为何要这样作?要回答这个问题，你须要了解 3D显卡是如何显示纹理的。最坏状况，你选择一个纹理，贴到一个多边形上，而后输出到屏幕。咱们说这是一对一的关系，最初纹理映射图的一个纹素 (纹理元素)对应到纹理映射对象多边形的一个像素。若是你显示的多边形被缩小一半，纹理的纹素就每间隔一个被显示。这样一般没有什么问题 --但在某些状况下会致使一些视觉上的怪异现象。让咱们看看砖块墙壁。 假设最初的纹理是一面砖墙，有许多砖块，砖块之间的泥浆宽度只有一个像素。若是你把多边形缩小一半，纹素只是每间隔一个被应用，这时候，全部的泥浆会忽然消失，由于它们被缩掉了。你只会看到一些奇怪的图像。

　　使用 MIP 映射，你能够在显示卡应用纹理以前，本身缩放图像，由于能够预先处理纹理，你作得更好一些，让泥浆不被缩掉。当 3D显卡用纹理绘制多边形时，它检测到缩放因子，说，"你知道，我要使用小一些的纹理，而不是缩小最大的纹理，这样看起来会更好一些。"在这里， MIP 映射为了一切，一切也为了 MIP映射。

多重纹理与凹凸映射
　　单一纹理映射给整个3D 真实感图形带来很大的不一样，但使用多重纹理甚至能够达到一些更加使人难忘的效果。过去这一直须要多遍渲染（绘制），严重影响了像素填充率。 但许多具备多流水线的3D 加速卡，如ATI's Radeon和 nVidia's GeForce 2及更高级的显卡，多重纹理能够在一遍渲染（绘制）过程当中完成。产生多重纹理效果时， 你先用一个纹理绘制多边形，而后再用另一个纹理透明地绘制在多边形上面。这让你能够使纹理看上去在移动，或脉动，甚至产生阴影效果 (咱们在照明一节中描述过)。绘制第一个纹理映射，而后在上面绘制带透明的全黑纹理，引发一种是全部的织法黑色的可是有一个透明分层堆积过它的顶端， 这就是 -- 即时阴影。 该技术被称为照明映射 ( 有时也称为 暗映射)，直至新的Doom，一直是Id引擎里关卡照明的传统方法。

　　凹凸贴图是最近涌现出来的一种古老技术。几年之前 Matrox第一个在流行的 3D 游戏中发起使用各类不一样形式的凹凸贴图。就是生成纹理来表现灯光在表面的投射，表现表面的凹凸或表面的裂缝。凹凸贴图并不随着灯光一块儿移动 -- 它被设计用来表现一个表面上的细小瑕疵，而不是大的凹凸。好比说，在飞行模拟器中，你能够使用凹凸贴图来产生像是随机的地表细节，而不是重复地使用相同的纹理，看上去一点趣味也没有。

　　凹凸贴图产生至关明显的表面细节，尽管是很高明的戏法，但严格意义上讲，凹凸贴图并不随着你的观察角度而变化。比较新的 ATI和 nVidia 显卡片能执行每像素运算，这种缺省观察角度的不足就真的再也不是有力而快速的法则了。不管是哪种方法， 到目前为止，没有游戏开发者太多的使用；更多的游戏可以且应该使用凹凸贴图。

高速缓存抖动 = 糟糕的事物
　　纹理高速缓存的管理游戏引擎的速度相当重要。 和任何高速缓存同样，缓存命中很好，而不命中将很糟糕。若是遇到纹理在图形显示卡内存被频繁地换入换出的状况，这就是纹理高速缓存抖动。发生这种状况时，一般API将会废弃每一个纹理，结果是全部的纹理在下一幀将被从新加载，这很是耗时和浪费。对游戏玩家来讲，当API从新加载纹理高速缓存时，会致使幀速率迟钝。

　　在纹理高速缓存管理中，有各类不一样的技术将纹理高速缓存抖动减到最少 –这是确保任何 3D 游戏引擎速度的一个决定性因素。纹理管理是件好事情 – 这意味着只要求显卡使用纹理一次，而不是重复使用。这听起来有点自相矛盾，但效果是它意谓着对显卡说，"看，全部这些多边形所有使用这一个纹理，咱们可以仅仅加载这个纹理一次而不是许屡次吗?" 这阻止API ( 或图形驱动软件)上传屡次向显卡加载纹理。象OpenGL这样的API实际上一般处理纹理高速缓存管理，意谓着，根据一些规则，好比纹理存取的频率，API决定哪些纹理储存在显卡上，哪些纹理存储在主存。真正的问题来了：a) 你时常没法知道API正在使用的准确规则。 b)你时常要求在一幀中绘制更多的纹理，以至超出了显卡内存空间所能容纳的纹理。

　　另一种纹理高速缓存管理技术是咱们早先讨论的纹理压缩。很象声音波形文件被压缩成 MP3文件，尽管没法达到那样的压缩比率，但纹理能够被压缩。 从声音波形文件到MP3的压缩能够达到 11:1的压缩比率，而绝大多数硬件支持的纹理压缩运算法则只有 4:1的压缩比率，尽管如此，这样能产生很大的差异。 除此以外，在渲染（绘制）过程当中，只有在须要时，硬件才动态地对纹理进行解压缩。这一点很是棒，咱们仅仅擦除即将可能用到的表面。

　　如上所述，另一种技术确保渲染器要求显卡对每一个纹理只绘制一次。肯定你想要渲染（绘制）的使用相同纹理的全部多边形同时送到显卡，而不是一个模型在这里，另外一个模型在那里，而后又回到最初的纹理论。仅仅绘制一次，你也就经过AGP接口传送一次。Quake III在其阴影系统就是这么作的。处理多边形时，把它们加入到一个内部的阴影列表，一旦全部的多边形处理完毕，渲染器遍历纹理列表，就将纹理及全部使用这些纹理的多边形同时传送出去。

　　上述过程在使用显卡的硬件 T & L（若是支持的话）时，并不怎么有效。你面临的结局是，满屏幕都是使用相同纹理的大量的多边形小群组，全部多边形都使用不一样的变换矩阵。这意谓着更多的时间花在创建显卡的硬件 T & L引擎 ，更多的时间被浪费了。 不管如何，由于他们有助于对整个模型使用统一的纹理，因此它对实际屏幕上的模型能够有效地工做。可是由于许多多边形倾向使用相同的墙壁纹理，因此对于世界场景的渲染，它经常就是地狱。一般它没有这么严重，由于大致而言，世界的纹理不会有那么大，这样一来API的纹理缓存系统将会替你处理这些，并把纹理保留在显卡以备再次使用。

　　在游戏机上，一般没有纹理高速缓存系统(除非你写一个)。在 PS2上面，你最好是远离"一次纹理"的方法。在 Xbox 上面， 这是不重要的，由于它自己没有图形内存(它是 UMA体系结构)，且全部的纹理不管如何始终保留在主存之中。

　　事实上，在今天的现代PC FPS游戏中，试图经过AGP接口传送大量纹理是第二个最一般的瓶颈。最大的瓶颈是实际几何处理，它要使东西出如今它应该出现的地方。在现在的3D FPS游戏中，最耗费时间的工做，显然是那些计算模型中每一个顶点正确的世界位置的数学运算。若是你不把场景的纹理保持在预算以内，仅居其次的就是经过AGP接口传送大量的纹理了。然而，你确实有能力影响这些。经过下降顶层的 MIP 级别(还记得系统在哪里不断地为你细分纹理吗?)，你就可以把系统正在尝试送到显卡的纹理大小减小一半。你的视觉质量会有所降低-- 尤为是在引人注目的电影片段中--可是你的幀速率上升了。这种方式对网络游戏尤为有帮助。实际上，Soldier of Fortune II和Jedi Knight II: Outcast这两款游戏在设计时针对的显卡还不是市场上的大众主流显卡。为了以最大大小观看他们的纹理，你的3D显卡至少须要有128MB的内存。这两种产品在思想上都是给将来设计的。

　　上面就是第 2 部份。在下面章节中，咱们将介绍许多主题，包括内存管理，雾效果，深度测试， 抗锯齿，顶点着色，API等。

第3部份:内存使用，特效和API

关于内存使用的思考
　　让咱们想想，在今天其实是如何使用3D 显卡内存的以及在未来又会如何使用。现在绝大多数3D显卡处理32位像素颜色，8位红色， 8位蓝色，8位绿色，和 8 位透明度。这些组合的红，蓝和绿256个色度，能够组成 16。7百万种颜色-- 那是你我能够在一个监视器上看见的全部颜色。

　　那么，游戏设计大师John Carmack为何要求 64 位颜色分辨率呢?若是咱们看不出区别，又有什么意义呢? 意义是:好比说， 有十几个灯光照射模型上的点，颜色颜色各不相同。 咱们取模型的最初颜色，而后计算一个灯光的照射，模型颜色值将改变。 而后咱们计算另外的一个灯光，模型颜色值进一步改变。 这里的问题是，由于颜色值只有8位，在计算了4个灯光以后，8位的颜色值将不足以给咱们最后的颜色较好的分辨率和表现。分辨率的不足是由量化偏差致使的，本质缘由是因为位数不足引发的舍入偏差。

　　你能很快地用尽位数，并且一样地，全部的颜色被清掉。每颜色16或 32 位，你有一个更高分辨率，所以你可以反复着色以适当地表现最后的颜色。这样的颜色深度很快就能消耗大量的存储空间。咱们也应提到整个显卡内存与纹理内存。这里所要说的是，每一个3D显卡实际只有有限的内存，而这些内存要存储前端和后端缓冲区，Z 缓冲区，还有全部的使人惊奇的纹理。最初的 Voodoo1显卡只有2MB显存，后来 Riva TNT提升到16MB显存。而后 GeForce和 ATI Rage有32MB显存，如今一些 GeForce 2 到 4的显卡和 Radeons带有 64MB 到128MB的显存。 这为何重要? 好吧，让咱们看一些数字…

　　好比你想让你的游戏看起来最好，因此你想要让它以32位屏幕， 1280x1024分辨率和32位 Z-缓冲跑起来。 好，屏幕上每一个像素4个字节，外加每一个像素4字节的Z-缓冲，由于都是每像素32位。咱们有1280x1024个像素 – 也就是 1，310，720个像素。基于前端缓冲区和Z-缓冲区的字节数，这个数字乘以8，是 10，485，760字节。包括一个后端缓冲区，这样是 1280x1024x12，也就是 15，728，640字节， 或 15MB。在一个 16MB 显存的显卡上，就只给咱们剩下1MB来存储全部的纹理。 如今若是最初的纹理是真32位或 4字节宽，那么咱们每幀能在显卡上存储 1MB/4字节每像素 = 262，144个像素。这大约是4个 256x256 的纹理页面。

　　很清楚，上述例子代表，旧的16MB显卡没有现代游戏表现其绚丽画面所须要的足够内存。很明显，在它绘制画面的时候，咱们每幀都必须从新把纹理装载到显卡。实际上，设计AGP总线的目的就是完成这个任务，不过， AGP仍是要比 3D 掀卡的幀缓冲区慢，因此你会受到性能上的一些损失。很明显，若是纹理由32位下降到16位，你就可以经过AGP以较低的分辨率传送两倍数量的纹理。若是你的游戏以每一个像素比较低的色彩分辨率跑，那么就能够有更多的显示内存用来保存经常使用的纹理 (称为高速缓存纹理)。 但实际上你永远不可能预知使用者将如何设置他们的系统。若是他们有一个在高分辨率和颜色深度跑的显卡，那么他们将会更可能那样设定他们的显卡。

雾
　　咱们如今开始讲雾,它是某种视觉上的效果。现在绝大多数的引擎都能处理雾，由于雾很是方便地让远处的世界淡出视野，因此当模型和场景地理越过观察体后平面进入视觉范围内时，你就不会看见它们忽然从远处跳出来了。也有一种称为体雾的技术。这种雾不是随物体离照相机的距离而定,它其实是一个你能看见的真实对象，而且能够穿越它，从另一侧出去 --当你在穿越对象的时候，视觉上雾的可见程度随着变化。想象一下穿过云团 -- 这是体雾的一个完美例子。体雾的一些好的实现例子是Quake III一些关卡中的红色雾，或新的Rogue Squadron II之 Lucas Arts的 GameCube版本。其中有一些是我曾经见过的最好的云--大约与你能看见的同样真实。

　　在咱们讨论雾化的时候,多是简短介绍一下 Alpha测试和纹理Alpha混合的好时机。当渲染器往屏幕上画一个特定像素时，假定它已经经过 Z-缓冲测试 (在下面定义)，咱们可能最后作一些Alpha测试。咱们可能发现为了显示像素后面的某些东西，像素须要透明绘制。这意味着咱们必须取得像素的已有值，和咱们新的像素值进行混和，并把混合结果的像素值放回原处。这称为读-修改-写操做,远比正常的像素写操做费时。

　　你能够用不一样类型的混合，这些不一样的效果被称为混合模式。直接Alpha混合只是把背景像素的一些百分比值加到新像素的相反百分比值上面。还有加法混合，将旧像素的一些百分比,和特定数量(而不是百分比)的新像素相加。这样效果会更加鲜明。 (Kyle'sLightsaber在 Jedi Knight II中的效果)。

　　每当厂商提供新的显卡时，咱们能够获得硬件支持的更新更复杂的混合模式，从而制做出更多更眩目的效果。GF3+4和最近的Radeon显卡提供的像素操做，已经到了极限。

模板阴影与深度测试
　　用模板产生阴影效果，事情就变得复杂而昂贵了。这里不讨论太多细节（能够写成一篇单独的文章了），其思想是，从光源视角绘制模型视图，而后用这个把多边形纹理形状产生或投射到受影响的物体表面。

　　实际上你是在视野中投射将会“落”在其余多边形上面的光体。最后你获得看似真实的光照，甚至带有视角在里面。由于要动态建立纹理，并对同一场景进行多遍绘制，因此这很昂贵。

　　你能用众多不一样方法产生阴影，情形时常是这样一来，渲染质量与产生效果所须要的渲染工做成比例。有所谓的硬阴影或软阴影之分，然后者较好，由于它们更加准确地模仿阴影一般在真实世界的行为。一般有一些被游戏开发者偏心的“足够好”的方法。如要更多的了解阴影，请参考 Dave Salvator的 3D流水线一文。

深度测试
　　如今咱们开始讨论深度测试， 深度测试丢弃隐藏的像素，过分绘制开始起做用。过分绘制很是简单 –在一幀中，你数次绘制一个像素位置。它以3D场景中Z（深度）方向上存在的元素数量为基础，也被称为深度复杂度。若是你经常太多的过分绘制， --举例来讲, 符咒的眩目视觉特效，就象Heretic II，能让你的幀速率变得很糟糕。当屏幕上的一些人们彼此施放符咒时，Heretic II设计的一些最初效果形成的情形是，他们在一幀中对屏幕上每一个相同的像素画了40次!不用说，这必须调整，尤为是软件渲染器，除了将游戏下降到象是滑雪表演外，它根本不能处理这样的负荷。深度测试是一种用来决定在相同的像素位置上哪些对象在其它对象前面的技术，这样咱们就可以避免绘制那些隐藏的对象。

　　看着场景并想一想你所看不见的。 换句话说，是什么在其余场景对象前面,或者隐藏了其余场景对象?是深度测试做出的这个决定。

　　我将进一步解释深度深度如何帮助提升幀速率。想像一个很琐细的场景，大量的多边形 (或像素)位于彼此的后面，在渲染器得到他们之间没有一个快速的方法丢弃他们。对非Alpha混合的多边形分类排序(在Z- 方向上)，首先渲染离你最近的那些多边形，优先使用距离最近的像素填充屏幕。因此当你要渲染它们后面的像素（由Z或者深度测试决定）时，这些像素很快被丢弃，从而避免了混合步骤并节省了时间。若是你从后到前绘制，全部隐藏的对象将被彻底绘制，而后又被其余对象彻底重写覆盖。场景越复杂，这种状况就越糟糕，因此深度测试是个好东西。

抗锯齿
　　让咱们快速的看一下抗锯齿。当渲染单个多边形时，3D 显卡仔细检查已经渲染的，并对新的多边形的边缘进行柔化，这样你就不会获得明显可见的锯齿形的像素边缘。两种技术方法之一一般被用来处理。第一种方法是单个多边形层次，须要你从视野后面到前面渲染多边形，这样每一个多边形都能和它后面的进行适当的混合。若是不按序进行渲染，最后你会看见各类奇怪的效果。在第二种方法中，使用比实际显示更大的分辩率来渲染整幅幀画面，而后在你缩小图像时，尖锐的锯齿形边缘就混合消失了。这第二种方法的结果不错，但由于显卡须要渲染比实际结果幀更多的像素，因此须要大量的内存资源和很高的内存带宽。

　　多数新的显卡能很好地处理这些，但仍然有多种抗锯齿模式能够供你选择，所以你能够在性能和质量之间做出折衷。对於当今流行的各类不一样抗锯齿技术的更详细讨论请参见Dave Salvator的3D 流水线一文。

顶点与像素着色
　　在结束讨论渲染技术以前，咱们快速的说一下顶点和像素着色，最近它们正引发不少关注。顶点着色是一种直接使用显卡硬件特征的方式，不使用API。举例来讲，若是显卡支持硬件 T & L，你能够用DirectX或OpenGL编程，并但愿你的顶点经过 T & L单元 (由于这彻底由驱动程序处理，因此没有办法确信)，或者你直接利用显卡硬件使用顶点着色。它们容许你根据显卡自身特征进行特别编码，你本身特殊的编码使用T & L引擎，以及为了发挥你的最大优点，显卡必须提供的其余别的特征。 事实上，如今nVidia和ATI 在他们大量的显卡上都提供了这个特征。

　　不幸的是，显卡之间表示顶点着色的方法并不一致。你不能象使用DirectX或者OpenGL那样，为顶点着色编写一次代码就能够在任何显卡上运行，这但是个坏消息。然而，由于你直接和显卡硬件交流，它为快速渲染顶点着色可能生成的效果提供最大的承诺。(如同创造很不错的特效 -- 你可以使用顶点着色以API没有提供的方式影响事物)。事实上，顶点着色正在真的将3D图形显示卡带回到游戏机的编码方式，直接存取硬件，最大限度利用系统的必须知识，而不是依靠API来为你作一切。对一些程序员来讲，会对这种编码方式感到吃惊，但这是进步代价。

　　进一步阐述，顶点着色是一些在顶点被送到显卡渲染以前计算和运行顶点效果程序或者例程。你能够在主CPU上面用软件来作这些事情，或者使用显卡上的顶点着色。为动画模型变换网格是顶点程序的主选。

　　像素着色是那些你写的例程，当绘制纹理时，这些例程就逐个像素被执行。你有效地用这些新的例程推翻了显卡硬件正常状况作的混合模式运算。这容许你作一些很不错的像素效果，好比，使远处的纹理模糊，添加炮火烟雾, 产生水中的反射效果等。一旦 ATI和 nVidia 能实际上就像素着色版本达成一致( DX9's新的高级阴影语言将会帮助促进这一目标), 我一点不惊讶DirectX和OpenGL采用Glide的方式--有帮助开始, 但最终不是把任何显卡发挥到极限的最好方法。我认为我会有兴趣观望未来。

最后（In Closing...）
　　最终，渲染器是游戏程序员最受评判的地方。在这个行业，视觉上的华丽很是重要，所以它为知道你正在作的买单。对于渲染器程序员，最坏的因素之一就是3D显卡工业界变化的速度。一天，你正在尝试使透明图像正确地工做；次日 nVidia 正在作顶点着色编程的展现。并且发展很是快，大体上，四年之前为那个时代的 3D 显卡写的代码如今已通过时了，须要所有重写。甚至John Carmack 这样描述过，他知道四年之前为充分发挥那个时期显卡的性能所写的不错的代码，现在很平凡 --所以他产生了为每一个新的id项目彻底重写渲染器的欲望。Epic的Tim Sweeney赞同 --这里是去年他给个人评论:

　　咱们已经足足花费了9个月时间来更换全部的渲染代码。最初的 Unreal被设计为软件渲染和后来扩展为硬件渲染。下一代引擎被设计为 GeForce 及更好的图形显示卡，且多边形吞吐量是Unreal Tournament的100倍。

　　这须要所有替换渲染器。很幸运，该引擎模块化程度足够好，咱们能够保持引擎的其他部分—编辑器，物理学，人工智能，网络--不改动，尽管咱们一直在以许多方式改进这些部分。

　　搭配长篇文章的短篇报导（Sidebar）：API --祝福和诅咒
　　那么什么是API? 它是应用程序编程接口,将不一致的后端用一致的前端呈现出来。举例来讲，很大程度上每种3D显示卡的3D实现方式都有所差异。然而，他们所有都呈现一个一致的前端给最终使用者或者程序员，因此他们知道他们为X 3D显示卡写的代码将会在Y 3D显示卡上面有相同的结果。好吧，无论怎样理论上是那样。大约在三年之前这多是至关真实的陈述，但自那之后，在nVidia 公司的引领下，3D显卡行业的事情发生了变化。

　　现在在PC领域，除非你正计划建造本身的软件光栅引擎，使用CPU来绘制你全部的精灵，多边形和粒子 --并且人们仍然在这样作。跟Unreal同样，Age of Empires II: Age of Kings有一个优秀的软件渲染器 –不然你将使用两种可能的图形API，OpenGL或者 DirectX之一。OpenGL是一种真正的跨平台API (使用这种API写的软件能够在Linux，Windows和MacOS上运行。)，并且有多年的历史了，为人所熟知，但也开始慢慢地显示出它的古老。 大约在四年之前，定义OpenGL驱动特征集一直是全部显示卡厂商工做的方向。

　　然而，一旦在目标达成之后，没有预先制定特征工做方向的路线图，这时候，全部的显卡开发商开始在特征集上分道扬镳，使用OpenGL扩展。

　　3dfx 创造了T-缓冲。 nVidia 努力寻求硬件变换和光照计算。Matrox努力获取凹凸贴图。等等。我之前说过的一句话，"过去几年以来，3D显示卡领域的事情发生了变化。"委婉地说明了这一切。

　　不管如何，另外一个能够选择的API是 DirectX。这受Microsoft公司控制，且在PC和 Xbox 上被完美地支持。因为明显的缘由，DirectX没有Apple或者 Linux版本。由于Microsoft控制着 DirectX，大致上它容易更好地集成在Windows里面。

　　OpenGL和DirectX之间的基本差异是前者由‘社区’拥有，然后者由Microsoft拥有。若是你想要 DirectX 为你的 3D 显示卡支持一个新的特征，那么你须要游说微软，但愿采纳你的愿望，并等待新的 DirectX发行版本。对于OpenGL，因为显示卡制造商为3D显示卡提供驱动程序，你可以经过OpenGL扩展当即得到显示卡的新特征。这是好，但做为游戏开发者，当你为游戏编码的时候，你不能期望它们很广泛。它们可能让你的游戏速度提高50%，但你不能要求别人有一块GeForce 3 来跑你的游戏。好吧，你能够这么作，但若是你想来年还在这个行业的话，这是个至关愚蠢的主意。

　　这是对这个问题极大的简单化，对我全部描述的也有各类例外状况，但这里通常的思想是很确实的。对于DirectX，在任何既定时间你容易确切地知道你能从显示卡得到的特征，若是一个特征不能得到，DirectX将会用软件模拟它(也不老是一件好事情，由于这样有时侯很是的慢，但那是另一回事)。对于OpenGL，你能够更加贴近显示卡的特征,但代价是不能肯定将会得到的准确特征。

第4部份:模型与动画，细节级别

角色建模与动画
　　你的角色模型在屏幕上看起来怎么样,怎样容易建立它们,纹理,以及动画对于现代游戏试图完成的`消除不可信`因素来讲相当重要。角色模型系统逐渐变得复杂起来,包括较高的多边形数量模型, 和让模型在屏幕上移动的更好方式。

　　现在你须要一个骨骼模型系统，有骨架和网格细节层次，单个顶点骨架的评估，骨架动画忽略，以及比赛中停留的角度忽略。而这些甚至尚未开始涉及一些你能作的很好的事情，像动画混合，骨架反向运动学（IK），和单个骨架限制，以及相片真实感的纹理。这个清单还可以继续列下去。可是真的，在用专业行话说了全部这些之后，咱们在这里真正谈论的是什么呢？让咱们看看。

　　让咱们定义一个基于网格的系统和一个骨骼动画系统做为开始。在基于网格的系统，对于每个动画幀，你要定义模型网格的每一个点在世界中的位置。举例来讲，你有一个包含200个多边形的手的模型，有 300 个顶点(注意，在顶点和多边形之间一般并非3个对1个的关系，由于大量多边形时常共享顶点 –使用条形和扇形，你能大幅减小顶点数量)。若是动画有 10幀，那么你就须要在内存中有300个顶点位置的数据。总共有300 x 10 = 3000 顶点，每一个顶点由x，y，z和颜色/alpha信息组成。你能看见这个增加起来是多么的快。Quake I，II和 III都使用了这种系统，这种系统确实有动态变形网格的能力，好比使裙子摆动，或者让头发飘动。

　　相比之下，在骨骼动画系统，网格是由骨架组成的骨骼(骨架是你运动的对象)。 网格顶点和骨架自己相关，因此它们在模型中的位置都是相对于骨架，而不是网格表明每一个顶点在世界中的位置。所以，若是你移动骨架，组成多边形的顶点的位置也相应改变。这意谓着你只必须使骨骼运动，典型状况大约有 50个左右的骨架—很明显极大地节省了内存。

骨骼动画附加的好处
　　骨骼动画的另外一个优势是可以根据影响顶点的一些骨架来分别“估价”每一个顶点。例如，双臂的骨架运动，肩，脖子并且甚至躯干都能在肩中影响网格。当你移动躯干的时候，网格就活像一个角色同样移动。总的效果是3D角色可以实现的动画更加流畅和可信，且须要更少的内存。每一个人都赢了。

　　固然这里的缺点是，若是你想要使有机的东西运动且很好，好比说头发，或者披肩，为了让它看起来天然，你最后不得不在里面放置数量惊人的骨架，这会抬高一些处理时间。

　　基于骨骼的系统能带给你的一些其余事情是‘忽略’特定层次骨架的能力-- 说,"我不关心动画想要对这块骨架所作的事情，我想要让它指向世界中的一个特定点"。这很棒。你能让模型着眼于世界中的事件，或者使他们的脚在他们站着的地面保持水平。这一切很是微妙，但它能够帮助带给场景附加的真实感。

　　在骨骼系统，你甚至能够指定"我须要把这个特别的动画用於模型的腿，而一个不一样的携枪或射击动画在模型躯干上播放，且那家伙（角色）叫喊的不一样动画效果在模型的头部播放"。很是妙。Ghoul2 (在Soldier of Fortune II:Double Helix and Jedi Knight I: Outcast中使用了Raven的动画系统 )拥有全部这些好东西，且特别被设计为容许程序员使用全部这些忽略能力。这对动画的节省像你同样难以相信。像你同样的动画上的此次救援不相信. Raven有一个角色行走的动画和一个站立开火的动画，并在它同时行走和开火形下把这两个动画合并，而不是须要一个动画表示角色行走并开火。

More Skeletons in the Closet
　　先前描述的效果能够经过具备层次的骨骼系统来完成。这是什么意思呢？意思是每块骨架实际上的位置相对于它的父亲，而不是每一个骨架直接位于空间中的地方。这意谓着若是你移动父亲骨架，那么它全部的子孙骨架也跟着移动，在代码上不须要任何额外的努力。这是让你可以在任何骨架层次改变更画，并且经过骨骼其他部分向下传递的东西。

　　建立一个没有层次的骨骼系统是可能的 --但那时你不能忽略一个骨架而且预期它工做。你所看到的只是身体上的一个骨架开始了新动画，除非你实现了某种‘向下传递信息’的系统，不然在该骨架下面的其它骨架保持原来的动画。首先由一个层次系统开始，你就自动地得到这些效果。

　　许多今天的动画系统中正开始出现一些比较新的特征，如动画混合，从一个正在播放的动画转变到另一个动画须要通过一小段时间，而不是当即从一个动画忽然转变到另一个。举例来讲，你有个角色在行走，而后他停了下来。你不是仅仅忽然地转变更画，让他的腿和脚停在无效位置，而是一秒钟混合一半，这样脚彷佛天然地移到了新的动画。不可以太高的评价这种效果 --混合是一个微妙的事情,但若是正确的运用，它真的有些差异。

反向运动学
　　反向运动学 (IK) 是被许多人们丢弃的一个专业术语，对它的真实含义没有多少概念。IK是现在游戏里面一个相对比较新的系统。使用 IK ，程序员可以移动一只手，或一条腿,模型的其他关节自动从新定位，所以模型被正肯定向。并且有模型的关节新位置的其馀者他们本身，所以模型正确的被定向。好比，你将会说,"好，手 ,去拾起桌子上的那个杯子"并指出杯子在世界中的位置。手就会移动到那里，且它后面的身体会调节其自身以便双臂移动，身体适当弯曲，等等。

　　也有和IK相反的事情，叫作前向运动学,本质上与 IK工做的次序相反。想像一只手，手附着在手臂上，手臂附着在身体上。如今想像你重重地击中了身体。一般手臂像连迦般抽动，且手臂末梢的手随之振动。 IK可以移动身体，并让其他的四肢本身以真实的方式移动。基本上它须要动画师设定每种工做的大量信息 --像关节所能经过的运动范围，若是一块骨架前面的骨架移动，那么这块骨架将移动多少百分比，等等。

　　和它如今同样，尽管很好，它是一个很大的处理问题，不用它你能够有不一样的动画组合而脱身。值得注意的是，真正的 IK解决办法须要一个层次骨骼系统而不是一个模型空间系统 -- 不然它们都耗时太多以至没法恰当地计算每一个骨架。

LOD几何系统
　　最后，咱们应当快速讨论一下与缩放模型几何复杂度相关的细节级别（LOD）系统(与讨论MIP映射时使用的LOD相对照)。假定现在绝大多数PC游戏支持的处理器速度的巨大范围，以及你可能渲染的任何给定可视场景的动态性质(在屏幕上有一个角色仍是12个？)，你一般须要一些系统来处理这样的状况，好比，当系统接近极限试图同时在屏幕上绘制出12个角色，每一个角色有3，000个多边形,并维持现实的幀速率。 LOD 被设计来协助这样的情景中。最基本的状况，它是在任何给定时间动态地改变你在屏幕上绘制的角色的多边形数量的能力。面对现实吧，当一个角色走远，也许只有十个屏幕像素高度，你真的不须要3000个多边形来渲染这个角色 --或许300个就够了，并且你很难分辨出差异。

　　一些 LOD 系统将会须要你创建模型的多个版本，并且他们将会依靠模型离观察者的接近程度来改变屏幕上的LOD级别，以及多少个多边形正被同时显示。更加复杂的系统实际上将会动态地减小屏幕上的多边形数量，在任何给定时间，任何给定的角色，动态地 -- Messiah和Sacrifice包括了这种风格的技术，尽管在CPU方面并不便宜。你必须确信，与首先简单地渲染整个事物相比，你的 LOD 系统没有花较多的时间计算出要渲染那些多边形（或不渲染）。 任一方式都将会工做，因为现在咱们试图要在屏幕上绘制的多边形数量，这是件很是必要的事情。注意， DX9将会支持硬件执行的自适应几何缩放(tessellation)。

　　归结起来是，获得一个运动流畅，其表现和移动在视觉上可信，屏幕上看起来逼真的模型。流畅的动画时常是经过手工建造动画和运动捕捉动画的组合获得。有时你仅仅手工创建了一个给定的动画 --当你在为一个模型作一些你在现实生活中不能作到的事情的动画时， 你倾向于这样作 --举例来讲，你确实不能向后弯腰，或像Mortal Kombat 4中的Lui Kang那样在行进的脚踏车上踢腿，一般运动捕捉这时候就出局了!一般运动捕捉动画 -- 实际上视频捕捉活生生的演员贯穿于你想在屏幕上所看到的动画 --是获得逼真的东西的方式。真实感的东西能使一款普通游戏看起来很棒，并且能掩饰许多事情。好比 NFL Blitz，屏幕上的模型大约有 200个多边形。它们在静止站立时看起来可怕的斑驳，一旦这些模型跑动起来它们就有快速流畅的动画，模型自身的许多丑陋消失了。眼睛容易看见的是 '逼真的'动画而不是模型自身的结构。 一个不错的模型设计师可以掩饰大多数模型缺陷。

　　我但愿这些带给你对模型和动画问题的洞察力。在第五部份中，咱们将会更加深刻3D世界的建造，讨论一些物理，运动和效果系统的东西。

第5部分:物理，运动，效果

世界建造
　　经常在创建一个含有任何3D成分的游戏时，你最终要试图创建一个将会在里面产生游戏动做的3D环境。不知怎么的游戏开发者提供了一个创建这种环境的方，它容易修改，有效率，有较低的多边形数量，对于游戏既容易渲染又容易运用物理学。很简单，对吗？当作这个的时候我用左手在作什么？当作这的时候 ,我对个人左手作什么? 是的。不错。

　　虽然那里有许多3D结构程序，从CAD/CAM程序到3D Studio Max，建造游戏世界是不一样于建造内部或外部世界的模型的尴尬。你有三角形数量问题 -- 任何给定的渲染器一次只能渲染这么多的多边形，这对于天才的关卡设计师来讲永远都不够。不知这些，你也只能每一个关卡存储预约数量的多边形，因此即便你的渲染器可以在视野中处理250，000个多边形，即便你只能在合理数量的空间中存储500，000个多边形，那么取决于你怎么处理它，最后你的关卡价值像两个房间那么小。很差。

　　任何方法，开发者须要提出一个创做工具 --最好足够灵活，容许游戏引擎须要的各类事物 – 好比，在世界中放置对象，在进入游戏之前对关卡的适当预览，以及准确的光照预览。在他们花三个小时预先处理关卡来产生一个 '引擎可消化的'格式以前 , 这些能力容许游戏开发者看到关卡将在游戏中看起来怎么样。开发者须要关于关卡，多边形数量，网格数量等等的相应数据。 他们须要一个合宜而友好的方式可以让世界有纹理背景图，容易存取多边形数量缩减工具，如此等等。这个清单能够继续列下去。

　　在先前已经存在的工具中找到这个功能是可能的。许多开发者使用Max或者Maya建造他们的关卡，但即便3D Max须要对它的功能有一些任务特定的扩展来有效率地完成关卡建造工做。甚至可能使用关卡建造工具，像QERadient（见下图），并且把它的输出从新处理成你的引擎可以解释的格式。

不能看见它? 别烦扰…
　　回想一下咱们在第一部分讨论的BSP (二叉空间分割)树，你也可能据说过潜在可视集合（PVS）这个术语正被四处谈论。二者都有相同的目标，不去探究涉及到的繁杂的数学，它是一种把世界分解为你能从世界任何给定位置看见的墙壁的最小子集的方式。在实现时，它们仅仅返回你能看见的那些，而不是那些隐藏在可能被遮挡的墙壁后面的。你能想象出这给软件渲染器带来的好处，渲染的每一个像素(多是这样的情形)极为重要。它们也按从后到前的顺序返回那些墙壁，在渲染时这是很方便的，由于你可以在渲染次序中肯定一个对象的实际位置。

　　大致而言，BSP 树最近正不受欢迎，因为它们的一些古怪，并且由于咱们从当今3D显示卡得到的像素吞吐量，再加上Z缓冲像素测试，BSP经常成了一个多余的过程。它们在计算出你在世界的确切位置和正在你周围的几何物体方面是便利的，但经常有比BSP树更好并且更直观的方式来存储这些信息。

　　潜在可视集像它听上去同样很是好。它是这么一个方法，在任何给定时间，给定你在世界的位置，它决定世界的哪些表面，哪些对象实际上能够看得见。这时经常使用来在渲染以前剔除对象，也剔除它们来减小AI和动画处理。毕竟，若是你实际上不能看见它们,为何还要费脑筋处理呢。多半这真的是不重要的，若是一个非玩家角色（NPC）正在播放动画，或者甚至在运行它的AI思考。

游戏物理学
　　既然咱们已经在内存中获得了世界的结构，咱们必须防止咱们的角色从里面掉落出去，并处理地板，斜坡，墙壁，门，以及移动平台。加之，咱们必须正确地处理地心引力，速度变化，惯性，和放置在世界里面的其它对象的碰撞。这被看做是游戏物理学。并且在咱们进一步深刻讨论以前，我想如今就在这里消除一个神话。任什么时候候你在世界中看见物理，或者任何人在一个复杂的游戏环境中宣称“真实的物理”，很好，它是BS。超过80%的建造一个有效率游戏物理系统的精力花在简化用来处理世界中对象的真实方程式上面。甚至那时，你时常忽略什么是‘真实的’，并创造一些‘有趣的’东西，毕竟，这是目标所在。

　　常常地游戏者将会忽视真实世界的牛顿物理学，并扮演他们本身的，更有趣的真实版本。例如，在QuakeII里面，你可以当即从0加速到35MPH，并快速停下来。没有摩擦力，并且斜坡不提供真实斜坡提供的相同类型的重力问题。身体没有它们应该的做用在全部关节上的地心引力 -- 你看不见身体像真实生活中那样倒在桌子上面或者边缘 -- 并且地心引力它自己甚至多是可变的。面对现实吧，在真正的世界中，空间中的飞船不像二战飞行战斗员在它们的表面操做那样实行。在空中，所有是力和副作用力，力在重量点周围做用，等等。不像 X-Wing中的Luke Skywalker那样啸叫。尽管那样作更加有趣！

　　做为游戏开发者来讲，不管咱们作什么，咱们须要可以检测墙壁，检测地板，在世界中处理和其余对象的碰撞。这些是现代游戏引擎的必备 –咱们决定对它们进一步要作的取决于咱们和咱们的游戏须要。

效果系统
　　现在绝大多数的游戏引擎建造有某种效果产生器，这容许咱们表现出有洞察力的游戏者期盼的全部可爱的吸引眼球的东西。然而，效果系统幕后所进行的东西可以急剧影响幀速率，因此这是咱们须要特别关心的地方。现在咱们有很棒的3D显示卡，咱们可以传送大量的三角形给它们，并且他们仍然要求更多的三角形。并不老是那样。在Heretic II，使用它的可爱的软件渲染模式，因为他们漂亮的符咒效果，Raven遇到了至关严重的过分绘制问题。回想当你在屏幕上绘制相同的像素超过一次时，过分绘制就发生了。当你有许多效果正在进行，按其性质你有许多三角形，多个三角形可能相互堆叠在彼此上面。结果是你有许多重复绘制的像素。加上Alpha，这意味着在从新绘制以前你必须读取旧像素并和新的像素混合，这会消耗更多的CPU时间。

　　Heretic II的一些效果能说明这点，咱们在一幀里对整个屏幕重复绘制了四十遍。很惊讶，是吗？所以他们在效果系统里面实现了一个系统采样在过去30幀的幀速率，若是速度开始减慢，它就自动地缩减任何给定效果绘制的三角形数量。这样使主要工做完成了，幀速率保持住了，但一些效果看上去很丑陋。

　　不管如何，由于现在绝大多数效果倾向使用大量很小的粒子模拟火和烟等等，结果你在效果代码里面每幀要处理许多的三角形。你必须把它们从一幀移动到下一幀，决定它们是否完成了，甚至还要在它们身上运用一些物理学以便让它们在地板上面适当的反弹。这在PC上面都是至关昂贵的，所以甚至如今你必须对你所可以作的有一些实际限制。举例来讲，用一个像素粒子产生火的效果可能会很好，但当你这么作的时候就别指望在屏幕上作更多别的事情。

　　粒子被定义为拥有它们本身的世界位置和速度的很是小的可绘制的物体。它们不一样于有方向的精灵，大的粒子使用这些精灵 --好比喷出的一团团烟雾。它们面向照相机自动而典型地旋转，缩放，改变它们的透明级别，所以它们可以随着时间淡出。咱们容易看到大量的粒子，但咱们却限制精灵的数量—尽管二者之间的真正不一样现在正在模糊。未来，特别是在 DX9和更加高级的图形硬件表面之后，咱们可能看到更多的人们使用过程shader来产生跟粒子系统类似或者更好的效果，创造很是棒的动画效果。

　　当谈论效果系统时，你可能据说过‘图原’这个词。一个图原是你的效果系统将处理的效果的最低级别的物理表现。更进一步解释，一个三角形是一个图原。那是绝大多数引擎最终在底层绘制的 --大量的三角形。当你沿着系统向上时，你对图原的定义随着变化。好比说，顶层的游戏程序员不想考虑处理个别的三角形。他仅仅想说,"这个效果在这里发生"并让系统以一种黑盒方式处理它。所以对于他来讲，一个效果图原就是‘让咱们在世界的这点持续这么长时间用这样的引力产生一束粒子’。在效果系统内部，它可能认为一个效果图原是它那时正在产生的每一个单独的效果，像一组遵循一样的物理学规则的三角形—而后它传送全部这些单独的三角形到渲染器进行渲染，所以在渲染器层次，图原就是一个单独的三角形。有一点困惑，但你知道总的思想了。

　　以上就是第五部分，下一个部分是关于声音系统，和各类不一样的音频APIs，3D音频效果，处理闭塞和障碍，各类不一样材料对声音的影响，音频混合等等。

第6部分:声音系统，音频APIs

声音系统
　　因为人们玩的游戏在种类和技术上的进步，声音和音乐近几年来在游戏中正逐渐变得重要起来（声音是一个实际游戏的可玩特色，好比在Thief和其它同类游戏中的听觉提示）。如今四声道环绕系统在游戏玩家的宝库中是负担得起的和日常的事。给定空间的声音，噪音的障碍和闭塞，和动态的音乐，现在许多游戏使用这些提升玩家情绪上的反应，更多的关注投入到这个领域就不足为奇了。

　　如今在PC竞技场中，游戏玩家实际上只有一种声音卡能够选择 -- PC声卡制造商创新公司（Creative Labs）的Sound Blaster Live！ 从旧的时间我的计算机声音卡片制造业者有创造力的中心.多年来创新公司已经为DirectX提供了他们的EAX声音扩展，而且他们是发起新的OpenAL（开放音频库Open Audio Library）的创立者。就如同OpenGL是一个图形API同样，OpenAL，像它起来听同样，是一个声音系统的API。OpenAL被设计为支持大多数一般声卡的许多特征，并且在一个特定的硬件特征不可得时提供一个软件替代。

　　为了更好的定义 OpenAL，我向创新公司的Garin Hiebert询问了其定义:

　　"这里借用咱们的 " OpenAL规格和叁考" 的一个定义:

　　OpenAL 是对音频硬件的一个软件接口,给程序员提供一个产生高质量多通道输出的能力。OpenAL是在模拟的三维环境里产生声音的一种重要方法。它想要跨平台并容易使用，在风格和规范上与OpenGL类似。任何已经熟悉OpenGL的程序员将发现OpenAL很是熟悉。

　　OpenAL API能容易地被扩展适应插件技术.创新公司已经把EAX支持加入到这套API了，程序员能够用来给他们的声音环境增长复杂的反响，比赛和障碍效果。

　　如同Jedi Knight II: Outcast同样，连同Eagle 世界/声音特征编辑器,Soldier of Fortune II以这个新系统为特征。什么是Eagle？在介绍这个之前，让咱们讨论一些其余的系统，并定义一些声音术语。

　　另外的一个系统是Miles声音系统。Miles是一家公司，它为你的代码生产插件，在充分利用每块声卡时处理全部必须的到特定声音卡的说话（好比Sound Blaster Live！系列，或者老的A3D声卡）。它很是像一个API前端，捆绑了一些额外的特征在里面。在其余事物当中Miles让你存取一些事物像MP3解压缩。它是很好的解决方案，但像任何事同样，它花费金钱并是你的代码和硬件之间的额外一层。虽然对於快速的声音系统制造，它很是有用，并且他们有段时间了，所以他们的确精通本身的业务。

声音术语
　　让咱们开始障碍和闭塞。它们听起来同样，但不是这样。闭塞基本上意谓着一个声音在播放时听者在他们之间有一些闭合的障碍物。

　　好比说，在NOLF2的一个屏幕镜头上你听到房子里面坏蛋的声音。你能听到他们，可是他们的声音至关低沉而沙哑。障碍是类似的，可是你和声音之间的障碍物并非闭合的。一个好的例子就是在你和声源之间有一根柱子。因为房间中的回声你仍然听获得这个声音，可是它和声音直接传递到你的耳朵里是不一样的。固然这确实依赖于知道在你的耳朵和声源之间的直线上是什么。并且根据房间的大小，声源到你的距离等等，须要的处理能变得至关耗时。后面咱们将会谈到跟踪--足能够说它时常是比较慢的幀速率的缘由。Quake III 里面的A3D 代码作了这些事情，关闭这些选项一般可以提升幀速率。Tribe 2是这种弊病的另一个受害者。关闭3D声音选项则你的幀速率当即好转，这在你考虑Tribes世界有多大和你能看见多远时有意义。

　　接着是声音物质的特征。大部分声卡可让你可以用可定义的过滤器做用于声音从而修正播放的声音。例如，在水下，或者在一个布料遮盖的房间中，或者在一个长的走廊中，或者在歌剧院，听到的声音有着很大的不一样。可以根据你所处的环境改变你听到声音的方式是至关不错的。

　　咱们回到Eagle… 这是一个编辑器，容许多数第一人称射击游戏地图设计者将他们的地图导入到这个工具，而后构造简化的几何形体来为实际游戏引擎中的EAX代码产生一个声音地图。其思想是你不须要一个真实的图形地图的复杂几何形体来模拟声音环境。你也可以给产生的简化地图分配声音物质，这样声音环境就可以动态地改变。我亲眼目击了这在Soldier of Fortune和Unreal Tournament上的示范，确实至关引人注目。 我这在财富和 Unreal巡回赛和它的军人上真的对示范是证人至关醒目. 当你跳入水中时，听到全部的声音改变，这是一个很是使人沉浸的经历。

　　好，让咱们继续吧。

　　对于游戏机，因为静态的硬件，你的各类可能性会更受限制 —尽管在PlayStation 2和Xbox上，硬件至关不错。我说的限制，仅仅是指扩展，而不是它所可以作的。我一点也不会感到惊讶看到这些游戏机上的游戏很快支持杜比数字5.1（Dolby Digital 5.1）输出。Xbox，因为它的 MCP 音频处理器，可以将任何游戏音频编码为5.1，而且游戏不须要特别编码就能利用这个特征。杜比（Dolby）把ProLogic II带到了 PS2 上，并与Factor 5合做为GameCube游戏实现了ProLogic II。在 Xbox之上，Halo, Madden 2002 和 Project Gotham Racing等游戏都有5.1杜比数字音频内容。DTS最近也为 PS2 游戏开发者发布了SDK，为这个平台上的游戏带来了下降了比特率的DTS音频版本。

位置的声音--一个复杂的世界
　　如今有一些不多有处理的声音空间化问题。我说的是把声音放在一个真实的3D世界中。有四个扬声器在你周围是一个很棒的开始，但这仍然只是在二维方向。在你的上方和下方没有扬声器，你没有真正得到3D声音。有一些声音调制过滤器试图解决这个问题，但实际上没有真实东西的代替物。固然真实地大多数游戏多半只是在二维方向上，所以这仍然不是太大的问题。

　　实际上任何声音系统最重要的特征之一是把声音混合在一块儿。根据你所处的位置，空间中声音的位置，每一个声音的音量大小，一旦你决定了实际上你可以听到的声音，而后你必须混合这些声音。一般声音卡本身处理这些，这首先是声音卡存在的主要缘由。然而，外面有一些引擎决定首先用软件作一次‘预混合’。直到你着眼于一点点历史之前，这并无真正地带来多大的意义。

　　当声音卡最初问世的时候，有许多不一样的混合方法。一些声卡能够混合8种声音，一些单位16种，一些32种，等等。若是你总想听到16种可能的声音，但你不知道声音卡是否可以处理，那么你回到了尝试和试验的道路上 —就是你本身用软件混合。这其实是Quake III声音系统的工做方式，但提一个问题:"Quake III是为A3D和Sound Blaster Live！声卡世界发布的，这比之前更加标准化，为何还这样作？"这是个好问题。实际上Quake III的声音系统几乎每行代码都和Quake II中的声音系统同样。并且Quake I，甚至Doom也是这样。你想想，向上直到 A3D 声卡和 SB Live! 声卡，许多年来声音系统的需求没有真正地改变过。两个扬声器，二维方向，音量简单地随着距离减少。从Doom一直到Quake III没有发生太大变化。并且在游戏行业中，若是不是无可奈何，别理会它。

　　一般你会仅仅使用DirectSound为你作声音混合，由于它会能够使用的声音硬件，或者转而依靠软件，不少地方就像DirectX为3D显示卡所作的同样。在 90% 的声音情形中，依靠软件混合对你的幀速率没有真正发生太多不一样。当DirectSound在一些狂热的编码者眼中甚至还不是一丝光线时，Doom引擎就已经产生了。它历来没有获得更新过，由于它历来就没有真的须要更新。

　　固然，你能够使用 SoundBlaster Live！声卡的一些聪明特征，例如房间的回声特性:一块石窟，或一个礼堂，一个巨穴, 一个足球体育馆等。并且你真的应该使用由硬件提供的混合器，毕竟，那是它存在的目的。这种方法的一个不足之处是程序自己时常没法得到混合结果，由于混合是在声卡内部完成而不是在主存。若是因为某种缘由你须要看到产生的音量，你是运气很差。

Music Tracks in Games（游戏中的音轨）
　　咱们没有过多的谈到游戏中的音乐生成。传统的有两种方法，一种是简单的音乐 .wav文件(或同等物)。它被预先制做作好，准备运行，和最小忙乱。然而，这些在内存和回放时间方面很昂贵。第二种方式用预设的样本编码MIDI音轨。这时常比较节省内存，但缺点是必须同时把一些声音混合在一块儿，于是会把声音通道用光。

　　动态音乐就是根据在游戏中目击的行动改变你的音乐的能力，好比探险用慢节奏的音乐，战斗用快节奏的音乐。预先制做的音乐的一个困难之处是要合拍，所以你能够从一段音乐渐弱到另外一段音乐，这对于MIDI音轨比较容易。尽管时常你足够快速地淡出，或者一段音乐在播放另外一段音乐以前已经消失了，你能侥幸不被察觉。

　　在咱们离开这个主题以前，顺便说一下，值得一提的是存在一些公司专门为你的游戏创做特定意义的音乐。FatMan(www.fatman.com)就是一家这样的公司。音乐可能比其余别的东西更加容易外包，这是他们存在的方式。

　　最后，游戏如今的事情天然是MP3格式，容许巨大的11：1的声音样本压缩，然而在送到声音卡以前只花费CPU不多的时间解压缩。当我在Rave Software工做时，在Star Trek Voyager: Elite Force中，咱们设法用MP3在一张CD上面彻底支持三种语言，仍然为较多的图形留有空间。主要地，咱们 MP3只用于非玩家角色（NPC）的语音，因为游戏的所有音频效果MP3流和动态解压缩超出了硬件的处理能力，虽然在未来这是确定可能的。比较新的格式，如来自 Dolby的 AAC 和来自微软的WMA，以将近两倍MP3的压缩率提供了相等或者更高的音频质量（实际上一半的比特率），可能应用到未来的游戏中。

　　以上是这一章节的内容，下面将是网络和连线游戏环境的开发。

第7部份:网络和连线游戏环境

网络游戏
　　我记得一些年前坐在GDC（游戏开发者大会）听负责开发X-Wing Vs TIE Fighter的家伙们题为“淹没在Internet”的演讲，全是关于让网络游戏实时地在Internet上工做的东西。他们选择那个题目是多么的正确啊。当它开始处理数据包的丢失，乱序，潜伏（一个数据包发送到它的目的地所花的时间）等等时，它确实淹没了。然而它是可能的。对于Internet须要一些聪明和经验，但它是确定可能的。看看今天大量的连线游戏，从Quake III，Unreal Tournament，Counter Strike一直到EverQuest和Ultima Online。

　　现在大多数真正有长久生命力的游戏都至少有一些连线成分。最纯粹的单人游戏容易玩一次，也许两次，或者甚至三次若是它是很是好的游戏，但一旦游戏结束，就被束之高阁了。若是你想要有任何长久生命力，那么多人连线游戏就是形势的核心所在，而且那意味着和Internet打交道，为编码者打开了那个潘多拉的盒子。

　　那么跟Internet打交道包括些什么呢？首先是要理解Internet是怎么工做的，和点对点与客户机/服务器体系结构的快速讨论。点对点就是你在两台机器上运行游戏，并简单地在它们之间共享输入。每一个单独的游戏假定它是正确的，并仅仅在它一幀接一幀的刷新中合并来自另一台机器的输入。客户机/服务器是一台机器有效地运行游戏，别的机器仅仅是一个终端，接受来自玩家的输入，并渲染服务器让它渲染的任何东西。

　　客户机/服务器的优势是每台机器都将会展示相同的游戏，由于全部的处理都在一个地方完成，没有跨越多台机器，你能够不用考虑每台机器相互之间的同步问题。不足之处是，服务器自己须要有一些重要的CPU可用时间来处理每个链接的客户机，和一个合适的网络链接来确保每个客户机及时地接收到它的更新。

了解IP
　　咱们都已经据说过TCP/IP（传输控制协议/网间协议）和UDP（用户数据包协议），在Web网络上有大量关于这些协议的深奥的技术资讯。实际上，在Cisco网站上有一些极好的TCP/IP指导。咱们将在较高层面上介绍一些TCP/IP的基本知识，目的是让你更好地了解使用这些标准协议的网络游戏设计者面临的挑战。

　　TCP/IP和UDP/IP是两层的通讯协议系统。IP层负责网际数据包的传输。UDP或者TCP层将大的数据包传给IP，IP将数据包分割为小的子数据包，为每一个数据包加上一个信封，计算出目的地的IP地址，应该如何到达那里，而后将数据包发送到你的ISP，或者无论怎样你链接到网络。这实在象是在一张明信片上写下你要发送的，贴上邮票，写上地址，塞进一个邮箱，它就送走了。

　　UDP和TCP是从你编码者或者游戏接收数据包的高层协议，并决定该如何处理这些数据包。UDP和TCP的区别在于TCP保证数据包的传送和有序，而UDP不保证。UDP是一条直接和IP对话的小路，而TCP是在你和IP之间的一个接口。它像是在你和你的邮件之间有一个管理员助手。使用UDP你会本身为你的信打字，把它们放进一个信封等等。使用TCP你会仅仅向你的管理员口授信稿，管理员会作所有的工做并追踪确认信件送到了。

　　然而，全部这些使人惊奇的为你完成的工做伴随着代价。为了肯定数据包经过Internet无缺无损地送到了目的方，TCP期待从目的方为它发送的每一个数据包发回一个应答包（网络用语是ACK）。若是它在必定时间内没有收到ACK，它就中止发送任何新的数据包，从新发送丢失的数据包，而且将继续这样作直到收到目的方的回应。当你访问一个网页时，咱们都已经看到了这种情形，在半途中下载中止了一会而后又从新开始了。多是一个数据包在什么地方丢失了（假定不时ISP的问题），在任何更多的数据包被发送之前TCP要求从新发送它。

　　这一切的问题是，在认识到出了差错的发送者和实际上正在送达的数据包之间出现了延迟。有时这能花上数秒钟，若是你仅仅只是下载一个文件或一个网页，这不是什么大碍，但若是这是一个游戏数据包并且每秒至少有十次，那么你真的是遇到麻烦了，尤为是由于它中止了其余一切事情。实际上就是这个问题因此几乎没有游戏选择使用TCP做为它们主要的Internet协议，除非它不是一个实时动做游戏。大多数游戏使用 UDP--他们不能保证有序或可靠送达，但它确实很快—或者结果是至少一般比TCP/IP更快。如今咱们了解这些了，接下来呢？

客户端预测
　　由于 UDP 明显的是快速响应游戏的方式，咱们将必须本身处理数据包的丢失和乱序。边并且这是技巧所在。不用说出太多的代码秘密，我就能说有方法。做为开始，有客户端预言，一个被谈论得至关多的词语。当你做为一个客户端链接到一个大的服务器，可是不能连贯地看见来自服务器的更新，客户端预言开始起做用了。正在你的电脑上运行的游戏部分看着你正给它的输入，并在缺少来自服务器的任何弃绝信息的状况下，对它认为将继续进行的事情做出‘最好的猜想’。它将会显示被猜想的数据，而后当它获得来自服务器的世界的最新状态时，改正它本身，若是须要。你可能会对这个方法的效力感到惊讶。大致而言，大部分时间数据包不容易丢失—大多数时候是一秒的几十分之一，这种状况下游戏没有太多的时间偏离服务器实际上认为正在发生的事情。偏离确实会随着时间变的比较大，大多数游戏里面有一个超时功能，当出现很长时间没有来自服务器的联络时就中止游戏。

　　你正在创造的游戏类型在这里有关系 --第一人称射击游戏不须要这样有效的客户端预言，由于它多数状况下仅仅处理“我在哪儿，我是否要射击？”。在第三人称游戏中，你必须更加精确，所以你可以正确地预测你的角色正在播放的动画，而且动做流畅。在这种情形中流畅的动画是彻底必要的。Heretic II在这方面有很大的问题，而且是当它开始网络编码时Raven一直不得不处理的最困难的事情之一。

　　固然若是你有一个很不错的网络链接，好比宽带链接，那么这个问题就远没有那么重要。对比较大的数据包有一个更宽的管道，对你的网络连通时间更快速。事实上，宽带对于游戏的主要优势不比较胖的管道多，但大大减小了延迟，特别是你到ISP的第一跳上。对于56K调制解调器，第一跳典型的延迟是100ms，这已经严重地增长了你到网络上任意一台游戏服务器的潜在连通时间。对于宽带链接好比像DSL，第一跳的延迟时间多半是20ms。使用Windows中一个叫作TraceRoute（TRACERT.EXE）的命令行程序并指定一个目标IP地址或者域名，你可以找出你的第一跳的连通时间。仔细观察第一跳，由于这几乎老是你到你的ISP的网络连通时间。而且观察你在你的ISP的网络内部用了多少跳直到你看见在一个给定跳上列出的一个不一样的域名。

　　请注意，宽带并不老是能解决延迟问题。你仍然受最慢的路由器/服务器和数据包从服务器穿越网络到达你的跳数（反之亦然）的支配。有一个宽带链接确实容易缓和这些，但不可能它们最后就消失了。固然，若是你打算要运行某种服务器，你将会须要一个具备足够快速的向上游的数据速率的带宽，由于仅仅一个调制解调器不可以处理一个服务器产生的负荷。

　　值得一提的是，若是你想要在PS2或者Xbox上面玩网络游戏，你将须要一个宽带链接，由于它们二者都不支持调制解调器。

包大小，智能数据传输，和反做弊
　　别的必须被处理的事情是数据包的大小。若是你在一个游戏里面64我的都在跑来跑去相互攻击，从一台机器发送到另一台机器的数据包能变得至关大，达到了一些调制解调器没有带宽处理这些数据的程度。这正在变得特别和那些有着很大的地表系统的游戏有关。这里增长的问题是，由于你有这个很好的地表系统，你可以看得很远，所以可以看见许多其余游戏玩家，使得你为了精确渲染所须要的来自服务器的数据数量以很快的速率增加。咱们能作什么呢？

　　好吧，首先必要的是只发送绝对必须的东西给任何给定的客户端，所以他仅仅获得从他的角度观察游戏所须要的东西。发送在他视野之外的人们的数据没有一点意义—他将看不见这些。同时，你最好确保只发送那些每幀之间实际上发生改变的数据。若是一个家伙仍然在播放相同的动画，从新发送数据没有意义。固然，若是数据包丢失时这确实带来一些问题，但这就是为何好的网络程序员被支付不少金钱，来处理相似这样的东西。

　　还有一些其余的事情也要处理。最近已经有大量的使人苦恼的连线做弊正在发生。这是某些人修改游戏以给他们不正当利益的地方。尽管严格意义上这不是网络的一部分，但它确实发生了。有时人们会创做一些模块，容许他们当即瞄准进入视野的任何人，或者简单地容许他们看穿墙壁，或者让其余游戏玩家看不见他们本身。大部份时间这些事情能够在网络层内部或者在服务器上被处理。任何有100%命中率的人被简单地踢出游戏，由于在人力所及的范围内那是不可能的。

　　游戏开发者必须尽一切可能制止做弊行为，但很不幸，人作的东西能够被人突破。全部你能作的就是让做弊变得困难，当确实发生时去尝试发现它。

　　好吧，如今就到这里了。在第8部分中，咱们将会看看游戏脚本系统的趣味世界，根据游戏过程当中出现的事件来渲染或使能预先定义的场景和行为，协助故事叙述。

第8部份:脚本系统

脚本系统
　　咱们从第七部分的游戏网络问题来到了脚本系统，由于其呈现的故事叙述机会，最近已经造成一种很大的游戏元素。在一个须要以受控制的方式解释的情景，预先编制的电影脚本是解决问题的方法。在电影中，这一般用来处理或者由主角向一个伙伴解释情形，或者敌人对英雄解释。固然，有其它的方法来作这件事情 --叙事者，倒叙，等等 – 但一般是使用实时情景的人们和事件来完成。固然，游戏是不一样的，游戏开发者在他们日常的FPS中不该该作太多的倒叙，由于一般会须要载入新的环境或者关卡，以及新的纹理和/或模型。全部这些额外的处理和渲染能影响到主要的游戏序列的性能。你能够重用已经存储在内存里面的场景元素来倒叙，但那样会看上去明显比较粗陋。

　　RavenSoft 的Star Trek Voyager: Elite Force普遍利用了脚本序列产生游戏中的事件和使用游戏引擎自己的剪辑场景。

　　在游戏中设计脚本情节的一个有趣趋势是使用当前极大改进了的3D游戏引擎本身产生剪辑场景。如今这可能像是至关地明显，可是数年之前，当 3D图形卡还比较简单的时候，剪辑场景一般使用高端3D工做站制做，获得的3D动画而后被记录为一个数字视频文件，以流式文件存储在CD-ROM。你从剪辑场景的漂亮图形画面回到真实游戏的相对粗陋的3D画面，这是至关使人不愉快的失望的事情。但像Half-Life和 Star Trek Voyager : Elite Force这样的游戏很好地利用了它们本身的引擎产生全部的剪辑场景，结果是剪辑场景和游戏之间的过渡更加平滑。

　　把脚本和人工智能区分开来多是个很好的主意。脚本是你彻底控制着一个给定场景，创建玩家几乎老是没有控制的事件，游戏者‘沿着轨道’移动到一个给定地点，或者创建一个游戏玩家须要解决的情形。一个好的例子多是巨石掉在走廊上，须要游戏玩家找到一个新的逃脱方法。

　　现在有一些不一样类型的脚本系统可供程序员或者美术师使用，并且它用很是有条理和逻辑的思想恰当地作这些。第一种是简单的基于文本的，单线索的风格，就像咱们程序员习惯的编码。在许多状况，它实际上基於 C，尽管以一种很是简单的形式。大量这种相似“if this，then do that”的东西。大部分脚本倾向在范围内是至关线性的—意味着它一般由许多在次序上彼此相接的命令组成。在世界中移动角色A指向B。当完成之后，让他讲话，完成之后，移动他指向C。至关简单的事情。

　　而后有复杂的东西--容许多重线索，和实际上容许可变情形。可变情形是当脚本开始时你实际上不能确知谁会出如今附近，可是你必须按这样的方式编写脚本以便任何人出如今附近它都将会工做。举例来讲--一个正常的简单脚本会有三个家伙，所有被预先定义，所有有一组他们将会讨论的情形。一个可变的脚本将会有三我的,你不能保证是某一个特定的人，并必须按相同的方式工做。或者在一个极端的情形中，也许只有二个，或者甚至一个家伙将会在那里，使得三方交谈有一点困难。

　　Raven在Star Trek Voyager: Elite Force中面临的一个很大的问题是这样的情形，使用者可能会想要把一个角色从一条船的某个地方带到另一个地方，可是从A点到B点的路径可能会随着每次游戏根本地改变。举例来讲，他们须要让Munro(你所扮演的游戏主要角色)从发动机舱室到输送舱。不幸的是因为游戏的非直线性，在事件到达这一点之前你可能已经破坏了涡轮升降机，或者也许 Jeffries管被损害不能经过。假定当脚本开始的时候咱们不知道世界的状态，咱们不得不为几乎各类可能发生的事情编写脚本以便适用于这些‘若是。。。怎么办’的情形。并且它仅仅从那里变得更加糟糕。咱们能创建的一些情形提供了如此多可能的组合情形，以至于为了一个满意的结论而准确测试每个可能发生的事情几乎是不可能的。请和在SiN, Star Trek Voyager : Elite Force or Deus Ex中工做的任何人谈谈。QA部门传统地憎恨这些类型游戏，由于这已经使他们的工做比之前更加困难了 50倍。

　　你可以想象为这些情形编写脚本是何等的困难。但那是今天的非线性游戏路径要求的事情，并且它为什么博得了较多的开发支持从而可以努力实现它。

Jim Dose关于脚本系统的论述
　　去年末我访谈了JimDose--Ritual的前任开发者，如今是Id Software的一个开发者，Doom3脚本系统（和其余一些事情）的设计者。尽管此次访谈有些久了，但仍然是颇有洞察力。

　　Jim谈了脚本系统和建立一个易用且健壮的系统(与包含设计者传统想要使用的全部特征相反):

　　设计一个脚本系统最难的部份是知道什么时候该中止。一旦你完成了并开始运行，你发现有许多可以利用它的系统。对于Sin，最初的主意只是要有一个比较容易的方法让关卡设计者描述对象怎样动态的在环境中移动。在项目的后期，咱们也使用它来让声音和游戏事件与动画同步，在多个关卡跟踪任务目标，控制HUD的布局和游戏内部电脑控制台用户接口，描述人工智能如何对不一样的情形产生反应，以及粒子系统。

　　控制复杂度可能也是至关的困难。当你把脚本的力量放进有创造力的人们手中时，他们开始探究他们所能作的界限。时常，他们受启发作一些恰好轻微超出系统能力范围的事情。很容易陷入到这种增长‘仅仅再多一个特征’就容许他们作他们想作的事情之中。随着语言增加，一个可能对最初的规格有意义的语言结构变得严重过分扩充了。在一些时候，从新思考系统变得有意义，但在那时，你可能已经积累了数量巨大的必须从新编写的脚本。和FAKK2同样，Sin遭受了这样的损失。我没有获得对脚本系统进行大规模完全检查的机会直到我为Rogue's 'Alice'.重写了脚本系统。

　　阿们，吉姆。-- Raven已经看到这个刚好在他们的ICARUS系统中出现了。ICARUS其实是一种与Jim在上面描述的相同种类的脚本系统，并且负责在Star Trek: Voyager: Elite Force中的全部脚本事件。它在Soldier of Fortune II和Jedi Knight II : Outcast中被重复使用。为了解决系统须要处理的新问题，这些问题在最初的实现中没有被预见/不须要，脚本系统的不少部分已经被从新编写了。

可视化脚本系统
　　第二种类型的脚本是可视化脚本系统。使用这种方法，而不是文本文件的编码方式，实际上你可以在真实的游戏环境中使用真实的角色创建你的脚本。你可以追踪角色在世界中行走的路径，定义使用的动画，而且一般获得关于你的脚本实际上将看起来如何的更好的主意。它对咱们已经讨论的非线性问题没有太大的真正的帮助，但它确实能够很快速地生成最初的脚本。

　　其次，Jim谈论了可视化脚本系统。

　　可视化脚本系统确实有它们的用处，但每每实现更加困难，若是设计得不好，当复杂度上升时就容易让开发者感到困惑。举例来讲，人工智能能够用一个流程图似的结构来进行可视化的设计。你能很是容易地可视化地表现人的行为举止方式，用盒子表明状态，箭头表明转化到其它状态，指示角色可以从一个状态转换到另一个状态的方式。

　　脚本的一种一般使用是在游戏世界中控制物体，指示他们他们如何在世界中移动。在一个编辑器中可视化地移动物体到关键位置并播放整个运动的能力对一个设计者可能会更加直观。然而，它确实有它的极限，由于将须要另一个接口来设计物体在它的移动中必须做出的任何决定。那种能力是把脚本动画片段和相似3DS Max或者Maya这样的程序产生的动画区分开来。

　　在一些时候，使用者可能须要一些方法决定一个脚本为什么没有作他们所指望的事情。一些形式的除错工具能使这件工做很是容易。至少，决定哪些脚本正在运行和脚本当前位置的一些方法必需的。在脚本中检查变量，开始，中止，和单步执行的能力也是有帮助的。一般，一个程序师可以在他们的调试器中进行除错，但这个过程要好比果有一些内建的脚本调试器可用时花费的时间更长。

　　以上就是第8部份，在接下来的章节中咱们将讨论使用现成产品和定制的游戏引擎设计工具的功过得失，而后探究游戏控制机制，开发游戏对象，和一些刺激有趣的事情 (武器系统)。

第9部分:现成产品与定作的游戏引擎设计工具，游戏特定主题

现成产品与定作的设计工具
　　咱们从第8部份的脚本引擎来到这一章节中的许多主题，咱们认为那些铁杆游戏玩家和有志成为游戏开发者的那些人将会发现它们至关有趣。咱们将开始讨论现成产品与定制的设计工具。

　　你的工具的选择是你引擎设计的一个很是重要的部份，由于这是你将用来给你的游戏产生内容的东西，是最耗时的部份。在这个过程当中有助于节省时间和资源的任何东西都是好的。那些不能的东西就是糟糕的。在那里，那是容易的。

　　固然没有那么容易。有比这更多的事情可能会马上被注意到。你的工具集的选择，和从工具到游戏的资产路径比它听起来更有技巧得多，并受到不少因素的影响，好比，是否适宜手边的工做，费用，内容生产者的熟悉，市场渗透，工具支持等等。当考虑选择现货成品工具，或者即便当开发你本身的工具时，记得开发者实际在作工做，最好可以作须要借助工具作的。一些现货成品工具能在价格上达到那里，当你陷入多个拷贝许可时，费用猛涨。

　　而后就有诱人的可能性从头制造你本身的工具，为你游戏和引擎的须要而设计。这固然须要时间，和程序员大量的努力来产生在开发者友好方式中所须要的东西。快速打造基于窗口的文件转换器是一回事情，从头建造一个完整的关卡设计工具又是另一回事情。另外一方面，若是你确实选择这条道路，最后你会有游戏开发者地带其余人没有的工具，所以你的东西将会看起来是独特的。现在不同凡响是一件很是值得想望的事情，并且从群众这些天起突出是一件很是使人想要的事物，产生全部的竞争。

　　固然因为内部的工具开发，你须要某人来作全部那些不可避免的小的改变和修正。但这里真正的意义是这是可能的。使用现成的工具，工具开发者会不多由于你须要的一些特征而改变他们的输出文件格式。这样你的东西最后看起来更加通用一些，不然你必须采用额外的步骤使用另外的工具来获得想要的结果，固然会花费开发者更多的时间。

　　值得记住的是现在许多有名的3D工具已经有一段时间的历史了，而且正在产生简直没有错误的产品，更重要的是，对他们所作的已经有必定程度的经验了。

　　若是你选择建造你本身的工具，多半你是，a）从新创造车轮到某种程度 b） 陷入那些建造现成工具的人们已经遇到过的相同的问题之中，只是他们已经解决了这些问题。时常人们建造一个单一特定的工具花费了至关的时间和努力，并产生了一个远远超出你本身的我的需求的工具。还有，他们有表明性地收编了一些你或者认为是没有用的，或者没有时间本身实现的特征。加上他们典型地有吸取特征你或会没有想有用,或没有时间实现你本身.这是第三方软件没法争辩的。

插件和目的建造工具
　　一般大多数的游戏开发过程最终都是这样的混合，本身开发的文件转换器工具，现成的内容创造工具，和一般那些要增长一些必须的特殊功能的工具的一些附加插件。现成工具在提供你不可避免会须要的功能方面有很长一段时间了，可是正如不可避免，总有一些颇有用的，有帮助的，或者彻底必须的东西你不能获得。一个小的插件多是一个很好的替代品，并且时常那就是所走过的路。为特定目的建造的预处理程序也是可用的，好比把TGA文件转换为一个对PS2友好的格式，或者那些相关的东西。

　　若是你或你的公司打算建造某种类型游戏的工具，那么这些工具通常是从一个项目到一个项目地演变发展，而不是每次都从头从新建造。若是你变换游戏类型，很好，那些产生具备每一个多边形命中能力的高分辨率模型的工具明显地不是一款RTS（即时战略）风格游戏所必须的。

　　Gil Gribb，Rave Software的技术带头人，对‘现成的工具’和‘本身动手建造’的问题是这么说的：

　　"本身开发的工具备可以根据本身产品的须要进行定制的优点，你拥有代码，能够修正任何错误或者增长任何的改进。

　　自制工具的缺点是建造和维护它们是很是昂贵的，一般成本要比现成工具高不少。在许多状况下，因为应用程序范围的缘故，创建本身的工具是彻底不可能的，好比说3D建模和动画软件包或者位图编辑软件。"

　　固然，若是你想要游戏玩家可以修改你的游戏，并且你本身创建了全部的工具，那么你就必需要向世界发布这些工具。这可能会引发一点点疑惑，记住创建你本身的工具的部分缘由是你能够领先你的竞争者。有时侯发布这些工具的源代码甚至可能让你获益匪浅，这确实提供了一种创造内容的方法。再次，Gil Gribb阐述这个主题：

　　"我是支持发布几乎全部的源代码。我认为咱们没有任何来自咱们的竞争者的惧怕的事情，合法的业务不会想到窃取知识产权。游戏迷，业余游戏制做者，以及游戏的普及都可以从发布的源代码获益。"

　　好，咱们的游戏引擎剖析系列到这里，固然咱们已经特别讨论了许多和引擎相关的主题，下面让咱们继续讨论一些与游戏特定相关的部分。

游戏控制机制
　　控制机制可以对开发中的游戏带来巨大的差异，有时甚至代表你正在创建的游戏的种类或者风格。

　　尝试在某个时候用gamepad玩一个即时战略类游戏--它不仅没有乐趣。有时当你被限制在一个特定的输入装置的时候，例如鼠标和键盘，为你的游戏发明新的控制方法会是一个使人筋疲力尽的过程。当Raven开始开发Heretic II时他们决定作的第一件事情之一就是为用鼠标使用第三人称照相机尝试和找出一个直观的方法。在这之前，大多数游戏采用的是Tomb Raider风格的照相机（第三人称预兆的追逐）他们发现这时常不能正确地工做，在不少情形下会给玩家带来挫折。照相机时常会获得任意的视角，若是可能的话移动相机，并且有时改变玩家的方向。

　　假定他们的目标对象是FPS游戏人群，Raven须要找到一个对FPS游戏玩家来讲直观的控制乌鸦座（Corvus）的方式。他们这样作了，但确实花费了一些时间，和一些不一样的方式—他们应当让照相机固定在一个方向吗，或者让它是浮动的吗？大多数游戏开发努力—除非一个肯定类型游戏的一个没有虚饰的实现—倾向于花费一些研发找出物理控制装置和游戏须要的内部控制机制的最直接的合并。这里是一个暗示—一旦你发现一个方式很起做用，就坚持下去。用这种方式控制游戏内在的东西能把视野，直觉，甚至游戏的焦点彻底改变成你从未想要过的东西。发现起做用的东西，证实它起做用，而后就别管它。过度设计控制会致使特征偏离和可察觉的游戏概念问题。

　　像这类特征偏离的一个很好的例子能够在Independence War中看到。这款游戏有着如此多的模式，按键，等等，仅仅熟悉和操纵游戏都不可能。

　　很明确这里的关键是简单。一个好的经验法则是，在正常的游戏中，若是你的游戏须要比在普通的gamepad的按键或者你手上的手指更多的按键，那么一些事情须要被重作。注意,我不是说一款游戏不该该有灵活性—Soldier of Fortune一定有许多可能的按键设定。但一般，当你认为它们大多数实际上都是不须要的时候Quake引擎有一个很好的方式。是的，你能够选择你想要使用什么武器，但你不是必须这样。游戏将会自动地为你那样作。这就是灵活性和过分设计之间的不一样。若是游戏须要你按下某个键来选择一个武器，那将会有问题。你理解这个了吗？

　　控制机制不能被太高估价 --一款游戏时常将会根据玩家以为他们对事件或者主要角色有多少控制而得到成功或失败。若是控制被改变，从新定向，或仅仅简单地从他们哪儿移除，它能致使游戏自身缺少参与，不用说，那是一件很糟糕的事情。在这上面花费时间并让它保持简单，将会有巨大的帮助。

实体和照相机
　　如今咱们来到了引擎不太使人愉快的部份，也是定义得最少的部分。当游戏运行的时候，游戏在这个部分能变得极端地多出错，耗时间，或仅完全的极限。

　　在这里咱们所谈论的是游戏引擎的 "游戏"部份。这个部分使用全部的其它技术让一些事物显示在屏幕上，处处移动，让它对你产生反应而且让你对一些事物产生反应。这个系统有许多方法，但如今我将紧扣Quake的方法由于那是我最熟悉的。

　　让咱们从实体开始。这些能够被定义为‘游戏对象’。如今那不只仅意谓你在屏幕上看见的模型，虽然实体肯定地控制这些 --实体也多是其余的事物。基本上它是游戏在任何给定时间须要知道的任何事物，例如让事情继续进行的定时器，模型的碰撞检测盒，特效，模型，游戏玩家，等等。

　　甚至照相机均可能是实体（在几乎全部Raven的产品中都是这样）。照相机在世界中被分配一个有角度的原点，它们每幀都被刷新并告知渲染器应该从哪里获得它的视野数据，and off we go。典型地实体是为了返回到游戏早先的状态而被存储和装载的那些东西。一般在装载过程当中使用的方法是把游戏地图装载进来，好像你正在从新开始一个关卡同样，而后装载全部存储的实体，这样他们就返回到游戏存储时它们的状态。Voila，即刻返回一个存储的游戏。当我理解Heretic II的方法时这并非那么的容易—装载/存储几乎比其余任何事情带给个人问题还多，特别是在协做模式。

照相机有许多形式：

　　自由形式：照相机能去任何地方
　　脚本：照相机能够沿着一条设定的路径前进
　　游戏时间：照相机有必需要遵循的定义的行为

　　仅仅说"嗯，我将仅仅跟随主要的角色"是不够的。这意谓你也可能须要让照相机穿过墙壁，或让它按一些方式移动以至甚至引发一些胃的恶心。让它沿着一些定义的上下运动路径前进也有益处，如同任何玩Descent游戏超过一小时的人能够告诉你的同样。身体和头部习惯于上下是一个静态的变量，并当它不是时，他们不喜欢它。制做Quake 1的 Mike Abrash，曾经告诉我即便当它被定义，他仍然处理的麦可 Abrash 地震 1,曾经告诉我即便当它被定义,他仍然从他们正制做的游戏感到运动恶心。他提到，对于他来讲，离开制做Quake 1一年时间才让他的胃安定下来。啊哈，咱们所做出的牺牲。

武器系统
　　游戏模块的另一个部份是武器系统。大多数的游戏有武器系统或相似的东西。 这是在世界中影响其余的物体，并且使他们对给定情形产生反应的东西，--好比说被射击。一般武器系统由许多不一样的类型组成；攻击扫描，基于飞弹的，以及范围形式。

　　攻击扫描是直接攻击武器。在屏幕上他们产生的效果只是那样，一个效果。当使用它的时候，和武器的实际操做没有任何关系。当你用手枪开火时，子弹被认为当即穿过世界并直接击中在它运动轨迹上的任何人/事物。

　　基于飞弹的武器有一个占用有限时间穿越世界的真实射弹，从而带给对方一些能够躲避的时间。

　　基于范围的武器像手榴弹和炸弹同样的东西，没必要击中就能够伤害到你；你只是必须处于爆炸范围内。处在那种爆炸范围内的玩家受到飞溅损害。熔岩是另一种形式的基于范围的武器。

　　那么你如何决定什么被击中而什么没有被击中呢？很好，这个问题把咱们带到了追踪，咱们将在接下来的物理学和人工智能章节更多的接触追踪。这是一组函数例程，当给定世界中一条从A点到B点的直线时，好比从枪的末端到预先定义的距离，它告诉游戏什么被击中。追踪很棒，但很昂贵，由于他们必须对那条线上的全部多边形进行‘碰撞检测’来看是否有什么地方被击中，更不用说模型和其它对象了。这也是一些物理学的工做方式，从一个给定的角色作一个笔直向下的跟踪能够知道地板位于什么地方。肆意的滥用追踪 — 如，在游戏的一幀中屡次使用它们 -- 对于今天许多游戏的速度降低是有责任的。在Jedi Knight II：Outcast，他们的光刀战斗已经遇到了这个问题，由于他们不只须要知道光刀是否击中了某处的什么和它如今的位置，并且对于它们之间的全部点都得这样，他们对光刀作了屡次追踪。

　　好吧，又一个章节结束了，仅仅剩下两个章节了。下面咱们介绍人工智能和搜索的更多细节。

第10部分:人工智能和导航（路径发现）

人工智能（AI）（终于到了游戏的重点部分......）

　　咱们上面已经用了其余九个章节介绍了游戏引擎，如今让咱们深刻到很是有趣和重要的人工智能主题。人工智能现在正在变成被谈论得最多的仅次于游戏引擎渲染能力的游戏开发领域之一，确实如此。直到大约两年半之前，游戏彷佛主要是在考虑你可以渲染多少个多边形，眼睛是多么的漂亮，和…好…劳拉的胸部是多么的有弹性...既然咱们如今已经可以渲染出很是真实的乳房，中心就开始转移到咱们实际上用那些多边形作什么了（即玩游戏）。由于它给你提供实际玩游戏的刺激做用和参与游戏世界中正在进行的事情，因此人工智能在这个领域很是关键。

　　人工智能包括了所有的东西，从在Tetris中决定哪一块新砖头掉落（这很大程度上知识一个随即数产生器），一直到创造基于小组的策略游戏，这些游戏和你交互，而且实际上在你玩的时候向你学习。人工智能包含了许多规则，若是你（做为一个游戏开发者）没有花费足够多的时间让它正确地工做，它会反过来在你屁股上咬一口。因此让咱们谈论一些哪些规则？这样你能更好地理解人工智能系统会确实是多么的复杂。为了不法律上的纠纷，咱们将使用一个假设的游戏而不是一个真实的游戏做为例子。

　　假设咱们的游戏中有坏份子生活在3D世界中，干着他们的事情，并且若是你打搅了他们的正常次序他们就会反抗你（玩家）。你必须决定的第一件事情就是他们正在从事的究竟是什么事情呢？他们正在守卫什么东西吗？在巡查？在计划一个聚会？在购买食品杂货？在整理床铺？创建行为的基线是游戏开发者的工做之一。一旦有了这个，你就总有NPC（非玩家角色）或计算机控制的‘人’可以恢复去作的事情，玩家与他们的交互就应当能被完成。

　　一旦咱们知道一个NPC角色须要作什么 —好比它在守卫一扇门，而且在这个区域小巡逻，NPC也必须有‘世界意识’。游戏设计者须要决定NPC的人工智能将如何看见世界，和它的知识范围。你将会仅仅说“计算机知道正在进行的每件事情”吗？这一般被认为是一件糟糕的事情，由于很是明显计算机可以看见和听见你不能看见和听见的事情，这被当成是在做弊。不是一种有趣的经历。或者你将模拟他的视野，这样他只可以对他能看见的事物做出反应吗？当有墙壁出现时这里就有问题了，由于你开始进入那些我在第九部分提到的‘追踪’例程，看看NPC是否试图对被墙壁挡住的人做出反应。这是一个很明显的人工智能问题，可是当涉及到门和窗户时，这个甚至变得更加复杂了。

　　当你开始为AI刺激例程增长听觉意识时，这依然变得更加复杂了。可是，这个意识是那些关键的“小事情”之一，这些使得假想的游戏世界彷佛更加真实，或者可以去除怀疑的悬念。若是你碰到过这样的事情，请举手：你在枪战中跟一个NPC交战，免除了一个NPC，你绕着角落行走并遇到了另一个NPC依然保持他的缺省行为模式，没有意识到刚刚发生的事情。如今，枪是嘈杂的事物，枪战可能已经明显地提醒了一个“倾听”的NPC有些事情正在进行。避免这种事情的技巧在于找到一个有效的方式来决定声源（即你武器的发射）的距离是否足够接近到NPC可以听见。

　　接下来就是决策例程。当咱们的巡逻NPC角色可以听到但不能看见某物时，你试图实现什么样的行为呢？他去寻找它吗？不理睬它？你如何决定什么是重要的声音他应该去或者不去调查？如同你看见的同样，这会很快变得很是的复杂。有不少方法来建造处理这些事情的代码，但一般这样是一个好主意，创建一个不是对特定的NPC而是对全部的NPC都起做用的系统，该系统基于你可以在游戏引擎之外的文本文件中创建的属性。这样就不须要程序员为一个给定的角色而改变AI，而且若是你对游戏代码作了改动，它将当即自动地应用到全部的角色，这在大多数状况下是一件好事情。

　　其余的世界意识问题会冒出来，好比这样的情形，两个守卫彼此紧挨着站立，你用狙击武器干掉了一个，而另一个站在哪儿彻底不知已经发生的事情。再者，遵照真实世界行为的细节是一款好游戏和一款伟大游戏的之间的区别。

　　让咱们说你已经把全部的刺激-响应部分准备好了—你已经扫描了世界，决定NPC应当对正在进行的一些事情做出反应—他听到了玩家角色发出了声响—而且你（游戏开发者）决定了他应当对这个作些什么—他将去调查。如今更加复杂的事情来了。他如何离开如今的位置，到达他认为发出声音的地方，而不会想一般的数字傻瓜同样跑到墙壁里面，碰到家具呢？继续往下看…

有关正确的路径 --- 世界导航
　　快速，准确的世界导航( 也叫作路径-发现)近来已经成为游戏开发者的圣杯。 让它看起来很是信服是一件很是困难的事情。你须要有局部世界的地理知识—墙壁的位置，台阶，悬崖和建筑物等的边缘。你也须要世界中的对象的知识—好比家具，汽车，尤为是其余人的位置。真正最后的因素是问题所在，一下子咱们将回到这一点上。

　　世界导航一般被分为两个领域，世界导航和局部导航。两者实际上只是范围上的区别，但大多数的程序员分别对待它们，由于这样处理起来容易一些。世界导航例程处理理解房间，门和通常的地理学，并计算出让玩家或者角色从世界中的A点到达B点的一条路径。“它将让你从A点到达B点”，这是一句很容易说的话，不是吗？提及来容易，但作起来很困难。理解世界是一个很是复杂问题，我已经看到过许多尝试过的解决办法。QuakeIII的机器人遵守建造的预先处理过的地图，通常的说法，使用原来地图的地面。预处理器检测地面元素，由地图建造者做上标记，并本身建造一个只使用地面的世界简化地图。机器人并不关心墙壁，由于他们从不接近它们，就像他们遵守地面的地图同样，设计上已经把避免墙壁构造在里面了。

　　其余方法在地图自己里面建造一些小的结点，AI能够追随它们。这些结点一般被建造在彼此的视线里面，有从一个结点到其余全部结点的链接，角色AI可以直接‘看见’，因此你就确保了从一个结点移动到另一个结点时AI不会试图穿越墙壁。若是有门或者降落物，你可以事先用这些结点对路径的信息编码，因而NPC可以采用适当的行为—等候电梯，打开一扇门，或者从一点跳到另一点。这其实是HereticII使用的系统，也是Raven在他们其余的大多数游戏中使用的系统。

　　关于这个主题，3D Realms的Jess Crable，如今为Duke Nukem Forever工做，如是说：

　　"导航在许多方面是个巨大的挑战，主要是当游戏中有大量正在发生的事情和一些非计划性的东西，好比障碍。为了不和（或）真实地对非计划性的障碍物导航（例如像另外的AI），AI须要很好地知道正在它周围发生的事情。比较而言另一个巨大的挑战就是真实感。若是AI正在表现玩家在实际生活中看到的一些东西，好比说一我的，或者一条狗，那么让它看上去真实可信就更加困难。"

　　而后就是局部导航。咱们可能有一条路径让咱们的 NPC从他在世界中的位置，移动到他认为听到声音的地方，但你不能盲目地按照这个执行并指望获得看起来不错的结果。这种性质的路径倾向于很是特定于一个给定的目的。当你沿着走廊从一个房间跑到另一个房间时，它很好，但若是你试图指导他穿越一个巨大的房间时，路径结点方法容易最终获得一些看起来很奇怪的发现路径。这些路径也不是动态的。由于他们被预先建造，他们不容易考虑到世界的任何动态变化。桌子可能有被移动过了，椅子被破坏了，墙壁被摧残，固然，人们会移动。这就是局部导航不一样于世界导航的地方。它必须考虑局部世界并导航NPC在里面穿越。它必须知道周围的环境，存在哪些能够选择的路径，并决定选择哪一条。

　　在局部导航中最大的问题是其余的NPC。给定一个发现路径的具体例程，若是你在相同的通常区域中有不止一个NPC，他们都试图到达世界的同一地点，结果是他们都很是容易有相同的路径。而后他们试图沿着这个路径行进，结果彼此遇到一块儿，而后花费他们全部的时间试图将彼此分开，而且一旦成功地分开了，他们再次试图到达目标，而后咱们又再次看到一样的事情发生。这一切看起来都是很是的愚蠢，这不是大多数人想要的效果。因此须要一些路径发现中的变化来避免这种情形，须要一些妥善处理避免的代码。有大量可以帮助解决这种情形的算法。

人工智能和角色动画问题
　　固然，当角色本身在世界中行走时你必须彻底地决定你想要角色播放什么动画。听起来无足轻重？不是的。关于这个主题，Raven的 Chris Reed—Soldier of FortuneII使用名为LICH的AI系统的如今的负责人—如是说：

　　"此刻我能告诉你，咱们在平滑移动上正有着最大的困难。在一个多丘陵的长满草的丛林中试图让五个角色在彼此附近行走是一个很是困难的问题。让底层系统完美是重要的，由于除非角色在较低层次上（避免墙壁，适当的动画）看起来真实，他们不可以有效地表达任何较高层次决定的智能。因为这个单独的缘由，动画和底层的移动是最重要的和最难实现的。它确实须要完美。"

　　所以咱们已经让咱们的角色从A点到达了B点，他本身穿越世界，在途中避免障碍物，正确播放动画，如今到达了这里。他看见了你。接下来作什么呢？很明显更多的是做出决策。他将向你射击。太棒了。你回应射击。如今干什么？当他试着逃走的时候，如今你再次经历所有一样的事情。

　　为了让这些情形看起来使人信服，你看见了这里必需要处理的大量问题。若是你创建你的AI使用没有动画的行为让NPC执行，这能被混合。一些Soldier of Fortune中的AI就是这样的例子。他们受到了指责，由于坏家伙没有以适当的方式对刺激做出反应。当他们明显应该这样作的时候，敌方NPC不扫射，或者不逃跑。部分问题是他们没有扫射敌人NPC的动画，或者让他们往回跑，由于空间的问题。所以世界上全部最伟大的AI代码都不可以解决这个问题。这是全部要考虑的重要事情。

　　想知道隐藏的难点吗？看看我前面全部的描述，而后试着将它应用到一组NPC上，这些NPC彼此必须说话，设定目标，彼此沟通，但不妨碍彼此的方式。一旦你这么作了，试试那些代码，做为玩家的队友作上面所描述的这些，然而不要在枪战中妨碍他。如今这是复杂的。而后这成为乐趣。这是最困难的部分。Raven的 Chris Reed关于AI‘感受’的一些评论：

　　"我认为反馈是AI的一个极大的问题。若是角色对于他周围环境的变化不产生反应，游戏的真实感就被彻底打破了。这有许多明显的例子(听见枪炮声，看见同伴被击中...)，以及一些更加微妙的事情(当两我的经过门厅时看着彼此并点头致意)。玩家是乐意接受一些生硬和可预测性的，可是这些事物容易把游戏带到现实生活。"

　　而且Jess Crable赞同：

　　"平衡是很是重要的…对玩家将会有多大的乐趣相当重要，但还有其余的问题要平衡。游戏玩家时常说他们想在游戏中看见更加真实的人工智能。然而，太多的真实感开始把乐趣带走。在这二者之间必需要有一个好的平衡。变化和随机一样也很重要—行为的变化，和保持在可信范围内的必定程度的不可预测性。"

游戏规则与天然发生的游戏
　　在咱们关于AI的全部描述中，咱们采用的是FPS的方式。有不止一种的AI。咱们已经描述的是处理3D世界一组规则。AI远远不止这些。时常最好的AI实际上很是的简单。它就是一组规则，玩家必须响应和处理的响应（或开始）动做的规则。

　　这里应当处理一个被称为“天然发生的游戏”的专业术语。天然发生的游戏本质上创造游戏将遵照的规则，那将会形成游戏程序员不能预见的情形。

　　举例来讲，象棋能被认为是天然发生的游戏。有一组规则，但游戏可以陷入各类程序员不可以以个别方式处理的情形。你不能为每一种可能的棋局情形编码规则。很清楚，游戏玩家每次不会老是面临相同的游戏情景。必定程度上，进行中的游戏情形会根据他的行动而发生变化。Black and White是这种情形的一个完美的例子，和The Sims同样—游戏有它本身的规则，但你如何运用和调和他们是你本身的事情。实际上，你在玩游戏的过程当中创造着游戏，而不是照着游戏设计者/程序员已经为你定义的路线进行。

　　有可能把基于规则的，天然发生的游戏方式和FPS环境混合在一块儿。Half Life中的一些海军陆战队士兵的行为就是这样作的—压制火力和侧翼攻击从设定的规则中动态完成。它看起来是动态的，并且必定程度上它是这样。然而，在FPS世界中仅仅有一组规则时常是不够的。几何和其余AI时常可以战胜简单的规则，这让保持正确并依然有趣变得更加困难。因此对那些可怜的AI程序员有一些同情心吧。他们的工做不容易。

　　好吧，下面还有一个章节，仅仅还剩下一个章节了。在最后的章节里，咱们将讨论头顶显示，菜单系统，游戏定制和配置，游戏引擎版权与建造，最后是游戏“mods”。

第11部份:最后的章节

前端
　　你已经看到了菜单系统，你可能理解游戏内的头顶显示（HUDs）时常是游戏经历中被忽视和诽谤的部分。最近，这个领域开始被给人印象很是深入的Black and White所关注，这款游戏实际上没有HUD。在PeterMolyneux经历了DungeonKeeper之后，它在屏幕上大量的图标，他决定游戏的大部分被这些图标占用了，主要的屏幕没有被足够利用。所以他决定废除全部这些东西。Peter迈了大胆的一步，咱们为你喝彩。很不幸，这种方式适用于B&W这类风格的游戏，但它并不老是对其余种类的游戏有用。

　　大致而言HUDs应该是不引人注意的，只提供你须要的关键信息；这自己会在设计团队中引起争议。Soldier of Fortune的最初设计在屏幕上有一个图标，当被击中时向你准确显示身体的哪一个部位被击中。当他们决定他们不许备为不一样身体部位的伤害而处罚玩家时，最后这个被丢弃了。在一些早期的Soldier of Fortune的屏幕截图上，依然可以在屏幕的右上角看见这个图标。

　　在一个完美的世界中HUD是可配置的，所以你能决定显示什么，在哪里显示，显示多久。若是你以为不须要局部雷达，那么它应当能够被移除掉。任何显示的HUD信息应当有必定程度的alpha（透明度），所以若是须要你能透过它们看见后面的事物。

　　说到配置，我是一个游戏我的设定的十足的狂热者。由于没有即时存储设备存储配置文件，在游戏机游戏上不是普遍地能够得到配置，这足够公平。可是随着PS2和Xbox硬盘驱动器的来临，我期待在未来看见配置被更多地使用。可以被定制的每件事物都应当这样，如同我看见的同样。很明显，也应当为每件事物提供合理的缺省配置，所以玩家没必要一屏一屏地进行枯燥的选择过程---一下子咱们将更多地讨论这个---玩家应当可以根据我的的喜爱和可得到的计算能力定制游戏经历。

　　回到缺省事物，保持必需的修改最小化很是重要。做出最少的决定而快速进入游戏老是一件好事情。Mortal Kombat，甚至QuakeIII都有一个很是快速的游戏进入系统。少量选择，而后你就进入游戏了。这并不意味着你不能有一个接一个的菜单容许你改变每件事物，但它们不该当是必需的且应当已经有合理的缺省设置了。若是甚至在你进入游戏之前你必须用14个屏幕设置一个角色，多是第一次你可能没有关于你正在选择的线索并且仅仅会作任何事情以经过屏幕，可能作了一些会极大影响初始游戏体验的事情。并且有可能它将会是不利的影响，做为一个游戏程序员/设计者，我在这里告诉你不管你作任何事情，让玩家第一次选择一些愚蠢的事物，无需让它更糟糕你就会有足够的机会制造不好的第一印象。

　　藉由关于配置和HUDs（连同前面十个章节的大量信息）的简要论述，咱们最终结束了关于现代游戏引擎的主要建造元素的讨论。固然，依赖于游戏的类型和谁在制做它们，每一个特定的游戏对这个清单有它本身的添加（或者减小）。然而，有一些对于游戏引擎实际上不是引擎设计部分的其余元素，可是它们却须要一些关注。

游戏引擎许可与组件
　　现在若是你要制做一款游戏，时常最快的开始方式就是购买现有的游戏引擎许可证并在此基础上开发---这就是Raven所作的事情，最近使用Quake3引擎编写了Star Trek Elite Force。Half Life基于Quake 1引擎，Deus Ex基于Unreal，这个清单还在继续。现在有两种许可证方式---一个彻底的游戏引擎（或游戏操做系统如Jason Hall授予LithTech），或者一组给定问题的部分解决方案。这方面一个好的例子会是RenderWare，这是一个渲染场景的部分解决方案并给你提供一些物理。你不能仅仅拍着一些模型并把它们称为完成了的游戏---还须要有声音系统，游戏机制，等等。但它确实给了你一个创建游戏的坚实基础。还记得我在渲染和物理学章节提到的全部数学知识吗？很好，这样你就避免了全部那些东西。

　　藉由LithTech，Unreal和Quake，你确实获得了彻底的解决方案--或至少是创始者为他们的游戏所须要的所有解决方案。记住QuakeIII是能够多人玩的，不时创建在单人游戏的基础之上的好比说Unreal Tournament。使用QuakeIII，你失去了单人游戏需用的某些系统，像读取/存储，脚本等等。你只是的到了Id公司制做一款游戏须要的东西，而不必定就是你所须要的东西。有时侯若是系统的一个局限刚好是你所须要的东西时，这多是一个真正的缺点。给Star Trek Voyager加入读取/存储和脚本：EliteForce不是野餐，可是必须的。然而，使用Quake3引擎依然是领先的开端。

　　Unreal有名的TimSweeney对于今天一些流行的预先打包的游戏引擎解决方案有一些评论。

　　"我认为我能公平地比较游戏引擎(Quake，Unreal等)和游戏组件如 RenderWare 和 Karma。游戏引擎是包含游戏开发的全部技术方面的组织严密的框架：渲染，编辑工具，物理学，人工智能，网络，等等。

　　它们针对那些想要一个彻底的，现成的解决方案的开发者，以便他们可以把精力集中在游戏可玩性和内容上。像RenderWare这样的游戏组件针对那些正在开发他们本身的技术但不想在一些已经很完善的技术领域作重复开发的开发者。

　　游戏引擎有解决游戏开发中所有技术问题的优势，有容易把一些包括游戏类型的假设创建在里面的缺点。举例来讲，Unreal已经被用来制做第一人称射击游戏，第三人称动做游戏，角色扮演游戏，甚至弹球游戏。可是没有人用它制做飞行模拟类游戏—它不是适合这种游戏的技术。游戏引擎带着完整的源代码而来，这是祝福 ( 你能彻底看见内部正在发生什么，你能够自由地根据你的须要扩充它)，也是诅咒 (若是你改变它，你将必须把变化合并进新的版本以内)。

　　游戏组件有解决所关注领域的技术问题的优势，如渲染或者物理学，不用花费大量的时间在这方面就能够比典型的开发者作得更好。他们的缺点是把这些组件整合进你的引擎其他部分就是你本身的事情了，这有时候会至关复杂。游戏组件通常没有完整的源代码伴随，所以并不老是很清楚他们内部作了些什么。"

　　谢谢Tim，很精妙的分析。

创建你本身的游戏引擎?
　　你可能创建本身的引擎而不是购买许可证。这避免了谁拥有什么，版税等全部的法律纠纷，并且若是你产出了质量足够好的东西，你甚至可以向别人出售许可证。然而，正如已经指出的那样，这须要时间和金钱来完成，更不用说绝对优秀的程序员了。LithTech已经发展了不少年，与Unreal相似。颇有趣，主要是由于变化的硬件和API版本，实际上Unreal最初的版本花费了四年时间才完成。当他们刚开始的时候，软件渲染是惟一的游戏。当开发正在继续的时候，3dfx带来了Glide，而后是Nvidia的TNT显卡（从那时起硬件和APIs确实有了更多的进步）。这就是它为什么支持这么多不一样的渲染途径的缘由。固然在一个相同的引擎内支持全部这些是一场编码恶梦，但那是另外的事。每一个引擎有模块化的方式，而且当一个模块---好比说，脚本---变得过期了或者需求变化了，你只须要把它抽出来并开始作一个新的模块。

　　Quake引擎经历时间有更加完整的进化发展。相应于Id公司下一个游戏的一组需求，当John Carmack创造了在当时的硬件上运行最快的东西时，引擎的每一个版本都通过了彻底的重写。QuakeII彻底重写了很多于四次，我我的看到了QuakeIII的机器人代码的三个不一样的版本。其余的开发者也没有可以避免这种情形。John Scott，建造了Soldier of Fortune II的地表系统，曾对我提到，在动态地表生成上他曾尝试了许多方法让物理学正确地工做。

　　建造技术或者完整的引擎不是件容易的事情。当今的游戏引擎须要许多，许多的系统，就如同许多人们尝试创造‘下一个大的引擎’时所发现的那样，从屏幕上文本的简单显示到高级人工智能。而且如我前面提到的，不断发展的新技术使得建造一个快速，高效的引擎是一个变化的目标。事实上，我见到有人仅仅为了让一个带alpha的纹理正确地显示而在PS2的混合模式上花了四天时间。

　　值得考虑的其余引擎有GarageGames的Tribes2引擎---被称为TheTorque Game Engine。个人理解是它能够收取微小数量的许可费用，未来有一些版税协议。这是的确值得考虑的事情。你能够在这里看到这个引擎的特征细节http://www.garagegames.com/index.php?sec=mg&;mod=v12&page=features。而后就是SeriousSam 引擎。这也是须要许可证的，的确值得看一看。若是你对它有兴趣的话，能够联系God Games---他们应当能够给你指明正确的方向。

　　在网络上有一些你能够下载的自由引擎---首先想到的是Crystal Space引擎。你能够从这里下载http://sourceforge.net/projects/crystal，并在你的游戏中随意使用。这不是一个专业的引擎，但看看全部的部分如何结合在一块儿时常是一个好的学习经历。

　　还有就是最初的QuakeEngine，如今已经被Id公司开放源代码。对于任何有抱负的游戏程序员来讲这是一个很好的开端----下载它，编译，开始调整。值得记住的是，这个擎是许多年之前的了，与Quake III或者新的Doom没有多少类似性。重复一遍，它确实是个好的开始。你能从这里找到发现好的资源网页http://www.inside3d.com/qip/home.shtml。

　　确实，这一切都是时间与金钱的事情。若是你没有时间开发一个新的引擎，就不要介意花钱使用第三方的引擎，去购买一个吧。注意，对于要求使用他们引擎的团队，现在大多数引擎许可团体有很合理的途径。尽量地让许多人们使用他们的技术，所以这种经验变成了工业标准，这对他们有好处。

‘Mod’社区
　　看一眼任何在线游戏服务器的统计数字，显示出Counter Strike服务器比任何其余游戏服务器都要多。和它最近的竞争者（Quake III或者Unreal Tournament）相比，几乎有两倍的CS服务器。

　　游戏mods 所有来自于一些编辑程序，这些程序让游戏者可以修改DOOM最初的.WAD文件，提供他们本身自家制造的关卡设计和纹理。人们开始玩这些(大体)自家建造的工具，而且也发现了他们能够产生其余人想玩的关卡。Id注意了这个趋势，并且将Quake系列引擎带到了一个新的阶段，这样设计游戏，使得游戏是用户可修改的。他们甚至发布他们本身的设计工具，指令，并且甚至---喘口气---游戏中的代码，如此有抱负的游戏程序员能够在Quake Universe中玩。你可能从这个创造出本身版本的Quake连线经历。许多今天的业内大师来自这种早期的修改经验。如今有名的设计者如LevelLord和CliffyB在这个行业中就是这样开始的。最高的荣誉来自一位名叫ZOID的绅士，他提出了3Wave CTF，第一个‘夺取旗帜’的游戏，游戏中须要人们组队---连线游戏从纯粹的死亡竞赛以来的第一次进化发展。

　　一些游戏是如此的流行以至于他们每一年都有事件发生。好比说，Quake有一个QuakeCon，在Mesquite Texas，Id软件公司所在地，举行的一年一次的quake大会。人们带着他们的PC来到这里，或为了看最新的mods或是展现的基于Quake引擎的游戏。

　　现在你制做的任何游戏须要或者有杀人者可多人玩的经验，或者有能够很是容易修改的内容这样连线‘修改者’能利用你的游戏并制做出其余游戏来。这一切延长了你游戏的生命，有但愿卖出更多，人们购买它，能够下载mods来玩最新的Quake III修改版本：The Teachers Strike Back。但你不能仅仅生产一款游戏，发布你的工具，就袖手旁观。实际上你最初必须把代码设计成不须要程序员就能够容易地扩充, …好吧, … John Carmack。

　　做为一个开发者，你须要在那里能够见获得，并为那些在家中想利用你的游戏和用它作点别的什么的人们提供经验和帮助。这种支持能够有许多形式----一个亲切友好的词语，一段代码，建议，宣传或只是金钱。只要有这个它时常不介意采用何种形式。

　　在这里你选择哪一个第三方工具用来建造内容多是相当重要的。在Raven，过去咱们已经作了一些开发决定，在这方面没有什么帮助，因为咱们为大多数的建模和全部的动画需求使用了SoftImage。虽然它是制做咱们须要的动画的最好工具，对于家庭业余爱好者来讲它太过昂贵了。这就给那些家庭业余爱好者在扩充咱们制做的内容时带来了问题，所以他们容易抛弃咱们转而寻求那些比较容易制做内容的游戏。在建造或者选择一个引擎时这确实是值得留意的事情。为了响应制做游戏mods，Discreet在市场上发布了一个3D Studio Max的‘lite’版本，称为gmax。最好的是，它是免费的。若是你想要试一试，你能从这里抓取它http://www.discreet.com/products/gmax/gmaxconsumer/index.html。

　　最后在线游戏的成功时常能追踪到 mod 社区，所以我认为感谢他们作了件好的工做是公平的。我过去时常说，在行业中到达一个‘真正的’工做最快的方式是从一个mod开始，说明你有完成它的训练并用它做为一个面试得到者。不能说，"我能作这个"就像已经完成了同样。所以去到那里并开始吧。你损失什么了吗？

有关做者 　　JakeSimpson 是一个游戏程序员，断断续续在这个行业已经有大约20年了。他在英国本土从15岁开始，在C64的时代，Sinclair Spectrums和 BBC Micros，经历了 Amiga和ST，离开了一段时间，而后90年代中期至后期在MideayGames写街机游戏。他最近在RavenSoftware工做过，制做有Soldier of Fortune， Heretic， Hexen， Star Trek : Voyager : Elite force和 JediKnight II : Outcast，在北加州的Maxis能够找到他，为Will Wright的游戏产品工做。业余时间他为GameBoy Color和Advance编写代码，由于“你能尽量地远离C++编码，并且，如同John Carmack所说，底层编程对程序员的灵魂有好处”。