游戏引擎剖析(Game Engine Anatomy 101)
原文作者：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 管线
- 高层的概观
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's Lightsaber在 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关于脚本系统的论述
去年底我访谈了Jim Dose--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 这样的程序产生的动画区分开来。
在一些时候，使用者可能需要一些方法决定一个脚本为何没有做他们所期望的事情。一些形式的除错工具能使这件工作非常容易。至少，决定哪些脚本正在运行和脚 本当前位置的一些方法必需的。在脚本中检查变量，开始，停止，和单步执行的能力也是有帮助的。通常，一个程序师能够在他们的调试器中进行除错，但这个过程 要比如果有一些内建的脚本调试器可用时花费的时间更长。
第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。在Peter Molyneux经历了Dungeon Keeper以后，它在屏幕上大量的图标，他决定游戏的大部分被这些图标占用了，主要的屏幕没有被足够利用。因此他决定废除所有这些东西。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加入读取/存储和脚本：Elite Force不是野餐，但是必须的。然而，使用Quake3引擎依然是领先的开端。
Unreal有名的Tim Sweeney 对于今天一些流行的预先打包的游戏引擎解决方案有一些评论。
"我认为我能公平地比较游戏引擎 (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的混合模式上花了四天时间。
值得考虑的其他引擎有Garage Games的Tribes 2引擎---被称为The Torque Game Engine。我的理解是它可以收取微小数量的许可费用，将来有一些版税协议。这是的确值得考虑的事情。你可以在这里看到这个引擎的特征细节http://www.garagegames.com/index.php?sec=mg&mod=v12&page=features 。 然后就是Serious Sam 引擎。这也是需要许可证的，的确值得看一看。如果你对它有兴趣的话，可以联系God Games---他们应当可以给你指明正确的方向。
在网络上有一些你可以下载的自由引擎---首先想到的是Crystal Space引擎。你可以从这里下载http://sourceforge.net/projects/crystal ，并在你的游戏中随意使用。这不是一个专业的引擎，但看看所有的部分如何结合在一起时常是一个好的学习经历。
还有就是最初的Quake Engine，现在已经被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开始，说明你有完成它的训练并 用它作为一个面试获得者。不能说，"我能做这个" 就像已经完成了一样。因此去到那里并开始吧。你损失什么了吗？
有关作者
Jake Simpson 是一个游戏程序员，断断续续在这个行业已经有大约20 年了。他在英国本土从15岁开始，在C64的时代，Sinclair Spectrums和 BBC Micros，经历了 Amiga 和ST，离开了一段时间，然后90年代中期至后期在Mideay Games写街机游戏。他最近在Raven Software工作过，制作有Soldier of Fortune， Heretic， Hexen， Star Trek : Voyager : Elite force 和 Jedi Knight II : Outcast，在北加州的Maxis可以找到他，为Will Wright的游戏产品工作。业余时间他为GameBoy Color和Advance编写代码，因为“你能尽可能地远离C++编码，而且，如同John Carmack所说，底层编程对程序员的灵魂有好处”。
(全文完)
from：http://blog.csdn.net/compiler/archive/2009/02/17/3899951.aspx
http://blog.csdn.net/compiler/archive/2009/02/17/3899983.aspx
http://blog.csdn.net/compiler/archive/2009/02/17/3899992.aspx
http://blog.csdn.net/compiler/archive/2009/02/17/3900000.aspx
http://blog.csdn.net/compiler/archive/2009/02/17/3900003.aspx
http://blog.csdn.net/compiler/archive/2009/02/17/3900006.aspx
http://blog.csdn.net/compiler/archive/2009/02/17/3900008.aspx
http://blog.csdn.net/compiler/archive/2009/02/17/3900013.aspx
http://blog.csdn.net/compiler/archive/2009/02/17/3900014.aspx
http://blog.csdn.net/compiler/archive/2009/02/17/3900020.aspx
http://blog.csdn.net/compiler/archive/2009/02/17/3900018.aspx
转载于:https://www.cnblogs.com/ykmzy/articles/5367443.html
本文链接：https://my.lmcjl.com/post/15414.html
4 评论