游戏引擎全剖析(二)

2007/12/12 10:42 P.M.
第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的压缩率提供了相等或者更高的音频质量（实际上一半的比特率），可能应用到将来的游戏中。
以上是这一章节的内容，下面将是网络和连线游戏环境的开发