游戏引擎全剖析(5-8)
2008-01-10 09:20
302 查看
第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部分中，我们将会看看游戏脚本系统的趣味世界，根据游戏过程中出现的事件来渲染或使能预先定义的场景和行为，协助故事叙述。
世界建造
常常在建立一个含有任何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部分中，我们将会看看游戏脚本系统的趣味世界，根据游戏过程中出现的事件来渲染或使能预先定义的场景和行为，协助故事叙述。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 