游戏编程简章与游戏引擎

经典word整理文档，仅参考，双击此处可删除页眉页脚。本资料属于网络整理，如有侵权，请联系删除，谢谢！)第1部分:游戏引擎介绍，渲染和构造3D世界介绍自Doom游戏时代以来我们已经走了很远。DOOM不只是一款伟大的游戏，它同时也开创了一种新的游戏编程模式:游戏"引擎"。这种模块化，可伸缩和扩展的设计观念可以让游戏玩家和程序设计者深入到游戏核心，用新的模型，场景和声音创造新的游戏，或向已有的游戏素材中添加新的东西。大量的新游戏根据已经存在的游戏引擎开发出来，而大多数都以ID公司的Quake引擎为基础，这些游戏包括CounterStrike，TeamFortress，TacOps，StrikeForce，以及QuakeSoccer。TacOps和StrikeForce都使用了UnrealTournament引擎。事实上，"游戏引擎"已经成为游戏玩家之间交流的标准用语，但是究竟引擎止于何处，而游戏又从哪里开始呢?像素的渲染，声音的播放，怪物的思考以及游戏事件的触发，游戏中所有这一切的幕后又是什么呢？如果你曾经思考过这些问题，而且想要知道更多驱动游戏进行的东西，那么这篇文章正好可以告诉你这些。本文分多个部分深入剖析了游戏引擎的内核，特别是Quake引擎，因为我最近工作的公司RavenSoftware已经在Quake引擎的基础上开发出了多款游戏，其中包括著名的SoldierofFortune。开始让我们首先来看看一个游戏引擎和游戏本身之间的主要区别。许多人们会混淆游戏引擎和整个游戏。这有点像把一个汽车发动机和整个汽车混淆起来一样。你能够从汽车里面取出发动机，建造另外一个外壳，再使用发动机一次。游戏也像那。游戏引擎被定义为所有的非游戏特有的技术。游戏部份是被称为'资产'的所有内容(人工智能和物理学)和为了使游戏运行或者控制如何运行而特别需要的程序代码，比如说AI--人工智能。对于曾经看过Quake游戏结构的人来说，游戏引擎就是Quakeexe是QAGame。dll和CGame。dll。如果你不知道这是什么意思，也没有什么关系；在有人向我解释它以前，我也不知道是什么意思。但是你将会完全明白它的意思。这篇游戏引擎指导分为十一个部份。是的，从数量上来说，总共是十一个部份!每个部分大概3000字左右。现在就从第一部分开始我们的探索吧，深入我们所玩游戏的内核，在这里我们将了解一些基本的东西，渲染器让我们从渲染器来开始游戏引擎设计的探讨吧，我们将从游戏开发者(本文的背景)也让您像我们一样思考问题!什么是渲染器，为什么它又这么重要呢？好吧，如果没有它，你将什么也看不到。它让游戏场景可视化，让玩家/观众可以看见场景，从而让玩家能够根据屏幕上所看到的东西作出适当的决断。尽管我们下面的探讨可能让新手感到有些恐惧，先别去理会它。渲染器做些什么？为什么它是必须的？我们将会解释这些重要问题。当构造一个游戏引擎的时候，你通常想做的第一件事情就是建造渲染器。因为如果看不见任何东西–那么你又如何知道你的程序代码在工作呢?超过50%的CPU处理时间1/30花费在渲染器上面；通常也是在这个部分，游戏开发者将会受到最苛刻的评判。如果我们在这个部分表现很差，事情将会变得非常糟糕，我们的程序技术，我们的游戏和我们的公司将在10天之内变成业界的笑话。它也是我们最依赖于外部厂商和力量的地方，在这里他们将处理最大限度的潜在操作目标。如此说来，建造一个渲染器确实不象听起来那么吸游戏或许永远不会跻身于排行榜前10名。如今，在屏幕上生成像素，涉及到3D加速卡，API，三维空间数学，对3D硬件如何工作的理解等等。对於主机（游戏机）游戏来说，也需要相同类型的知识，但是至少对于主机，你不必去尝试击中一个移动中的目标。因为一台主机的硬件配置是固定的"时间快照"，和PC（个人计算机）不同，在一台主机的生命期中，它的硬件配置不会改变。在一般意义上，渲染器的工作就是要创造出游戏的视觉闪光点，实际上达到这个目标需要大量的技巧。3D图形本质上是用最少的努力创造出最大效果的一门艺术，因为额外的3D处理在处理器时间和和内存带宽方面都是极为昂贵的。它也是一种预算，要弄清楚你想在什么地方花费处理器时间，而你宁愿在什么地方节省一些从而达到最好的整体效果。接下来我们将会介绍一些这方面的工具，以及怎样更好的用它们让游戏引擎工作。建造3D世界最近，当我和一位从事计算机图形方面工作长达数年之久的人会谈时，她向我吐露道，当她第一次看到实时操纵计算机3D图象时，她不知道这是怎么实现的，也不知道计算机如何能够存储3D图象。今天这对于在大街上的普通人来说或许是真实的，即使他们时常玩PC游戏，游戏机游戏，或街机游戏。下面我们将从游戏设计者的角度讨论创造3D世界的一些细节，你也应该看一看DaveSalvator所写的“3D管线导论“，以便对3D图象生成的主要过程有一个整体的了解。3D3D世界中的一系列点(被称为顶点)，彼此之间有相互关系，所以计算机知道如何在世界中的这些点之间画线或者是填充表面。一个立方体由8个点组6个表面，分别代表它的每一个面。这就是3D对象储存的基础。对于一些比较复杂的3D物体，比如说一个Quake的关卡，将有数以千计(有时数以十万计)的顶点，和数以千计的多边形表面。本质上与上面的立方体例子类似，它仅仅是由许许多多的小多边形组成的一些复杂场景。模型和世界如何储存是渲染器的一部份功能，而不属于应用程序/游戏部份。游戏逻辑不需要知道对象在内存中如何表示，也不需要知道渲染器将怎样把他们显示出来。游戏只是需要知道渲染器将使用正确的视野去表示对象，并将在正确的动画帧中把正确的模型显示出来。在一个好的引擎中，渲染器应该是可以完全被一个新的渲染器替换掉，并且不需要去改动游戏的一行代码。许多跨平台引擎，而且许多自行开发的游戏机引擎就是这样的，如Unreal引擎，--举例来说，这个游戏GameCube版本的渲染器就可以被你任意的替换掉。让我们再看看内部的表示方法—除了使用坐标系统，还有其他方法可以在计算机内存里表示空间的点。在数学上，你可以使用一个方程式来描述直线或曲线，并得到多边形，而几乎所有的3D显示卡都使用多边形来作为它们的最终渲染图元。一个图元就是你在任何显示卡上面所能使用的最低级的绘制（渲染）单位，几乎所有的硬件都是使用三个顶点的多边形(三角形)。新一代的nVidia和ATI显卡可以允许你以数学方式渲染(被称为高次表面)，但因为这不是所有图形卡的标准，你还不能靠它作为渲染策略。从计算的角度来看，这通常有些昂贵，但它时常是新的实验技术的基础，例如，地表的渲染，或者对物件锐利的边缘进行柔化。我们将会在下面的曲面片小节中更进一步介绍这2/30些高次表面。剔除概观问题来了。我现在有一个由几十万个顶点/多边形描述的世界。我以第一人称视角位于我们这个3D世界的一边。在视野中可以看见世界的一些多边形，而另外一些则不可见，因为一些物体，比如一面看得见的墙壁，遮挡住了它们。即使是最好的游戏编码人员，在目前的3D显卡上，在一个视野中也不能处理300，000个三角形且仍然维持60fps(一个主要目标)。显卡不能处理它，因此我们必须写一些代码，在把它们交给显卡处理之前除去那些看不见的多边形。这个过程被称为剔除。有许多不同的剔除方法。在深入了解这些之前，让我们探讨一下为什么图形显示卡不能处理超高数量的多边形。我是说，最新的图形卡每秒钟不能处理几百万个多边形吗？它不应该能够处理吗?首先，你必须理解市场销售宣称的多边形生成率和真实世界的多边形生成率。行销上宣称的多边形生成率是图形显示卡理论上能够达到的多边形生成率。如果全部多边形都在屏幕上，相同的纹理，相同的尺寸大小，正在往显示卡上传送多边形的应用程序除了传送多边形以外什么也不做，这时显卡能处理多少多边形数量，就是图形芯片厂商呈现给你的数字。--多边形的3D变换，光照计算，拷贝较多的纹理到显卡内存，等等。不仅纹理要送到显示卡，而且还有每个多边形的细节。一些比较新的显卡允许你实际上在显卡内存本身里面储存模型/世界几何细节，但这可能是昂贵的，将会耗光纹理正常可以使用的空间，所以你最好能确定每一帧都在使用这些模型的顶点，否则你只是在浪费显示卡上的存储空间。我们就说到这里了。重要的是，在实际使用显卡时，并不必然就能达到你在显卡包装盒上所看到的那些指标，如果你有一个比较慢速的CPU，或没有足够的内存时，这种差异就尤为真实。基本的剔除方法最简单的剔除方式就是把世界分成区域，每个区域有一个其他可见区域的列表。那样，你只需要显示针对任何给定点的可见部分。如何生成可见视野区域的列表是技巧所在。再者，有许多方法可以用来生成可见区域列表，如BSP树，窥孔等等。可以肯定，当谈论DOOM或QUAKE时，你已经听到过使用BSP这个术语了。它表示二叉空间分割。BSP是一种将世界分成小区域的的方法，通过组织世界的多边形，容易确定哪些区域是可见的而哪些是不可见的–从而方便了那些不想做太多绘制工作的基于软件的渲染器。它同时也以一种非常有效的方式让你知道你位于世界中的什么地方。在基于窥孔的引擎(最早由3DRealms已经取消的Prey项目引入游戏世界)个区域(或房间)都建造有自己的模型，通过每个区域的门(或窥孔)能够看见另外的区段。渲染器把每个区域作为独立的场景单独绘制。这就是它的大致原理。足以说这是任何一个渲染器的必需部份，而且非常重要。尽管一些这样的技术归类在"遮挡剔除"之下，但是他们全部都有同样的目的:尽早消除不必要的工作。对於一个FPS游戏(第一人称射击游戏)而且游戏玩家承担视野的控制，丢弃或者剔除不可见的三角形就是绝对必要的了。对空间模拟来说也是这样的，你可以看见很远很远的地方–剔除超过视觉范围外面的东西就非常重要。对于视野受到限制的游戏来说–比如RTS(即时战略类游戏)--通常比较容易实现。通常渲染器的这个部份还是由软件来完成，而不是由显卡完成，由显卡来做这部分3/30工作只是一个时间问题。基本的图形管线流程一个简单的例子，从游戏到多边形绘制的图形管线过程大致是这样:•游戏决定在游戏中有哪些对象，它们的模型，使用的纹理，他们可能在什么动画帧，以及它们在游戏世界里的位置。游戏也决定照相机的位置和方向。•游戏把这些信息传递给渲染器。以模型为例，渲染器首先要查看模型的大小，照相机的位置，然後决定模型在屏幕上是否全部可见，或者在观察者(照相机视野)的左边，在观察者的后面，或距离很远而不可见。它甚至会使用一些世界测定方式来计算出模型是否是可见的。(参见下面这条)•世界可视化系统决定照相机在世界中的位置，并根据照相机视野决定世界的哪些区域/多边形是可见的。有许多方法可以完成这个任务，包括把世界分割成许多区域的暴力方法，每个区域直接为"我能从区域D看见区域AB&C"，到更精致的BSP(二叉空间分割)世界。所有通过这些剔除测试的多边形被传递给多边形渲染器进行绘制。•对於每一个被传递给渲染器的多边形，渲染器依照局部数学(也就是模型动画)和世界数学(相对于照相机的位置?)对多边形进行变换，并检查决定多边形是不是背对相机(也就是远离照相机)。背面的多边形被丢弃。非背面的多边形由渲染器根据发现的附近灯光照亮。然后渲染器要看多边形使用的纹理，并且确定API/图形卡正在使用那种纹理作为它的渲染基础。在这里，多边形被送到渲染API，然后再送给显卡。很明显这有些过分简单化了，但你大概理解了。下面的图表摘自DaveSalvator's3D管线一文，可以给你多一些具体细节:3D管线-高层的概观1.应用程序/场景•场景/几何数据库遍历•对象的运动，观察相机的运动和瞄准•对象模型的动画运动•3D世界内容的描述•对象的可见性检查，包括可能的遮挡剔除•细节层次的选择(LOD)2.几何图元•变换(旋转，平移，缩放)•从模型空间到世界空间的变换(Direct3D)•从世界空间到观察空间变换•观察投影•细节接受/拒绝剔除•背面剔除(也可以在后面的屏幕空间中做)•光照处理•透视分割-变换到裁剪空间•裁剪•变换到屏幕空间3.三角形生成•背面剔除(或者在光照计算之前的观察空间中完成)4/30•斜率/角度计算•扫瞄线变换4.渲染/光栅化•着色•纹理•雾•Alpha透明测试•深度缓冲•抗锯齿(可选择的)•显示通常你会把所有的多边形放到一些列表内，然後根据纹理对这个列表排序(这样你只需要对显卡传送一次纹理，而不是每个多边形都传送一次)，等等。在过去，会把多边形按照它们到相机的距离进行排序，首先绘制那些距离相机最远的多边形，但现在由于Z缓冲的出现，这种方法就不是那么重要了。当然那些透明的多边形要除外，它们要在所有的非半透明多边形绘制之后才能够绘制，这样一来，所有在它们后面的多边形就能正确地在场景中显现出来。当然，象那样，实际上你必须得从后到前地绘制那些多边形。但时常在任何给定的FPS游戏场景中，通常没有太多透明的多边形。它可能看起来像有，但实际上与那些不透明的多边形相比，其比率是相当低的。一旦应用程序将场景传递到API，API就能利用硬件加速的变换和光照处理(T&L)，这在如今的3D显卡中是很平常的事情。这里不讨论涉及到的矩阵数学(参见Dave的3D管线导论)，几何变换允许3D显卡按照你的尝试，根据相机在任何时间的位置和方向，在世界的正确角度和位置绘制多边形。对于每个点或顶点都有大量的计算，包括裁剪运算，决定任何给定的多边形实际上是否可见，在屏幕上完全不可见或部分可见。光照运算，计算纹理色彩明亮程度，这取决于世界的灯光从什么角度如何投射到顶点上。过去，处理器处理这些计算，但现在，当代图形硬件就能为你做这些事情，这意谓着你的处理器可以去做其他的事情了。很明显这是件好事情™，由于不能指望市面上所有的3D显卡板上都有T&，所以无论如何你自己将必须写所有的这些例程(再一次从游戏开发者角度来说)。你将在本文各处的不同段落看到"好事情(tm)"这个词汇。我认为，这些特征为使游戏看起来更好作出了非常有用的贡献。毫不令人吃惊，你也将会看见它的对立面；你猜到了，那就是“坏事情我正在尝试争取这些词汇的版权，你要使用他们就得支付一笔小小的费用哟。曲面片（高次表面）除了三角形，曲面片的使用现在正变得更普遍。因为他们能用数学表达式来描述几何(通常涉及某种曲线的几何形体)置，所以曲面片(高次表面的另一个名称)非常好。这样，你实际上就能够动态地根据方程式来建立(和变形)多边形网格，并决定你实际想要从曲面片上看到的多边形数量。因此，举例来说，你可以描述一个管道，然后在世界中就可以有这种管道的许多样例。在一些房间中，你已经显示了10，000个多边形，你可以说，"因为我们已经显示了大量的多边形，而且任何更多的多边形将会使帧速率下降，所以这个管道应该只有100个多边形"。但在另外一个房间中，视野中只有5000个可见的多边形，你可以说，"因为我们还没有达到预算可以显示的多边形数量，所以，现在这个管道能有500个多边形"。非常美妙的东西--通过AGP传5/30送同一个对象的曲面方程确实要比传送其大量顶点节省成本。SOF2就使用了这个方法的一种变体来建立它的地表系统。事实上现在的ATI显卡具有TruForm，它能带一个以三角形为基础的模型，并将该模—接着再用十倍三角形数量把模型转换回基于大量三角形的模型(被称为retesselation)。然后模型送往管线做进一步的处理。实际上ATI仅仅在T&L引擎之前增加了一个阶段来处理这个过程。这里的缺点是，要控制哪些模型需要被平滑处理而哪些又不需要。你常常想要一些边缘比较尖锐，比如鼻子，但它却被不恰当的平滑过了。这仍然是一种很好的技术，而且我能预见它在将来会被更多的应用。这就是第一部份--我们将会在第二部分继续介绍光照和纹理，下面的章节会更加深入。第2部份:3D环境的光照和纹理世界的灯光在变换过程中，通常是在称为观察空间的坐标空间中，我们遇到了最重要的运算之一:光照计算。它是一种这样的事情，当它工作时，你不关注它，但当它不工作时，你就非常关注它了。有很多不同的光照方法，从简单的计算多边形对于灯光的朝向，并根据灯光到多边形的方向和距离加上灯光颜色的百分比值，一直到产生边缘平滑的灯光贴图叠加基本纹理。而且一些API实际上提供预先建造的光照方法。举例来说，OpenGL提供了每多边形，每顶点，和每像素的光照计算。在顶点光照中，你要决定一个顶点被多少个多边形共享，并计算出共享该顶点的所有多边形法向量的均值（称为法向量），并将该法向量赋顶点。一个给定多边形的每个顶点会有不同的法向量，所以你需要渐变或插值多边形顶点的光照颜色以便得到平滑的光照效果。你没有必要用这种光照方式查看每个单独的多边形。这种方式的优点是时常可以使用硬件转换与光照（T&L）来帮助快速完成。不足之处是它不能产生阴影。举例来说，即使灯光是在模型的右侧，左手臂应该在被身体投影的阴影中，而实际上模型的双臂却以同样的方式被照明了。这些简单的方法使用着色来达到它们的目标。当用平面光照绘制一个多边形时，你让(该方法中，多边形均对应一个光强度，表面上所有点都用相同的强度值显示，渲染绘制时得到一种平面效果，多边形的边缘不能精确的显示出来)。对于顶点着色(Gouraud着色)，你让渲染引擎给每个顶点赋予特定的颜色。在绘制多边形上各点投影所对应的像素时，根据它们与各顶点的距离，对这些顶点的颜色进行插值计算。(实际上QuakeIII模型使用的就是这种方法，效果好的令人惊奇)。还有就是PhongGouraud着色，通过纹理工作，但不对每个顶点颜色进行插值决定像素颜色值，它对每个顶点的法向量进行插值，会为每个顶点投影的像素做相同Gouraud着色，你需要知道哪些光投射在每个顶点上。对于Phong对每个像素也要知道这么多。一点也不令人惊讶，Phong着色可以得到更加平滑的效果，因为每个像素都需要进行光照计算，其绘制非常耗费时间。平面光照处理方法很快速，但比较粗糙。Phong着色比Gouraud着色计算更昂贵，但效果最好，可以达到镜面高光效果("高亮")。这些都需要你在游戏开发中折衷权衡。6/30多重纹理与凹凸映射单一纹理映射给整个3D真实感图形带来很大的不同，但使用多重纹理甚至可以达到但许多具有多流水线的3D加速卡，如ATI'sRadeon和nVidia'sGeForce2及更高级的显卡，多重纹理可以在一遍渲染（绘制）过程中完成。产生多重纹理效果时，你先用一个纹理绘制多边形，然后再用另外一个纹理透明地绘制在多边形上面。这让你可以使纹理看上去在移动，或脉动，甚至产生阴影效果(我们在照明一节中描述过)。绘制第一个纹理映射，然后在上面绘制带透明的全黑纹理，引起一种是所有的织法黑色的但是有一个透明分层堆积过它的顶端，这就是--即时阴影。该技术被称为照明映射(有时也称为暗映射)至新的Doom，一直是Id引擎里关卡照明的传统方法。Matrox第一个在流行的3D游戏中发起使用各种不同形式的凹凸贴图。就是生成纹理来表现灯光在表面的投射，表现表面的凹凸或表面的裂缝。凹凸贴图并不随着灯光一起移动--它被设计用来表现一个表面上的细小瑕疵，而不是大的凹凸。比如说，在飞行模拟器中，你可以使用凹凸贴图来产生像是随机的地表细节，而不是重复地使用相同的纹理，看上去一点趣味也没有。凹凸贴图产生相当明显的表面细节，尽管是很高明的戏法，但严格意义上讲，凹凸贴图并不随着你的观察角度而变化。比较新的ATI和nVidia显卡片能执行每像素运算，这种缺省观察角度的不足就真的不再是有力而快速的法则了。无论是哪一种方法，到目前为止，没有游戏开发者太多的使用；更多的游戏能够且应该使用凹凸贴图。高速缓存抖动=糟糕的事物纹理高速缓存的管理游戏引擎的速度至关重要。和任何高速缓存一样，缓存命中很好，而不命中将很糟糕。如果遇到纹理在图形显示卡内存被频繁地换入换出的情况，这就是纹理高速缓存抖动。发生这种情况时，通常API将会废弃每个纹理，结果是所有的纹理在下一帧将被重新加载，这非常耗时和浪费。对游戏玩家来说，当API重新加载纹理高速缓存时，会导致帧速率迟钝。在纹理高速缓存管理中，有各种不同的技术将纹理高速缓存抖动减到最少–这是确保任何3D游戏引擎速度的一个决定性因素。纹理管理是件好事情–这意味着只要求显卡使用纹理一次，而不是重复使用。这听起来有点自相矛盾，但效果是它意谓着对显卡说，"看，所有这些多边形全部使用这一个纹理，我们能够仅仅加载这个纹理一次而不是许多次吗?"这阻止API(或图形驱动软件)上传多次向显卡加载纹理。象OpenGL这样的API实际上通常处理纹理高速缓存管理，意谓着，根据一些规则，比如纹理存取的频率，API决定哪些纹理储存在显卡上，哪些纹理存储在主存。真正的问题来了：a)你时常无法知道API正在使用的准确规则。b)你时常要求在一帧中绘制更多的纹理，以致超出了显卡内存空间所能容纳的纹理。另外一种纹理高速缓存管理技术是我们早先讨论的纹理压缩。很象声音波形文件被压缩成MP3文件，尽管无法达到那样的压缩比率，但纹理可以被压缩。从声音波形文件到MP3的压缩可以达到11:1的压缩比率，而绝大多数硬件支持的纹理压缩运算法则只有4:1的压缩比率，尽管如此，这样能产生很大的差别。除此之外，在渲染（绘制）过程中，只有在需要时，硬件才动态地对纹理进行解压缩。这一点非常棒，我们仅仅擦除即将可能用到的表面。如上所述，另外一种技术确保渲染器要求显卡对每个纹理只绘制一次。确定你想要渲染（绘制）的使用相同纹理的所有多边形同时送到显卡，而不是一个模型在这里，另一个模型7/30AGP接口传送一次。QuakeIII在其阴影系统就是这么做的。处理多边形时，把它们加入到一个内部的阴影列表，一旦所有的多边形处理完毕，渲染器遍历纹理列表，就将纹理及所有使用这些纹理的多边形同时传送出去。上述过程在使用显卡的硬件T&L（如果支持的话）时，并不怎么有效。你面临的结局是，满屏幕都是使用相同纹理的大量的多边形小群组，所有多边形都使用不同的变换矩阵。这意谓着更多的时间花在建立显卡的硬件T&L引擎无论如何，因为他们有助于对整个模型使用统一的纹理，所以它对实际屏幕上的模型可以有效地工作。通常它没有这么严重，因为大体而言，世界的纹理不会有那么大，这样一来API的纹理缓存系统将会替你处理这些，并把纹理保留在显卡以备再次使用。在游戏机上，通常没有纹理高速缓存系统(除非你写一个)。在PS2上面，你最好是远离"一次纹理"Xbox上面，这是不重要的，因为它本身没有图形内存(它是UMA体系结构)，且所有的纹理无论如何始终保留在主存之中。事实上，在今天的现代PCFPS游戏中，试图通过AGP接口传送大量纹理是第二个最通常的瓶颈。最大的瓶颈是实际几何处理，它要使东西出现在它应该出现的地方。在如今的3DFPS游戏中，最耗费时间的工作，显然是那些计算模型中每个顶点正确的世界位置的数学运算。如果你不把场景的纹理保持在预算之内，仅居其次的就是通过AGP接口传送大量的纹理了。然而，你确实有能力影响这些。通过降低顶层的MIP级别(还记得系统在哪里不断地为你细分纹理吗?)，你就能够把系统正在尝试送到显卡的纹理大小减少一半。你的视觉质量会有所下降--尤其是在引人注目的电影片断中--但是你的帧速率上升了。这种方式对网络游戏尤其有帮助。实际上，SoldierofFortuneII和JediKnightII:Outcast这两款游戏在设计时针对的显卡还不是市场上的大众主流显卡。为了以最大大小观看他们的纹理，你的3D显卡至少需要有128MB的内存。这两种产品在思想上都是给未来设计的。上面就是第2部份。在下面章节中，我们将介绍许多主题，包括内存管理，雾效果，深度测试，抗锯齿，顶点着色，API等第3部分:模板阴影与深度测试用模板产生阴影效果，事情就变得复杂而昂贵了。这里不讨论太多细节（可以写成一篇单独的文章了），其思想是，从光源视角绘制模型视图，然后用这个把多边形纹理形状产生或投射到受影响的物体表面。实际上你是在视野中投射将会“落”在其他多边形上面的光体。最后你得到看似真实的光照，甚至带有视角在里面。因为要动态创建纹理，并对同一场景进行多遍绘制，所以这很昂贵。你能用众多不同方法产生阴影，情形时常是这样一来，渲染质量与产生效果所需要的渲染工作成比例。有所谓的硬阴影或软阴影之分，而后者较好，因为它们更加准确地模仿阴影通常在真实世界的行为。通常有一些被游戏开发者偏爱的“足够好”的方法。如要更多的了解阴影，请参考DaveSalvator的3D流水线一文。深度测试现在我们开始讨论深度测试，深度测试丢弃隐藏的像素，过度绘制开始起作用。过度绘制非常简单–在一帧中，你数次绘制一个像素位置。它以3D场景中Z（深度）方向上存在的元素数量为基础，也被称为深度复杂度。如果你常常太多的过度绘制，--举例来说,8/30符咒的眩目视觉特效，就象HereticII，能让你的帧速率变得很糟糕。当屏幕上的一些人们彼此施放符咒时，HereticII设计的一些最初效果造成的情形是，他们在一帧中对屏幕上每个相同的像素画了40次!不用说，这必须调整，尤其是软件渲染器，除了将游戏降低到象是滑雪表演外，它根本不能处理这样的负荷。深度测试是一种用来决定在相同的像素位置上哪些对象在其它对象前面的技术，这样我们就能够避免绘制那些隐藏的对象。看着场景并想想你所看不见的。换句话说，是什么在其他场景对象前面,或者隐藏了其他场景对象?是深度测试作出的这个决定。我将进一步解释深度如何帮助提高帧速率。想像一个很琐细的场景，大量的多边形(或像素)位于彼此的后面，在渲染器获得他们之间没有一个快速的方法丢弃他们。对非Alpha混合的多边形分类排序(在Z-方向上)，首先渲染离你最近的那些多边形，优先使用距离最近的像素填充屏幕。所以当你要渲染它们后面的像素（由Z像素很快被丢弃，从而避免了混合步骤并节省了时间。如果你从后到前绘制，所有隐藏的对象将被完全绘制，然后又被其他对象完全重写覆盖。场景越复杂，这种情况就越糟糕，所以深度测试是个好东西。抗锯齿让我们快速的看一下抗锯齿。当渲染单个多边形时，3D显卡仔细检查已经渲染的，并对新的多边形的边缘进行柔化，这样你就不会得到明显可见的锯齿形的像素边缘。两种技术方法之一通常被用来处理。第一种方法是单个多边形层次，需要你从视野后面到前面渲染多边形，这样每个多边形都能和它后面的进行适当的混合。如果不按序进行渲染，最后你会看见各种奇怪的效果。在第二种方法中，使用比实际显示更大的分辩率来渲染整幅帧画面，然后在你缩小图像时，尖锐的锯齿形边缘就混合消失了。这第二种方法的结果不错，但因为显卡需要渲染比实际结果帧更多的像素，所以需要大量的内存资源和很高的内存带宽。多数新的显卡能很好地处理这些，但仍然有多种抗锯齿模式可以供你选择，因此你可以在性能和质量之间作出折衷。对於当今流行的各种不同抗锯齿技术的更详细讨论请参见DaveSalvator的3D流水线一文。顶点与像素着色在结束讨论渲染技术之前，我们快速的说一下顶点和像素着色，最近它们正引起很多关注。顶点着色是一种直接使用显卡硬件特征的方式，不使用API。举例来说，如果显卡支持硬件T&L，你可以用DirectX或OpenGL编程，并希望你的顶点通过T&L单元(因为这完全由驱动程序处理，所以没有办法确信)，或者你直接利用显卡硬件使用顶点着色。它们允许你根据显卡自身特征进行特别编码，你自己特殊的编码使用T&L引擎，以及为了发挥你的最大优势，显卡必须提供的其他别的特征。事实上，现在nVidia和ATI在他们大量的显卡上都提供了这个特征。DirectX或者OpenGL那样，为顶点着色编写一次代码就可以在任何显卡上运行，这可是个坏消息。然而，因为你直接和显卡硬件交流，它为快速渲染顶点着色可能生成的效果提供最大的承诺。(如同创造很不错的特效--你能够使用顶点着色以API没有提供的方式影响事物)。事实上，顶点着色正在真的将3D图形显示卡带回到游戏机的编码方式，直接存取硬件，最大限度利用系统的必须知识，而不是依靠API来为你做一切。对一些程序员来说，会对这种编码方式感到吃惊，但这是进步代价。进一步阐述，顶点着色是一些在顶点被送到显卡渲染之前计算和运行顶点效果程序或者例程。你可以在主CPU上面用软件来做这些事情，或者使用显卡上的顶点着色。为动画模9/30型变换网格是顶点程序的主选。像素着色是那些你写的例程，当绘制纹理时，这些例程就逐个像素被执行。你有效地用这些新的例程推翻了显卡硬件正常情况做的混合模式运算。这允许你做一些很不错的像素效,ATI和nVidia能实际上就像素着色版本达成一致(DX9's新的高级阴影语言将会帮助促进这一目标),我一点不惊讶DirectX和OpenGL采用Glide的方式--有帮助开始,但最终不是把任何显卡发挥到极限的最好方法。我认为我会有兴趣观望将来。最后（In）最终，渲染器是游戏程序员最受评判的地方。在这个行业，视觉上的华丽非常重要，因此它为知道你正在做的买单。对于渲染器程序员，最坏的因素之一就是3D显卡工业界变化的速度。一天，你正在尝试使透明图像正确地工作；第二天nVidia正在做顶点着色编程的3D显卡写的代码现在已经过时了，需要全部重写。甚至JohnCarmack这样描述过，他知道四年以前为充分发挥那个时期显卡的性能所写的不错的代码，如今很平凡--因此他产生了为每个新的id项目完全重写渲染器的欲望。Epic的TimSweeney赞同--这里是去年他给我的评论:我们已经足足花费了9Unreal被设计为软件渲染和后来扩展为硬件渲染。下一代引擎被设计为GeForce及更好的图形显示卡，且多边形吞吐量是UnrealTournament的100倍。这需要全部替换渲染器。很幸运，该引擎模块化程度足够好，我们可以保持引擎的其余--不改动，尽管我们一直在以许多方式改进这些部分。搭配长篇文章的短篇报导（API--祝福和诅咒那么什么是API?它是应用程序编程接口,将不一致的后端用一致的前端呈现出来。举例来说，很大程度上每种3D显示卡的3D实现方式都有所差别。然而，他们全部都呈现一个X3D显示卡写的代码将会在Y3D显示卡上面有相同的结果。好吧，不管怎样理论上是那样。大约在三年以前这可能是相当真实的陈述，但自那以后，在nVidia公司的引领下，3D显卡行业的事情发生了变化。如今在PC领域，除非你正计划建造自己的软件光栅引擎，使用CPU来绘制你所有的精灵，多边形和粒子--而且人们仍然在这样做。跟UnrealAgeofEmpiresII:AgeofKings有一个优秀的软件渲染器–否则你将使用两种可能的图形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和DirectXMicrosoft拥有。10/30如果你想要DirectX为你的3D显示卡支持一个新的特征，那么你需要游说微软，希望采纳你的愿望，并等待新的DirectXOpenGL，由于显示卡制造商为3D显示卡提供驱动程序，你能够通过OpenGL扩展立即获得显示卡的新特征。这是好，但作为游戏开50%，但你不能要求别人有一块GeForce3来跑你的游戏。好吧，你可以这么做，但如果你想来年还在这个行业的话，这是个相当愚蠢的主意。这是对这个问题极大的简单化，对我所有描述的也有各种例外情况，但这里一般的思想DirectX，在任何既定时间你容易确切地知道你能从显示卡获得的特征，如果一个特征不能获得，DirectX将会用软件模拟它(也不总是一件好事情，因为这样有时侯非常的慢，但那是另外一回事)。对于OpenGL，你可以更加贴近显示卡的特征,但代价是不能确定将会获得的准确特征。第4部份:模型与动画，细节级别角色建模与动画你的角色模型在屏幕上看起来怎么样,怎样容易创建它们,纹理,以及动画对于现代游戏试图完成的`消除不可信`,包括较高的多边形数量模型,和让模型在屏幕上移动的更好方式。如今你需要一个骨骼模型系统，有骨架和网格细节层次，单个顶点骨架的评估，骨架动像动画混合，骨架反向运动学（IK还能够继续列下去。但是真的，在用专业行话说了所有这些以后，我们在这里真正谈论的是什么呢？让我们看看。让我们定义一个基于网格的系统和一个骨骼动画系统作为开始。在基于网格的系统，对于每一个动画帧，你要定义模型网格的每个点在世界中的位置。举例来说，你有一个包含200个多边形的手的模型，有300个顶点(注意，在顶点和多边形之间通常并不是3个对1个的关系，因为大量多边形时常共享顶点–使用条形和扇形，你能大幅减少顶点数量)。如果动画有10帧，那么你就需要在内存中有300个顶点位置的数据。总共有300x10=3000顶点，每个顶点由xyz和颜色/alpha信息组成。你能看见这个增长起来是多么的快。QuakeI，II和III都使用了这种系统，这种系统确实有动态变形网格的能力，比如使裙子摆动，或者让头发飘动。相比之下，在骨骼动画系统，网格是由骨架组成的骨骼(骨架是你运动的对象)。网格顶点和骨架本身相关，所以它们在模型中的位置都是相对于骨架，而不是网格代表每个顶点在世界中的位置。因此，如果你移动骨架，组成多边形的顶点的位置也相应改变。这意谓着你只必须使骨骼运动，典型情况大约有50个左右的骨架—很明显极大地节省了内存。骨骼动画附加的好处骨骼动画的另一个优点是能够根据影响顶点的一些骨架来分别“估价”每个顶点。例如，双臂的骨架运动，肩，脖子而且甚至躯干都能在肩中影响网格。当你移动躯干的时候，网格就活像一个角色一样移动。总的效果是3D角色能够实现的动画更加流畅和可信，且需要更少的内存。每个人都赢了。当然这里的缺点是，如果你想要使有机的东西运动且很好，比如说头发，或者披肩，为了让它看起来自然，你最后不得不在里面放置数量惊人的骨架，这会抬高一些处理时间。11/30基于骨骼的系统能带给你的一些其他事情是‘忽略’特定层次骨架的能力--说,"我不关心动画想要对这块骨架所做的事情，我想要让它指向世界中的一个特定点"。这很棒。你能让模型着眼于世界中的事件，或者使他们的脚在他们站着的地面保持水平。这一切非常微妙，但它可以帮助带给场景附加的真实感。在骨骼系统，你甚至可以指定"我需要把这个特别的动画用於模型的腿，而一个不同的携枪或射击动画在模型躯干上播放，且那家伙（角色）叫喊的不同动画效果在模型的头部播放"Ghoul2(在SoldierofFortuneII:DoubleHelixandJediKnightI:Outcast中使用了Raven的动画系统)拥有所有这些好东西，且特别被设计为允许程序员使用所有这些忽略能力。这对动画的节省像你一样难以相信。像你一样的动画上的这次救援不相信.Raven有一个角色行走的动画和一个站立开火的动画，并在它同时行走和开火形下把这两个动画合并，而不是需要一个动画表示角色行走并开火。MoreSkeletonsintheCloset先前描述的效果可以通过具有层次的骨骼系统来完成。这是什么意思呢？意思是每块骨架实际上的位置相对于它的父亲，而不是每个骨架直接位于空间中的地方。这意味着如果你移动父亲骨架，那么它所有的子孙骨架也跟着移动，在代码上不需要任何额外的努力。这是让你能够在任何骨架层次改变动画，而且通过骨骼其余部分向下传递的东西。创建一个没有层次的骨骼系统是可能的--但那时你不能忽略一个骨架并且预期它工作。你所看到的只是身体上的一个骨架开始了新动画，除非你实现了某种‘向下传递信息’的系统，否则在该骨架下面的其它骨架保持原来的动画。首先由一个层次系统开始，你就自动地获得这些效果。许多今天的动画系统中正开始出现一些比较新的特征，如动画混合，从一个正在播放的动画转变到另外一个动画需要经过一小段时间，而不是立即从一个动画突然转变到另外一个。举例来说，你有个角色在行走，然后他停了下来。你不是仅仅突然地转变动画，让他的腿和脚停在无效位置，而是一秒钟混合一半，这样脚似乎自然地移到了新的动画。不能够过高的评价这种效果--混合是一个微妙的事情,但如果正确的运用，它真的有些差别。反向运动学反向运动学(IK)是被许多人们丢弃的一个专业术语，对它的真实含义没有多少概念。IK是如今游戏里面一个相对比较新的系统。使用IK,模型的其余关节自动重新定位，因此模型被正确定向。而且有模型的关节新位置的其馀者他们自己，因此模型正确的被定向。比如，你将会说,"好，手,去拾起桌子上的那个杯子"并指出杯子在世界中的位置。手就会移动到那里，且它后面的身体会调节其自身以便双臂移动，身体适当弯曲，等等。也有和IK相反的事情，叫做前向运动学,本质上与IK工作的次序相反。想像一只手，手附着在手臂上，手臂附着在身体上。现在想像你重重地击中了身体。通常手臂像连迦般抽IK基本上它需要动画师设定每种工作的大量信息--架前面的骨架移动，那么这块骨架将移动多少百分比，等等。和它现在一样，尽管很好，它是一个很大的处理问题，不用它你可以有不同的动画组合IK解决办法需要一个层次骨骼系统而不是一个模型空间系统--否则它们都耗时太多以致无法恰当地计算每个骨架。12/30LOD几何系统最后，我们应当快速讨论一下与缩放模型几何复杂度相关的细节级别（LOD(与讨论MIP映射时使用的LOD相对照)PC游戏支持的处理器速度的巨大范围，以及你可能渲染的任何给定可视场景的动态性质(在屏幕上有一个角色还是12个？)，你通常需要一些系统来处理这样的情况，比如，当系统接近极限试图同时在屏幕上绘制出12个角色，每个角色有3，000个多边形,并维持现实的帧速率。LOD被设计来协助这样的情景中。最基本的情况，它是在任何给定时间动态地改变你在屏幕上绘制的角色的多边形数量的能力。面对现实吧，当一个角色走远，也许只有十个屏幕像素高度，你真的不需要3000个多边形来渲染这个角色--或许300个就够了，而且你很难分辨出差别。一些LOD系统将会需要你建立模型的多个版本，而且他们将会依靠模型离观察者的接近程度来改变屏幕上的LOD级别，以及多少个多边形正被同时显示。更加复杂的系统实际上将会动态地减少屏幕上的多边形数量，在任何给定时间，任何给定的角色，动态地--Messiah和Sacrifice包括了这种风格的技术，尽管在CPU方面并不便宜。你必须确信，与首先简单地渲染整个事物相比，你的LOD系统没有花较多的时间计算出要渲染那些多边形任一方式都将会工作，由于如今我们试图要在屏幕上绘制的多边形数量，这是件非常必要的事情。注意，DX9将会支持硬件执行的自适应几何缩放(tessellation)。归结起来是，得到一个运动流畅，其表现和移动在视觉上可信，屏幕上看起来逼真的模型。流畅的动画时常是通过手工建造动画和运动捕捉动画的组合得到。有时你仅仅手工建立了一个给定的动画--当你在为一个模型做一些你在现实生活中不能做到的事情的动画时，你倾向于这样做--举例来说，你确实不能向后弯腰，或像MortalKombat4中的LuiKang那样在行进的脚踏车上踢腿，通常运动捕捉这时候就出局了!通常运动捕捉动画--实际上视频捕捉活生生的演员贯穿于你想在屏幕上所看到的动画--实感的东西能使一款普通游戏看起来很棒，而且能掩饰许多事情。比如NFLBlitz，屏幕上的模型大约有200个多边形。它们在静止站立时看起来可怕的斑驳，一旦这些模型跑动起来它们就有快速流畅的动画，模型自身的许多丑陋消失了。眼睛容易看见的是'逼真的'动画而不是模型自身的结构。一个不错的模型设计师能够掩饰大多数模型缺陷。我希望这些带给你对模型和动画问题的洞察力。在第五部份中，我们将会更加深入3D世界的建造，讨论一些物理，运动和效果系统的东西。第5部分:游戏物理学既然我们已经在内存中得到了世界的结构，我们必须防止我们的角色从里面掉落出去，并处理地板，斜坡，墙壁，门，以及移动平台。加之，我们必须正确地处理地心引力，速度变化，惯性，和放置在世界里面的其它对象的碰撞。这被看作是游戏物理学。而且在我们进一步深入讨论之前，我想现在就在这里消除一个神话。任何时候你在世界中看见物理，或者任何人在一个复杂的游戏环境中宣称“真实的物理”，很好，它是BS。超过80%的建造一个有效率游戏物理系统的精力花在简化用来处理世界中对象的真实方程式上面。甚至那时，你时常忽略什么是‘真实的’，并创造一些‘有趣的’东西，毕竟，这是目标所在。例如，在QuakeII里面，你能够立即从0加速到35MPH，并快速停下来。没有摩擦力，而且斜坡不提供真实斜坡提供的相同类型的重力问题。身体没有它们应该的作用在所有关节上的地心引力--你看不见身体像真实生活中那样倒在桌子上面或者边缘--而且地心引力它本身甚至可能是可变的。面对现实吧，在真正的世界中，空间中的飞船不像二战飞行战斗13/30不像X-Wing中的LukeSkywalker那样啸叫。尽管那样做更加有趣！作为游戏开发者来说，无论我们做什么，我们需要能够检测墙壁，检测地板，在世界中–我们决定对它们进一步要做的取决于我们和我们的游戏需要。效果系统如今绝大多数的游戏引擎建造有某种效果产生器，这允许我们表现出有洞察力的游戏者所以这是我们需要特别关心的地方。如今我们有很棒的3D显示卡，我们能够传送大量的三角形给它们，而且他们仍然要求更多的三角形。并不总是那样。在HereticII，使用它的可爱的软件渲染模式，由于他们漂亮的符咒效果，Raven遇到了相当严重的过度绘制问题。回想当你在屏幕上绘制相同的像素超过一次时，过度绘制就发生了。当你有许多效果正在进行，按其性质你有许多三角形，多个三角形可能相互堆叠在彼此上面。结果是你有许多重复绘制的像素。加上Alpha，这意味着在重新绘制之前你必须读取旧像素并和新的像素混合，这会消耗更多的CPU时间。HereticII的一些效果能说明这点，我们在一帧里对整个屏幕重复绘制了四十遍。很惊讶，是吗？因此他们在效果系统里面实现了一个系统采样在过去30帧的帧速率，如果速度开始减慢，它就自动地缩减任何给定效果绘制的三角形数量。这样使主要工作完成了，帧速率保持住了，但一些效果看上去很丑陋。无论如何，因为如今绝大多数效果倾向使用大量很小的粒子模拟火和烟等等，结果你在效果代码里面每帧要处理许多的三角形。你必须把它们从一帧移动到下一帧，决定它们是否完成了，甚至还要在它们身上运用一些物理学以便让它们在地板上面适当的反弹。这在PC上面都是相当昂贵的，因此甚至现在你必须对你所能够做的有一些实际限制。举例来说，用一个像素粒子产生火的效果可能会很好，但当你这么做的时候就别期望在屏幕上做更多别的事情。粒子被定义为拥有它们自己的世界位置和速度的非常小的可绘制的物体。它们不同于有方向的精灵，大的粒子使用这些精灵--比如喷出的一团团烟雾。它们面向照相机自动而典型地旋转，缩放，改变它们的透明级别，因此它们能够随着时间淡出。我们容易看到大量的粒子，但我们却限制精灵的数量—尽管两者之间的真正不同如今正在模糊。将来，特别是在DX9和更加高级的图形硬件表面以后，我们可能看到更多的人们使用过程shader来产生跟粒子系统相似或者更好的效果，创造非常棒的动画效果。当谈论效果系统时，你可能听说过‘图原’这个词。一个图原是你的效果系统将处理的效果的最低级别的物理表现。更进一步解释，一个三角形是一个图原。那是绝大多数引擎最终在底层绘制的--大量的三角形。当你沿着系统向上时，你对图原的定义随着变化。比如说，顶层的游戏程序员不想考虑处理个别的三角形。他仅仅想说,"这个效果在这里发生"并让系统以一种黑盒方式处理它。因此对于他来说，一个效果图原就是‘让我们在世界的这点持续这么长时间用这样的引力产生一束粒子’。在效果系统内部，它可能认为一个效果图原是它那时正在产生的每个单独的效果，像一组遵循同样的物理学规则的三角形—然后它传送有一点困惑，但你知道总的思想了。以上就是第五部分，下一个部分是关于声音系统，和各种不同的音频APIs，3D音频效果，处理闭塞和障碍，各种不同材料对声音的影响，音频混合等等。14/30第6部分:声音系统，音频APIs声音系统由于人们玩的游戏在种类和技术上的进步，声音和音乐近几年来在游戏中正逐渐变得重要起来（声音是一个实际游戏的可玩特点，比如在Thief现在四声道环绕系统在游戏玩家的宝库中是负担得起的和平常的事。给定空间的声音，噪音的障碍和闭塞，和动态的音乐，如今许多游戏使用这些提高玩家情绪上的反应，更多的关注投入到这个领域就不足为奇了。现在在PC竞技场中，游戏玩家实际上只有一种声音卡可以选择--PC声卡制造商创新公司（CreativeLabs）的SoundBlasterLive！从旧的时间个人计算机声音卡片制造业者有创造力的中心.多年来创新公司已经为DirectX提供了他们的EAX是发起新的OpenAL（开放音频库OpenAudioLibrary）的创立者。就如同OpenGL是一个图形API一样，OpenAL，像它起来听一样，是一个声音系统的API。OpenAL被设计为支持大多数通常声卡的许多特征，而且在一个特定的硬件特征不可得时提供一个软件替代。为了更好的定义OpenAL，我向创新公司的GarinHiebert询问了其定义:"这里借用我们的"OpenAL规格和叁考"的一个定义:OpenAL是对音频硬件的一个软件接口,给程序员提供一个产生高质量多通道输出的能力。OpenAL是在模拟的三维环境里产生声音的一种重要方法。它想要跨平台并容易使用，在风格和规范上与OpenGL相似。任何已经熟悉OpenGL的程序员将发现OpenAL非常熟悉。OpenALAPI能容易地被扩展适应插件技术.创新公司已经把EAX支持加入到这套API了，程序员可以用来给他们的声音环境增加复杂的反响，比赛和障碍效果。如同JediKnightII:Outcast一样，连同Eagle世界/声音特征编辑器,SoldierofFortuneII以这个新系统为特征。什么是Eagle？在介绍这个以前，让我们讨论一些其他的系统，并定义一些声音术语。另外的一个系统是Miles声音系统。Miles是一家公司，它为你的代码生产插件，在充分利用每块声卡时处理所有必须的到特定声音卡的说话（比如SoundBlasterLive！系列，或者老的A3DAPI前端，捆绑了一些额外的特征在里面。在其他事物当中Miles让你存取一些事物像MP3解压缩。它是很好的解决方案，但像任何事一样，它而且他们有段时间了，因此他们的确精通自己的业务。声音术语让我们开始障碍和闭塞。它们听起来一样，但不是这样。闭塞基本上意谓着一个声音在播放时听者在他们之间有一些闭合的障碍物。NOLF2的一个屏幕镜头上你听到房子里面坏蛋的声音。你能听到他们，但是他们的声音相当低沉而沙哑。障碍是相似的，但是你和声音之间的障碍物并不是闭合的。一个好的例子就是在你和声源之间有一根柱子。由于房间中的回声你仍然听得到这个声音，但是它和声音直接传递到你的耳朵里是不同的。当然这确实依赖于知道在你的耳朵和声源之间后面我们将会谈到跟踪--足可以说它时常是比较慢的帧速率的原因。QuakeIII里面的A3D代码做了这些事情，关闭这些选项通常能够提高帧速率。Tribe2是这种弊病的另外一个受3D声音选项则你的帧速率立即好转，这在你考虑Tribes世界有多大和你能看见多远时有意义。15/30接着是声音物质的特征。大部分声卡可以让你能够用可定义的过滤器作用于声音从而修正播放的声音。例如，在水下，或者在一个布料遮盖的房间中，或者在一个长的走廊中，或者在歌剧院，听到的声音有着很大的不同。能够根据你所处的环境改变你听到声音的方式是相当不错的。我们回到Eagle„这是一个编辑器，允许多数第一人称射击游戏地图设计者将他们的地图导入到这个工具，然后构造简化的几何形体来为实际游戏引擎中的EAX代码产生一个声音地图。其思想是你不需要一个真实的图形地图的复杂几何形体来模拟声音环境。你也能够给产生的简化地图分配声音物质，这样声音环境就能够动态地改变。我亲眼目睹了这在SoldierofFortune和UnrealTournament上的示范，确实相当引人注目。我这在财富和Unreal巡回赛和它的军人上真的对示范是证人相当醒目.当你跳入水中时，听到所有的声音改变，这是一个非常令人沉浸的经历。好，让我们继续吧。对于游戏机，由于静态的硬件，你的各种可能性会更受限制—尽管在PlayStation2和Xbox上，硬件相当不错。我说的限制，仅仅是指扩展，而不是它所能够做的。我一点也不会感到惊讶看到这些游戏机上的游戏很快支持杜比数字5.1（DolbyDigital5.1）输出。Xbox，由于它的MCP音频处理器，能够将任何游戏音频编码为5.1，并且游戏不需要特别编码就能利用这个特征。杜比（Dolby）把ProLogicII带到了PS2上，并与Factor5合作为GameCube游戏实现了ProLogicII。在Xbox之上，Halo,Madden2002和ProjectGothamRacing等游戏都有5.1杜比数字音频内容。DTS最近也为PS2游戏开发者发布了SDK，为这个平台上的游戏带来了降低了比特率的DTS音频版本。位置的声音一个复杂的世界现在有一些很少有处理的声音空间化问题。我说的是把声音放在一个真实的3D世界中。有四个扬声器在你周围是一个很棒的开始，但这仍然只是在二维方向。在你的上方和下方没有扬声器，你没有真正获得3D声音。有一些声音调制过滤器试图解决这个问题，但实际上没有真实东西的代替物。当然真实地大多数游戏多半只是在二维方向上，因此这仍然不是太大的问题。实际上任何声音系统最重要的特征之一是把声音混合在一起。根据你所处的位置，空间中声音的位置，每个声音的音量大小，一旦你决定了实际上你能够听到的声音，然后你必须混合这些声音。通常声音卡自己处理这些，这首先是声音卡存在的主要原因。然而，外面有一些引擎决定首先用软件做一次‘预混合’。直到你着眼于一点点历史以前，这并没有真正地带来多大的意义。当声音卡最初问世的时候，有许多不同的混合方法。一些声卡可以混合8单位1632如果你总想听到16种可能的声音，但你不知道声音卡是否能够处理，那么你回到了尝试和试验的道路上—就是你自己用软件混合。这实际上是QuakeIII:"QuakeIII是为A3D和SoundBlasterLive！声卡世界发布的，这比以前更加标准化，为什么还这样做？"这是个好问题。实际上QuakeIII的声音系统几乎每行代码都和QuakeII中的声音系统一样。而且QuakeI，甚至Doom也是这样。你想一想，向上直到A3D声卡和SBLive!声卡，许多年来声音系统的需求没Doom一直到QuakeIII没有发生太大变化。而且在游戏行业中，如果不是迫不得已，别理会它。通常你会仅仅使用DirectSound为你做声音混合，因为它会可以使用的声音硬件，或者转而依靠软件，很多地方就像DirectX为3D显示卡所做的一样。在90%靠软件混合对你的帧速率没有真正发生太多不同。当DirectSound在一些狂热的编码者眼中16/30甚至还不是一丝光线时，Doom引擎就已经产生了。它从来没有得到更新过，因为它从来就没有真的需要更新。SoundBlasterLive:一,一个足球体育馆等。而且你真的应该使用由硬件提供的混合器，毕竟，那是它存在的目的。这种方法的一个不足之处是程序本身时常无法获得混合结果，因为混合是在声卡内部完成而不是在主存。如果由于某种原因你需要看到产生的音量，你是运气不好。MusicTracksin（游戏中的音轨）我们没有过多的谈到游戏中的音乐生成。传统的有两种方法，一种是简单的音乐.wav文件(或同等物)。它被预先制作做好，准备运行，和最小忙乱。然而，这些在内存和回放时间方面很昂贵。第二种方式用预设的样本编码MIDI音轨。这时常比较节省内存，但缺点是必须同时把一些声音混合在一起，因而会把声音通道用光。动态音乐就是根据在游戏中目睹的行动改变你的音乐的能力，比如探险用慢节奏的音乐，战斗用快节奏的音乐。预先制作的音乐的一个困难之处是要合拍，因此你可以从一段音乐渐弱到另一段音乐，这对于MIDI音轨比较容易。尽管时常你足够快速地淡出，或者一段音乐在播放另一段音乐之前已经消失了，你能侥幸不被察觉。在我们离开这个主题之前，顺便说一下，值得一提的是存在一些公司专门为你的游戏创作特定意义的音乐。FatMan()就是一家这样的公司。音乐可能比其他别的东西更加容易外包，这是他们存在的方式。最后，游戏现在的事情自然是MP3格式，允许巨大的11：1的声音样本压缩，然而在送到声音卡之前只花费CPURaveSoftwareStarTrekVoyager:EliteForce中，我们设法用MP3在一张CD上面完全支持三种语言，仍然为较多的图形留有空间。主要地，我们MP3只用于非玩家角色（NPC）的语音，由于游戏的全部音频效果MP3流和动态解压缩超出了硬件的处理能力，虽然在将来这是肯定可能的。比较新的格式，如来自Dolby的AAC和来自微软的WMA，以将近两倍MP3的压缩率提供了相等或者更高的音频质量（实际上一半的比特率），可能应用到将来的游戏中。以上是这一章节的内容，下面将是网络和连线游戏环境的开发。第7部份:网络和连线游戏环境我记得一些年前坐在GDC（游戏开发者大会）听负责开发X-WingVsTIEFighter的家伙们题为“淹没在Internet”的演讲，全是关于让网络游戏实时地在Internet上工作的东西。他们选择那个题目是多么的正确啊。当它开始处理数据包的丢失，乱序，潜伏（一个数据包发送到它的目的地所花的时间）等等时，它确实淹没了。然而它是可能的。对于InternetQuakeIII，UnrealTournament，CounterStrike一直到EverQuest和UltimaOnline。如今大多数真正有长久生命力的游戏都至少有一些连线成分。最纯粹的单人游戏容易玩如果你想要有任何长久生命力，那么多人连线游戏就是形势的核心所在，并且那意味着和Internet打交道，为编码者打开了那个潘多拉的盒子。那么跟Internet打交道包括些什么呢？首先是要理解Internet点与客户机/服务器体系结构的快速讨论。点对点就是你在两台机器上运行游戏，并简单地在它们之间共享输入。每个单独的游戏假定它是正确的，并仅仅在它一帧接一帧的刷新中合17/30并来自另外一台机器的输入。客户机/服务器是一台机器有效地运行游戏，别的机器仅仅是一个终端，接受来自玩家的输入，并渲染服务器让它渲染的任何东西。客户机/服务器的优点是每台机器都将会展现相同的游戏，因为所有的处理都在一个地方完成，没有跨越多台机器，你可以不用考虑每台机器相互之间的同步问题。不足之处是，服务器本身需要有一些重要的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是一条直接和IPTCP是在你和IP之间的一个接口。它像是在你和你的邮件之间有一个UDP你会自己为你的信打字，把它们放进一个信封等等。使用TCP你会仅仅向你的管理员口授信稿，管理员会做全部的工作并追踪确认信件送到了。Internet完好无损地送到了目的方，TCP期待从目的方为它发送的每个数据包发回一个应答包（网络用语是ACKACK，它就停止发送任何新的数据包，重新发送丢失的数据包，并且将继续这样做直到收到目的方的回应。当你访问一个网页时，我们都已经看到了这种情形，在半途中下载停止了一会然后又重新开始了。可能是一个数据包在什么ISPTCP要求重新发送它。这一切的问题是，在认识到出了差错的发送者和实际上正在送达的数据包之间出现了延迟。有时这能花上数秒钟，如果你仅仅只是下载一个文件或一个网页，这不是什么大碍，但如果这是一个游戏数据包而且每秒至少有十次，那么你真的是遇到麻烦了，尤其是因为它停止了其他一切事情。实际上就是这个问题所以几乎没有游戏选择使用TCP作为它们主要的Internet协议，除非它不是一个实时动作游戏。大多数游戏使用UDP--他们不能保证有序或可靠送达，但它确实很快—或者结果是至少通常比TCP/IP更快。现在我们了解这些了，接下来呢？包大小，智能数据传输，和反作弊别的必须被处理的事情是数据包的大小。如果你在一个游戏里面64个人都在跑来跑去相互攻击，从一台机器发送到另外一台机器的数据包能变得相当大，达到了一些调制解调器没有带宽处理这些数据的程度。这正在变得特别和那些有着很大的地表系统的游戏有关。这里增加的问题是，因为你有这个很好的地表系统，你能够看得很远，因此能够看见许多其他游戏玩家，使得你为了精确渲染所需要的来自服务器的数据数量以很快的速率增长。我们能做什么呢？好吧，首先必要的是只发送绝对必须的东西给任何给定的客户端，因此他仅仅得到从他18/30的角度观察游戏所需要的东西。发送在他视野以外的人们的数据没有一点意义—他将看不见这些。同时，你最好确保只发送那些每帧之间实际上发生改变的数据。如果一个家伙仍然在播放相同的动画，重新发送数据没有意义。当然，如果数据包丢失时这确实带来一些问题，但这就是为什么好的网络程序员被支付很多金钱，来处理类似这样的东西。还有一些其他的事情也要处理。最近已经有大量的令人苦恼的连线作弊正在发生。这是某些人修改游戏以给他们不正当利益的地方。尽管严格意义上这不是网络的一部分，但它确实发生了。有时人们会创作一些模块，允许他们立即瞄准进入视野的任何人，或者简单地允许他们看穿墙壁，或者让其他游戏玩家看不见他们自己。大部份时间这些事情可以在网络层内部或者在服务器上被处理。任何有100%命中率的人被简单地踢出游戏，因为在人力所及的范围内那是不可能的。游戏开发者必须尽一切可能制止作弊行为，但很不幸，人做的东西可以被人突破。所有你能做的就是让作弊变得困难，当确实发生时去尝试发现它。8部分中，我们将会看看游戏脚本系统的趣味世界，根据游戏过程中出现的事件来渲染或使能预先定义的场景和行为，协助故事叙述.第8部份:脚本系统脚本系统我们从第七部分的游戏网络问题来到了脚本系统，因为其呈现的故事叙述机会，最近已经形成一种很大的游戏元素。在一个需要以受控制的方式解释的情景，预先编制的电影脚本是解决问题的方法。在电影中，这通常用来处理或者由主角向一个伙伴解释情形，或者敌人对英雄解释。当然，有其它的方法来做这件事情--–但通常是使用实时情景的人们和事件来完成。当然，游戏是不同的，游戏开发者在他们平常的FPS中不应该做太多的倒叙，因为通常会需要载入新的环境或者关卡，以及新的纹理和/或模型。所有这些额外的处理和渲染能影响到主要的游戏序列的性能。你可以重用已经存储在内存里面的场景元素来倒叙，但那样会看上去明显比较粗陋。RavenSoft的StarTrekVoyager:EliteForce广泛利用了脚本序列产生游戏中的事件和使用游戏引擎本身的剪辑场景。在游戏中设计脚本情节的一个有趣趋势是使用当前极大改进了的3D游戏引擎自己产生剪辑场景。现在这可能像是相当地明显，但是数年以前，当3D图形卡还比较简单的时候，剪辑场景通常使用高端3D3D动画然后被记录为一个数字视频文件，以流式文件存储在CD-ROM3D画面，这是相当令人不愉快的失望的事情。但像Half-Life和StarTrekVoyager:EliteForce这样的游戏很好地利用了它们自己的引擎产生所有的剪辑场景，结果是剪辑场景和游戏之间的过渡更加平滑。把脚本和人工智能区分开来可能是个很好的主意。脚本是你完全控制着一个给定场景，建立玩家几乎总是没有控制的事件，游戏者‘沿着轨道’移动到一个给定地点，或者建立一个游戏玩家需要解决的情形。一个好的例子可能是巨石掉在走廊上，需要游戏玩家找到一个新的逃脱方法。如今有一些不同类型的脚本系统可供程序员或者美术师使用，而且它用非常有条理和逻辑的思想恰当地做这些。第一种是简单的基于文本的，单线索的风格，就像我们程序员习惯Cifthis，thendothat”的东西。大部分脚本倾向在范围内是相当线性的—意味着它通常由许多在次19/30序上彼此相接的命令组成。在世界中移动角色A指向B移动他指向C。相当简单的事情。然后有复杂的东西--允许多重线索，和实际上允许可变情形。可变情形是当脚本开始时你实际上不能确知谁会出现在附近，但是你必须按这样的方式编写脚本以便任何人出现在附近它都将会工作。举例来说--一个正常的简单脚本会有三个家伙，全部被预先定义，全部有一组他们将会讨论的情形。一个可变的脚本将会有三个人,你不能保证是某一个特定的人，并必须按相同的方式工作。或者在一个极端的情形中，也许只有二个，或者甚至一个家伙将会在那里，使得三方交谈有一点困难。Raven在StarTrekVoyager:EliteForce中面临的一个很大的问题是