游戏引擎剖析
第3部份: 内存使用，特效和API<br/><br/><br/>关于内存使用的思考<br/> 让我们想一想，在今天实际上是如何使用3D 显卡内存的以及在将来又会如何使用。 如今绝大多数3D显卡处理32位像素颜色，8位红色， 8位蓝色，8 位绿色，和 8 位透明度。这些组合的红，蓝和绿256个色度，可以组成 16。7 百万种颜色-- 那是你我可以在一个监视器上看见的所有颜色。 <br/><br/> 那么，游戏设计大师John Carmack 为什么要求 * 位颜色分辨率呢? 如果我们看不出区别，又有什么意义呢? 意义是: 比如说， 有十几个灯光照射模型上的点，颜色颜色各不相同。 我们取模型的最初颜色，然后计算一个灯光的照射，模型颜色值将改变。 然后我们计算另外的一个灯光， 模型颜色值进一步改变。 这里的问题是，因为颜色值只有8位，在计算了4个灯光之后，8位的颜色值将不足以给我们最后的颜色较好的分辨率和表现。分辨率的不足是由量化误差导致的，本质原因是由于位数不足引起的舍入误差。 <br/><br/> 你能很快地用尽位数，而且同样地，所有的颜色被清掉。每颜色16 或 32 位，你有一个更高分辨率，因此你能够反复着色以适当地表现最后的颜色。这样的颜色深度很快就能消耗大量的存储空间。我们也应提到整个显卡内存与纹理内存。这里所要说的是，每个3D 显卡实际只有有限的内存，而这些内存要存储前端和后端缓冲区，Z 缓冲区，还有所有的令人惊奇的纹理。最初的 Voodoo1 显卡只有2MB显存，后来 Riva TNT提高到16MB显存。然后 GeForce 和 ATI Rage有32MB显存， 现在一些 GeForce 2 到 4的显卡和 Radeons 带有 *MB 到128MB 的显存。 这为什么重要? 好吧，让我们看一些数字…<br/><br/> 比如你想让你的游戏看起来最好，所以你想要让它以32位屏幕， 1280x1024分辨率和32位 Z- 缓冲跑起来。 好，屏幕上每个像素4个字节，外加每个像素4字节的Z-缓冲，因为都是每像素32位。我们有1280x1024 个像素 – 也就是 1，310，720个像素。基于前端缓冲区和Z-缓冲区的字节数，这个数字乘以8，是 10，485，760字节。包括一个后端缓冲区，这样是 1280x1024x12， 也就是 15，728，*0 字节， 或 15MB。 在一个 16MB 显存的显卡上，就只给我们剩下1MB 来存储所有的纹理。 现在如果最初的纹理是真32 位或 4字节宽，那么我们每幀能在显卡上存储 1MB/4字节每像素 = 262，144个像素。这大约是4 个 256x256 的纹理页面。 <br/><br/> 很清楚，上述例子表明，旧的16MB 显卡没有现代游戏表现其绚丽画面所需要的足够内存。很明显，在它绘制画面的时候，我们每幀都必须重新把纹理装载到显卡。实际上，设计AGP总线的目的就是完成这个任务，不过， AGP 还是要比 3D 掀卡的幀缓冲区慢，所以你会受到性能上的一些损失。很明显，如果纹理由32位降低到16位，你就能够通过AGP以较低的分辨率传送两倍数量的纹理。如果你的游戏以每个像素比较低的色彩分辨率跑， 那么就可以有更多的显示内存用来保存常用的纹理 (称为高速缓存纹理) 。 但实际上你永远不可能预知使用者将如何设置他们的系统。如果他们有一个在高分辨率和颜色深度跑的显卡，那么他们将会更可能那样设定他们的显卡。<br/><br/><br/>雾<br/> 我们现在开始讲雾,它是某种视觉上的效果。如今绝大多数的引擎都能处理雾， 因为雾非常方便地让远处的世界淡出视野，所以当模型和场景地理越过观察体后平面进入视觉范围内时，你就不会看见它们突然从远处跳出来了。 也有一种称为体雾的技术。这种雾不是随物体离照相机的距离而定,它实际上是一个你能看见的真实对象，并且可以穿越它，从另外一侧出去 -- 当你在穿越对象的时候，视觉上雾的可见程度随着变化。想象一下穿过云团 -- 这是体雾的一个完美例子。体雾的一些好的实现例子是Quake III一些关卡中的红色雾，或新的Rogue Squadron II 之 Lucas Arts的 GameCube 版本。其中有一些是我曾经见过的最好的云--大约与你能看见的一样真实。<br/><br/> 在我们讨论雾化的时候,可能是简短介绍一下 Alpha 测试和纹理Alpha混合的好时机。当渲染器往屏幕上画一个特定像素时，假定它已经通过 Z- 缓冲测试 (在下面定义)，我们可能最后做一些Alpha测试。我们可能发现为了显示像素后面的某些东西，像素需要透明绘制。这意味着我们必须取得像素的已有值，和我们新的像素值进行混和，并把混合结果的像素值放回原处。这称为读-修改-写操作,远比正常的像素写操作费时。 <br/><br/> 你可以用不同类型的混合，这些不同的效果被称为混合模式。直接Alpha混合只是把背景像素的一些百分比值加到新像素的相反百分比值上面。还有加法混合，将旧像素的一些百分比,和特定数量(而不是百分比)的新像素相加。 这样效果会更加鲜明。 (Kyle's Lightsaber在 Jedi Knight II 中的效果)。<br/> <br/> 每当厂商提供新的显卡时，我们可以得到硬件支持的更新更复杂的混合模式，从而制作出更多更眩目的效果。GF3+4和最近的Radeon显卡提供的像素操作，已经到了极限。<br/><br/><br/>模板阴影与深度测试<br/> 用模板产生阴影效果，事情就变得复杂而昂贵了。这里不讨论太多细节（可以写成一篇单独的文章了），其思想是，从光源视角绘制模型视图，然后用这个把多边形纹理形状产生或投射到受影响的物体表面。 <br/><br/> 实际上你是在视野中投射将会“落”在其他多边形上面的光体。最后你得到看似真实的光照，甚至带有视角在里面。因为要动态创建纹理，并对同一场景进行多遍绘制，所以这很昂贵。 <br/><br/> 你能用众多不同方法产生阴影，情形时常是这样一来，渲染质量与产生效果所需要的渲染工作成比例。有所谓的硬阴影或软阴影之分，而后者较好，因为它们更加准确地模仿阴影通常在真实世界的行为。 通常有一些被游戏开发者偏爱的“足够好”的方法。如要更多的了解阴影，请参考 Dave Salvator的 3D 流水线一文。<br/><br/><br/>深度测试<br/> 现在我们开始讨论深度测试， 深度测试丢弃隐藏的像素，过度绘制开始起作用。过度绘制非常简单 – 在一幀中，你数次绘制一个像素位置。它以3D场景中Z（深度）方向上存在的元素数量为基础，也被称为深度复杂度。如果你常常太多的过度绘制， -- 举例来说, 符咒的眩目视觉特效，就象Heretic II，能让你的幀速率变得很糟糕。当屏幕上的一些人们彼此施放符咒时，Heretic II设计的一些最初效果造成的情形是，他们在一幀中对屏幕上每个相同的像素画了40次! 不用说，这必须调整，尤其是软件渲染器，除了将游戏降低到象是滑雪表演外，它根本不能处理这样的负荷。深度测试是一种用来决定在相同的像素位置上哪些对象在其它对象前面的技术，这样我们就能够避免绘制那些隐藏的对象。 <br/><br/> 看着场景并想想你所看不见的。 换句话说，是什么在其他场景对象前面,或者隐藏了其他场景对象? 是深度测试作出的这个决定。 <br/><br/> 我将进一步解释深度深度如何帮助提高幀速率。想像一个很琐细的场景，大量的多边形 (或像素)位于彼此的后面，在渲染器获得他们之间没有一个快速的方法丢弃他们。对非Alpha混合的多边形分类排序( 在Z- 方向上)，首先渲染离你最近的那些多边形，优先使用距离最近的像素填充屏幕。所以当你要渲染它们后面的像素（由Z或者深度测试决定）时，这些像素很快被丢弃，从而避免了混合步骤并节省了时间。如果你从后到前绘制，所有隐藏的对象将被完全绘制，然后又被其他对象完全重写覆盖。场景越复杂，这种情况就越糟糕，所以深度测试是个好东西。<br/><br/><br/>抗锯齿<br/> 让我们快速的看一下抗锯齿。当渲染单个多边形时，3D 显卡仔细检查已经渲染的，并对新的多边形的边缘进行柔化，这样你就不会得到明显可见的锯齿形的像素边缘。两种技术方法之一通常被用来处理。 第一种方法是单个多边形层次，需要你从视野后面到前面渲染多边形，这样每个多边形都能和它后面的进行适当的混合。如果不按序进行渲染，最后你会看见各种奇怪的效果。在第二种方法中，使用比实际显示更大的分辩率来渲染整幅幀画面，然后在你缩小图像时，尖锐的锯齿形边缘就混合消失了。这第二种方法的结果不错，但因为显卡需要渲染比实际结果幀更多的像素，所以需要大量的内存资源和很高的内存带宽。<br/><br/> 多数新的显卡能很好地处理这些，但仍然有多种抗锯齿模式可以供你选择，因此你可以在性能和质量之间作出折衷。对於当今流行的各种不同抗锯齿技术的更详细讨论请参见Dave Salvator 的3D 流水线一文。<br/><br/><br/>顶点与像素着色<br/> 在结束讨论渲染技术之前，我们快速的说一下顶点和像素着色，最近它们正引起很多关注。顶点着色是一种直接使用显卡硬件特征的方式，不使用API。举例来说，如果显卡支持硬件 T & L ，你可以用DirectX或OpenGL编程，并希望你的顶点通过 T & L 单元 (因为这完全由驱动程序处理，所以没有办法确信)，或者你直接利用显卡硬件使用顶点着色。它们允许你根据显卡自身特征进行特别编码，你自己特殊的编码使用T & L 引擎，以及为了发挥你的最大优势，显卡必须提供的其他别的特征。 事实上，现在nVidia 和ATI 在他们大量的显卡上都提供了这个特征。 <br/><br/> 不幸的是，显卡之间表示顶点着色的方法并不一致。你不能象使用DirectX或者OpenGL 那样，为顶点着色编写一次代码就可以在任何显卡上运行，这可是个坏消息。然而，因为你直接和显卡硬件交流，它为快速渲染顶点着色可能生成的效果提供最大的承诺。( 如同创造很不错的特效 -- 你能够使用顶点着色以API没有提供的方式影响事物)。事实上，顶点着色正在真的将3D 图形显示卡带回到游戏机的编码方式，直接存取硬件，最大限度利用系统的必须知识，而不是依靠API来为你做一切。对一些程序员来说，会对这种编码方式感到吃惊，但这是进步代价。<br/><br/> 进一步阐述，顶点着色是一些在顶点被送到显卡渲染之前计算和运行顶点效果程序或者例程。你可以在主CPU上面用软件来做这些事情，或者使用显卡上的顶点着色。 为动画模型变换网格是顶点程序的主选。<br/><br/> 像素着色是那些你写的例程，当绘制纹理时，这些例程就逐个像素被执行。你有效地用这些新的例程推翻了显卡硬件正常情况做的混合模式运算。这允许你做一些很不错的像素效果， 比如，使远处的纹理模糊，添加炮火烟雾, 产生水中的反射效果等。一旦 ATI 和 nVidia 能实际上就像素着色版本达成一致( DX9's 新的高级阴影语言将会帮助促进这一目标), 我一点不惊讶DirectX 和OpenGL采用Glide的方式-- 有帮助开始, 但最终不是把任何显卡发挥到极限的最好方法。我认为我会有兴趣观望将来。<br/> 最后（In Closing...）<br/> 最终，渲染器是游戏程序员最受评判的地方。在这个行业，视觉上的华丽非常重要，因此它为知道你正在做的买单。对于渲染器程序员，最坏的因素之一就是3D 显卡工业界变化的速度。一天，你正在尝试使透明图像正确地工作；第二天 nVidia 正在做顶点着色编程的展示。而且发展非常快，大致上，四年以前为那个时代的 3D 显卡写的代码现在已经过时了，需要全部重写。 甚至John Carmack 这样描述过，他知道四年以前为充分发挥那个时期显卡的性能所写的不错的代码，如今很平凡 -- 因此他产生了为每个新的id项目完全重写渲染器的欲望。Epic 的Tim Sweeney赞同 -- 这里是去年他给我的评论: <br/><br/> 我们已经足足花费了9个月时间来更换所有的渲染代码。最初的 Unreal 被设计为软件渲染和后来扩展为硬件渲染。下一代引擎被设计为 GeForce 及更好的图形显示卡，且多边形吞吐量是Unreal Tournament的100倍。 <br/><br/> 这需要全部替换渲染器。很幸运，该引擎模块化程度足够好，我们可以保持引擎的其余部分—编辑器，物理学，人工智能，网络--不改动，尽管我们一直在以许多方式改进这些部分。<br/><br/> 搭配长篇文章的短篇报导（Sidebar）：API -- 祝福和诅咒<br/> 那么什么是API? 它是应用程序编程接口,将不一致的后端用一致的前端呈现出来。举例来说，很大程度上每种3D显示卡的3D实现方式都有所差别。然而，他们全部都呈现一个一致的前端给最终使用者或者程序员，所以他们知道他们为X 3D显示卡写的代码将会在Y 3D显示卡上面有相同的结果。好吧，不管怎样理论上是那样。 大约在三年以前这可能是相当真实的陈述，但自那以后，在nVidia 公司的引领下，3D显卡行业的事情发生了变化。 <br/><br/> 如今在PC领域，除非你正计划建造自己的软件光栅引擎，使用CPU来绘制你所有的精灵，多边形和粒子 -- 而且人们仍然在这样做。跟Unreal一样，Age of Empires II: Age of Kings有一个优秀的软件渲染器 – 否则你将使用两种可能的图形API，OpenGL或者 DirectX 之一。OpenGL是一种真正的跨平台API (使用这种API写的软件可以在Linux，Windows和MacOS上运行。)， 而且有多年的历史了，为人所熟知，但也开始慢慢地显示出它的古老。 大约在四年以前，定义OpenGL驱动特征集一直是所有显示卡厂商工作的方向。<br/><br/> 然而，一旦在目标达成以后，没有预先制定特征工作方向的路线图，这时候，所有的显卡开发商开始在特征集上分道扬镳，使用OpenGL扩展。<br/> <br/> 3dfx 创造了T- 缓冲。 nVidia 努力寻求硬件变换和光照计算。Matrox努力获取凹凸贴图。等等。 我以前说过的一句话，"过去几年以来，3D显示卡领域的事情发生了变化。"委婉地说明了这一切。 <br/><br/> 无论如何，另一个可以选择的API是 DirectX。这受Microsoft公司控制，且在PC 和 Xbox 上被完美地支持。由于明显的原因，DirectX 没有Apple或者 Linux 版本。因为Microsoft控制着 DirectX，大体上它容易更好地集成在Windows里面。 <br/><br/> OpenGL和DirectX之间的基本差别是前者由‘社区’拥有，而后者由Microsoft拥有。如果你想要 DirectX 为你的 3D 显示卡支持一个新的特征，那么你需要游说微软，希望采纳你的愿望，并等待新的 DirectX发行版本。对于OpenGL，由于显示卡制造商为3D显示卡提供驱动程序，你能够通过OpenGL扩展立即获得显示卡的新特征。这是好，但作为游戏开发者，当你为游戏编码的时候，你不能指望它们很普遍。它们可能让你的游戏速度提升50%，但你不能要求别人有一块GeForce 3 来跑你的游戏。好吧，你可以这么做，但如果你想来年还在这个行业的话，这是个相当愚蠢的主意。<br/><br/> 这是对这个问题极大的简单化，对我所有描述的也有各种例外情况，但这里一般的思想是很确实的。对于DirectX ，在任何既定时间你容易确切地知道你能从显示卡获得的特征，如果一个特征不能获得，DirectX 将会用软件模拟它(也不总是一件好事情，因为这样有时侯非常的慢，但那是另外一回事)。对于OpenGL，你可以更加贴近显示卡的特征,但代价是不能确定将会获得的准确特征。 <br/> 第4部份: 模型与动画，细节级别<br/><br/><br/>角色建模与动画<br/> 你的角色模型在屏幕上看起来怎么样,怎样容易创建它们,纹理,以及动画对于现代游戏试图完成的`消除不可信`因素来说至关重要。角色模型系统逐渐变得复杂起来, 包括较高的多边形数量模型, 和让模型在屏幕上移动的更好方式。<br/><br/> 如今你需要一个骨骼模型系统，有骨架和网格细节层次，单个顶点骨架的评估，骨架动画忽略，以及比赛中停留的角度忽略。而这些甚至还没有开始涉及一些你能做的很好的事情，像动画混合，骨架反向运动学（IK），和单个骨架限制，以及相片真实感的纹理。这个清单还能够继续列下去。但是真的，在用专业行话说了所有这些以后，我们在这里真正谈论的是什么呢？让我们看看。 <br/><br/> 让我们定义一个基于网格的系统和一个骨骼动画系统作为开始。在基于网格的系统，对于每一个动画幀，你要定义模型网格的每个点在世界中的位置。举例来说，你有一个包含200 个多边形的手的模型，有 300 个顶点(注意，在顶点和多边形之间通常并不是3个对1个的关系，因为大量多边形时常共享顶点 – 使用条形和扇形，你能大幅减少顶点数量)。如果动画有 10 幀，那么你就需要在内存中有300个顶点位置的数据。 总共有300 x 10 = 3000 顶点，每个顶点由x，y，z和颜色/alpha信息组成。你能看见这个增长起来是多么的快。Quake I，II和 III 都使用了这种系统，这种系统确实有动态变形网格的能力，比如使裙子摆动，或者让头发飘动。<br/><br/> 相比之下，在骨骼动画系统，网格是由骨架组成的骨骼( 骨架是你运动的对象)。 网格顶点和骨架本身相关，所以它们在模型中的位置都是相对于骨架，而不是网格代表每个顶点在世界中的位置。因此，如果你移动骨架，组成多边形的顶点的位置也相应改变。这意谓着你只必须使骨骼运动，典型情况大约有 50 个左右的骨架—很明显极大地节省了内存。<br/><br/><br/>骨骼动画附加的好处<br/> 骨骼动画的另一个优点是能够根据影响顶点的一些骨架来分别“估价” 每个顶点。例如，双臂的骨架运动，肩，脖子而且甚至躯干都能在肩中影响网格。当你移动躯干的时候，网格就活像一个角色一样移动。总的效果是3D角色能够实现的动画更加流畅和可信，且需要更少的内存。每个人都赢了。 <br/><br/> 当然这里的缺点是，如果你想要使有机的东西运动且很好，比如说头发，或者披肩，为了让它看起来自然，你最后不得不在里面放置数量惊人的骨架，这会抬高一些处理时间。 <br/><br/> 基于骨骼的系统能带给你的一些其他事情是‘忽略’特定层次骨架的能力 -- 说,"我不关心动画想要对这块骨架所做的事情，我想要让它指向世界中的一个特定点"。这很棒。你能让模型着眼于世界中的事件，或者使他们的脚在他们站着的地面保持水平。这一切非常微妙，但它可以帮助带给场景附加的真实感。<br/><br/> 在骨骼系统，你甚至可以指定"我需要把这个特别的动画用於模型的腿，而一个不同的携枪或射击动画在模型躯干上播放，且那家伙（角色）叫喊的不同动画效果在模型的头部播放"。非常妙。Ghoul2 ( 在Soldier of Fortune II: Double Helix and Jedi Knight I: Outcast中使用了Raven的动画系统 ) 拥有所有这些好东西，且特别被设计为允许程序员使用所有这些忽略能力。这对动画的节省像你一样难以相信。像你一样的动画上的这次救援不相信. Raven有一个角色行走的动画和一个站立开火的动画，并在它同时行走和开火形下把这两个动画合并，而不是需要一个动画表示角色行走并开火。<br/><br/><br/>More Skeletons in the Closet<br/> 先前描述的效果可以通过具有层次的骨骼系统来完成。这是什么意思呢？意思是每块骨架实际上的位置相对于它的父亲，而不是每个骨架直接位于空间中的地方。这意谓着如果你移动父亲骨架，那么它所有的子孙骨架也跟着移动，在代码上不需要任何额外的努力。这是让你能够在任何骨架层次改变动画，而且通过骨骼其余部分向下传递的东西。 <br/><br/> 创建一个没有层次的骨骼系统是可能的 -- 但那时你不能忽略一个骨架并且预期它工作。你所看到的只是身体上的一个骨架开始了新动画，除非你实现了某种‘向下传递信息’的系统，否则在该骨架下面的其它骨架保持原来的动画。首先由一个层次系统开始，你就自动地获得这些效果。 <br/><br/> 许多今天的动画系统中正开始出现一些比较新的特征，如动画混合，从一个正在播放的动画转变到另外一个动画需要经过一小段时间，而不是立即从一个动画突然转变到另外一个。举例来说，你有个角色在行走，然后他停了下来。你不是仅仅突然地转变动画，让他的腿和脚停在无效位置，而是一秒钟混合一半，这样脚似乎自然地移到了新的动画。不能够过高的评价这种效果 -- 混合是一个微妙的事情,但如果正确的运用，它真的有些差别。<br/><br/><br/>反向运动学<br/> 反向运动学 (IK) 是被许多人们丢弃的一个专业术语，对它的真实含义没有多少概念。IK 是如今游戏里面一个相对比较新的系统。使用 IK ，程序员能够移动一只手，或一条腿, 模型的其余关节自动重新定位，因此模型被正确定向。而且有模型的关节新位置的其馀者他们自己，因此模型正确的被定向。比如，你将会说,"好，手 , 去拾起桌子上的那个杯子"并指出杯子在世界中的位置。手就会移动到那里，且它后面的身体会调节其自身以便双臂移动，身体适当弯曲，等等。<br/><br/> 也有和IK相反的事情，叫做前向运动学,本质上与 IK 工作的次序相反。想像一只手，手附着在手臂上，手臂附着在身体上。现在想像你重重地击中了身体。通常手臂像连迦般抽动，且手臂末梢的手随之振动。 IK 能够移动身体，并让其余的四肢自己以真实的方式移动。基本上它需要动画师设定每种工作的大量信息 -- 像关节所能通过的运动范围，如果一块骨架前面的骨架移动，那么这块骨架将移动多少百分比，等等。<br/><br/> 和它现在一样，尽管很好，它是一个很大的处理问题，不用它你可以有不同的动画组合而脱身。值得注意的是，真正的 IK 解决办法需要一个层次骨骼系统而不是一个模型空间系统 -- 否则它们都耗时太多以致无法恰当地计算每个骨架。<br/><br/><br/>LOD几何系统<br/> 最后，我们应当快速讨论一下与缩放模型几何复杂度相关的细节级别（LOD）系统(与讨论MIP映射时使用的LOD相对照)。假定如今绝大多数PC游戏支持的处理器速度的巨大范围，以及你可能渲染的任何给定可视场景的动态性质(在屏幕上有一个角色还是12个？)， 你通常需要一些系统来处理这样的情况，比如，当系统接近极限试图同时在屏幕上绘制出12个角色，每个角色有3，000个多边形,并维持现实的幀速率。 LOD 被设计来协助这样的情景中。最基本的情况，它是在任何给定时间动态地改变你在屏幕上绘制的角色的多边形数量的能力。面对现实吧，当一个角色走远，也许只有十个屏幕像素高度，你真的不需要3000个多边形来渲染这个角色 -- 或许300个就够了，而且你很难分辨出差别。 <br/><br/> 一些 LOD 系统将会需要你建立模型的多个版本，而且他们将会依靠模型离观察者的接近程度来改变屏幕上的LOD级别， 以及多少个多边形正被同时显示。更加复杂的系统实际上将会动态地减少屏幕上的多边形数量，在任何给定时间，任何给定的角色，动态地 -- Messiah和Sacrifice包括了这种风格的技术，尽管在CPU方面并不便宜。你必须确信，与首先简单地渲染整个事物相比，你的 LOD 系统没有花较多的时间计算出要渲染那些多边形（或不渲染）。 任一方式都将会工作，由于如今我们试图要在屏幕上绘制的多边形数量，这是件非常必要的事情。注意， DX9 将会支持硬件执行的自适应几何缩放(tessellation)。<br/><br/> 归结起来是，得到一个运动流畅，其表现和移动在视觉上可信，屏幕上看起来逼真的模型。流畅的动画时常是通过手工建造动画和运动捕捉动画的组合得到。有时你仅仅手工建立了一个给定的动画 -- 当你在为一个模型做一些你在现实生活中不能做到的事情的动画时， 你倾向于这样做 -- 举例来说，你确实不能向后弯腰，或像Mortal Kombat 4中的Lui Kang那样在行进的脚踏车上踢腿，通常运动捕捉这时候就出局了! 通常运动捕捉动画 -- 实际上视频捕捉活生生的演员贯穿于你想在屏幕上所看到的动画 -- 是得到逼真的东西的方式。真实感的东西能使一款普通游戏看起来很棒，而且能掩饰许多事情。比如 NFL Blitz，屏幕上的模型大约有 200 个多边形。它们在静止站立时看起来可怕的斑驳，一旦这些模型跑动起来它们就有快速流畅的动画，模型自身的许多丑陋消失了。眼睛容易看见的是 '逼真的' 动画而不是模型自身的结构。 一个不错的模型设计师能够掩饰大多数模型缺陷。<br/><br/> 我希望这些带给你对模型和动画问题的洞察力。在第五部份中，我们将会更加深入3D世界的建造，讨论一些物理，运动和效果系统的东西。 <br/> 第5部分: 物理，运动，效果<br/><br/><br/>世界建造<br/> 常常在建立一个含有任何3D成分的游戏时，你最终要试图建立一个将会在里面产生游戏动作的3D环境。 不知怎么的游戏开发者提供了一个建立这种环境的方，它容易修改，有效率，有较低的多边形数量，对于游戏既容易渲染又容易运用物理学。很简单，对吗？当做这个的时候我用左手在做什么？当做这的时候 , 我对我的左手做什么? 是的。不错。 <br/><br/> 虽然那里有许多3D结构程序，从CAD/CAM程序到3D Studio Max，建造游戏世界是不同于建造内部或外部世界的模型的尴尬。你有三角形数量问题 -- 任何给定的渲染器一次只能渲染这么多的多边形，这对于天才的关卡设计师来说永远都不够。不知这些，你也只能每个关卡存储预定数量的多边形，所以即使你的渲染器能够在视野中处理250，000个多边形，即使你只能在合理数量的空间中存储500，000个多边形，那么取决于你怎么处理它，最后你的关卡价值像两个房间那么小。不好。 <br/><br/> 任何方法，开发者需要提出一个创作工具 -- 最好足够灵活，允许游戏引擎需要的各种事物 – 比如，在世界中放置对象，在进入游戏以前对关卡的适当预览，以及准确的光照预览。在他们花三个小时预先处理关卡来产生一个 '引擎可消化的' 格式之前 , 这些能力允许游戏开发者看到关卡将在游戏中看起来怎么样。 开发者需要关于关卡，多边形数量，网格数量等等的相应数据。 他们需要一个合宜而友好的方式能够让世界有纹理背景图，容易存取多边形数量缩减工具，如此等等。这个清单可以继续列下去。 <br/><br/> 在先前已经存在的工具中找到这个功能是可能的。许多开发者使用Max或者Maya建造他们的关卡， 但即使3D Max需要对它的功能有一些任务特定的扩展来有效率地完成关卡建造工作。甚至可能使用关卡建造工具，像QERadient（见下图），而且把它的输出重新处理成你的引擎能够解释的格式。<br/><br/><br/>不能看见它? 别烦扰…<br/> 回想一下我们在第一部分讨论的BSP (二叉空间分割) 树，你也可能听说过潜在可视集合（PVS）这个术语正被四处谈论。两者都有相同的目标，不去探究涉及到的繁杂的数学，它是一种把世界分解为你能从世界任何给定位置看见的墙壁的最小子集的方式。在实现时，它们仅仅返回你能看见的那些，而不是那些隐藏在可能被遮挡的墙壁后面的。你能想象出这给软件渲染器带来的好处，渲染的每个像素(可能是这样的情形)极为重要。它们也按从后到前的顺序返回那些墙壁，在渲染时这是很方便的，因为你能够在渲染次序中确定一个对象的实际位置。 <br/><br/> 大体而言，BSP 树最近正不受欢迎，由于它们的一些古怪，而且因为我们从当今3D显示卡获得的像素吞吐量，再加上Z缓冲像素测试，BSP 常常成了一个多余的过程。它们在计算出你在世界的确切位置和正在你周围的几何物体方面是便利的，但常常有比BSP树更好而且更直观的方式来存储这些信息。 <br/><br/> 潜在可视集像它听上去一样非常好。它是这么一个方法，在任何给定时间，给定你在世界的位置，它决定世界的哪些表面，哪些对象实际上可以看得见。这时常用来在渲染之前剔除对象，也剔除它们来减少AI和动画处理。毕竟，如果你实际上不能看见它们,为什么还要费脑筋处理呢。多半这真的是不重要的，如果一个非玩家角色（NPC）正在播放动画，或者甚至在运行它的AI思考。<br/><br/><br/>游戏物理学<br/> 既然我们已经在内存中得到了世界的结构，我们必须防止我们的角色从里面掉落出去，并处理地板，斜坡，墙壁，门，以及移动平台。加之，我们必须正确地处理地心引力，速度变化，惯性，和放置在世界里面的其它对象的碰撞。这被看作是游戏物理学。而且在我们进一步深入讨论之前，我想现在就在这里消除一个神话。任何时候你在世界中看见物理，或者任何人在一个复杂的游戏环境中宣称“真实的物理”，很好，它是BS。超过80%的建造一个有效率游戏物理系统的精力花在简化用来处理世界中对象的真实方程式上面。甚至那时，你时常忽略什么是‘真实的’，并创造一些‘有趣的’东西，毕竟，这是目标所在。<br/><br/> 经常地游戏者将会忽视真实世界的牛顿物理学，并扮演他们自己的，更有趣的真实版本。例如，在QuakeII里面，你能够立即从0加速到35MPH，并快速停下来。没有摩擦力，而且斜坡不提供真实斜坡提供的相同类型的重力问题。身体没有它们应该的作用在所有关节上的地心引力 -- 你看不见身体像真实生活中那样倒在桌子上面或者边缘 -- 而且地心引力它本身甚至可能是可变的。 面对现实吧，在真正的世界中，空间中的飞船不像二战飞行战斗员在它们的表面操作那样实行。在空中，全部是力和反作用力，力在重量点周围作用，等等。不像 X-Wing中的Luke Skywalker那样啸叫。尽管那样做更加有趣！ <br/><br/> 作为游戏开发者来说，无论我们做什么，我们需要能够检测墙壁，检测地板，在世界中处理和其他对象的碰撞。这些是现代游戏引擎的必备 – 我们决定对它们进一步要做的取决于我们和我们的游戏需要。<br/><br/><br/>效果系统<br/> 如今绝大多数的游戏引擎建造有某种效果产生器，这允许我们表现出有洞察力的游戏者期盼的所有可爱的吸引眼球的东西。然而，效果系统幕后所进行的东西能够急剧影响幀速率，所以这是我们需要特别关心的地方。如今我们有很棒的3D显示卡，我们能够传送大量的三角形给它们，而且他们仍然要求更多的三角形。并不总是那样。 在Heretic II，使用它的可爱的软件渲染模式，由于他们漂亮的符咒效果，Raven遇到了相当严重的过度绘制问题。回想当你在屏幕上绘制相同的像素超过一次时，过度绘制就发生了。当你有许多效果正在进行，按其性质你有许多三角形，多个三角形可能相互堆叠在彼此上面。结果是你有许多重复绘制的像素。加上Alpha，这意味着在重新绘制之前你必须读取旧像素并和新的像素混合，这会消耗更多的CPU时间。 <br/><br/> Heretic II的一些效果能说明这点，我们在一幀里对整个屏幕重复绘制了四十遍。很惊讶，是吗？因此他们在效果系统里面实现了一个系统采样在过去30幀的幀速率，如果速度开始减慢，它就自动地缩减任何给定效果绘制的三角形数量。这样使主要工作完成了，幀速率保持住了，但一些效果看上去很丑陋。 <br/><br/> 无论如何，因为如今绝大多数效果倾向使用大量很小的粒子模拟火和烟等等，结果你在效果代码里面每幀要处理许多的三角形。你必须把它们从一幀移动到下一幀，决定它们是否完成了，甚至还要在它们身上运用一些物理学以便让它们在地板上面适当的反弹。这在PC上面都是相当昂贵的，因此甚至现在你必须对你所能够做的有一些实际限制。举例来说，用一个像素粒子产生火的效果可能会很好，但当你这么做的时候就别期望在屏幕上做更多别的事情。 <br/><br/> 粒子被定义为拥有它们自己的世界位置和速度的非常小的可绘制的物体。它们不同于有方向的精灵，大的粒子使用这些精灵 -- 比如喷出的一团团烟雾。它们面向照相机自动而典型地旋转，缩放，改变它们的透明级别，因此它们能够随着时间淡出。我们容易看到大量的粒子，但我们却限制精灵的数量—尽管两者之间的真正不同如今正在模糊。将来，特别是在 DX9 和更加高级的图形硬件表面以后，我们可能看到更多的人们使用过程shader来产生跟粒子系统相似或者更好的效果，创造非常棒的动画效果。 <br/><br/> 当谈论效果系统时，你可能听说过‘图原’这个词。一个图原是你的效果系统将处理的效果的最低级别的物理表现。更进一步解释，一个三角形是一个图原。那是绝大多数引擎最终在底层绘制的 -- 大量的三角形。当你沿着系统向上时，你对图原的定义随着变化。比如说，顶层的游戏程序员不想考虑处理个别的三角形。他仅仅想说,"这个效果在这里发生" 并让系统以一种黑盒方式处理它。因此对于他来说，一个效果图原就是‘让我们在世界的这点持续这么长时间用这样的引力产生一束粒子’。在效果系统内部，它可能认为一个效果图原是它那时正在产生的每个单独的效果，像一组遵循同样的物理学规则的三角形—然后它传送所有这些单独的三角形到渲染器进行渲染，因此在渲染器层次，图原就是一个单独的三角形。有一点困惑，但你知道总的思想了。 <br/><br/> 以上就是第五部分，下一个部分是关于声音系统，和各种不同的音频APIs，3D音频效果，处理闭塞和障碍，各种不同材料对声音的影响，音频混合等等。 <br/> 第6部分: 声音系统，音频APIs<br/><br/><br/>声音系统<br/> 由于人们玩的游戏在种类和技术上的进步，声音和音乐近几年来在游戏中正逐渐变得重要起来（声音是一个实际游戏的可玩特点，比如在Thief和其它同类游戏中的听觉提示）。现在四声道环绕系统在游戏玩家的宝库中是负担得起的和平常的事。给定空间的声音，噪音的障碍和闭塞，和动态的音乐，如今许多游戏使用这些提高玩家情绪上的反应，更多的关注投入到这个领域就不足为奇了。<br/><br/> 现在在PC竞技场中，游戏玩家实际上只有一种声音卡可以选择 -- PC声卡制造商创新公司（Creative Labs）的Sound Blaster Live！ 从旧的时间个人计算机声音卡片制造业者有创造力的中心. 多年来创新公司已经为DirectX提供了他们的EAX声音扩展，并且他们是发起新的OpenAL（开放音频库Open Audio Library）的创立者。就如同OpenGL是一个图形API一样，OpenAL，像它起来听一样，是一个声音系统的API。OpenAL 被设计为支持大多数通常声卡的许多特征，而且在一个特定的硬件特征不可得时提供一个软件替代。<br/><br/> 为了更好的定义 OpenAL，我向创新公司的Garin Hiebert询问了其定义: <br/><br/> "这里借用我们的 " OpenAL 规格和叁考" 的一个定义: <br/><br/> OpenAL 是对音频硬件的一个软件接口,给程序员提供一个产生高质量多通道输出的能力。OpenAL 是在模拟的三维环境里产生声音的一种重要方法。它想要跨平台并容易使用，在风格和规范上与OpenGL相似。任何已经熟悉OpenGL的程序员将发现OpenAL非常熟悉。 <br/><br/> OpenAL API能容易地被扩展适应插件技术.创新公司已经把EAX支持加入到这套API了，程序员可以用来给他们的声音环境增加复杂的反响，比赛和障碍效果。<br/><br/> 如同Jedi Knight II: Outcast 一样，连同Eagle 世界/声音特征编辑器,Soldier of Fortune II 以这个新系统为特征。什么是Eagle？ 在介绍这个以前，让我们讨论一些其他的系统，并定义一些声音术语。 <br/><br/><br/> 另外的一个系统是Miles声音系统。Miles是一家公司，它为你的代码生产插件，在充分利用每块声卡时处理所有必须的到特定声音卡的说话（比如Sound Blaster Live！系列，或者老的A3D声卡）。它非常像一个API前端，捆绑了一些额外的特征在里面。 在其他事物当中Miles让你存取一些事物像MP3解压缩。 它是很好的解决方案，但像任何事一样，它花费金钱并是你的代码和硬件之间的额外一层。虽然对於快速的声音系统制造，它非常有用，而且他们有段时间了，因此他们的确精通自己的业务。<br/><br/><br/>声音术语<br/> 让我们开始障碍和闭塞。它们听起来一样，但不是这样。闭塞基本上意谓着一个声音在播放时听者在他们之间有一些闭合的障碍物。 <br/><br/> 比如说，在NOLF2的一个屏幕镜头上你听到房子里面坏蛋的声音。你能听到他们，但是他们的声音相当低沉而沙哑。障碍是相似的，但是你和声音之间的障碍物并不是闭合的。一个好的例子就是在你和声源之间有一根柱子。由于房间中的回声你仍然听得到这个声音，但是它和声音直接传递到你的耳朵里是不同的。当然这确实依赖于知道在你的耳朵和声源之间的直线上是什么。而且根据房间的大小，声源到你的距离等等，需要的处理能变得相当耗时。后面我们将会谈到跟踪--足可以说它时常是比较慢的幀速率的原因。Quake III 里面的A3D 代码做了这些事情，关闭这些选项通常能够提高幀速率。Tribe 2 是这种弊病的另外一个受害者。关闭3D声音选项则你的幀速率立即好转，这在你考虑Tribes世界有多大和你能看见多远时有意义。 <br/><br/> 接着是声音物质的特征。大部分声卡可以让你能够用可定义的过滤器作用于声音从而修正播放的声音。例如，在水下，或者在一个布料遮盖的房间中，或者在一个长的走廊中，或者在歌剧院，听到的声音有着很大的不同。能够根据你所处的环境改变你听到声音的方式是相当不错的。 <br/><br/> 我们回到Eagle… 这是一个编辑器，允许多数第一人称射击游戏地图设计者将他们的地图导入到这个工具，然后构造简化的几何形体来为实际游戏引擎中的EAX代码产生一个声音地图。其思想是你不需要一个真实的图形地图的复杂几何形体来模拟声音环境。你也能够给产生的简化地图分配声音物质，这样声音环境就能够动态地改变。我亲眼目睹了这在Soldier of Fortune和Unreal Tournament上的示范，确实相当引人注目。 我这在财富和 Unreal 巡回赛和它的军人上真的对示范是证人相当醒目. 当你跳入水中时，听到所有的声音改变，这是一个非常令人沉浸的经历。 <br/><br/> 好，让我们继续吧。 <br/><br/> 对于游戏机，由于静态的硬件，你的各种可能性会更受限制 — 尽管在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音频版本。<br/><br/><br/>位置的声音--一个复杂的世界<br/> 现在有一些很少有处理的声音空间化问题。我说的是把声音放在一个真实的3D世界中。有四个扬声器在你周围是一个很棒的开始，但这仍然只是在二维方向。在你的上方和下方没有扬声器，你没有真正获得3D声音。有一些声音调制过滤器试图解决这个问题，但实际上没有真实东西的代替物。当然真实地大多数游戏多半只是在二维方向上，因此这仍然不是太大的问题。 <br/><br/> 实际上任何声音系统最重要的特征之一是把声音混合在一起。根据你所处的位置，空间中声音的位置，每个声音的音量大小，一旦你决定了实际上你能够听到的声音，然后你必须混合这些声音。通常声音卡自己处理这些，这首先是声音卡存在的主要原因。然而，外面有一些引擎决定首先用软件做一次‘预混合’。直到你着眼于一点点历史以前，这并没有真正地带来多大的意义。<br/><br/> 当声音卡最初问世的时候，有许多不同的混合方法。一些声卡可以混合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没有发生太大变化。而且在游戏行业中，如果不是迫不得已，别理会它。<br/><br/> 通常你会仅仅使用DirectSound为你做声音混合，因为它会可以使用的声音硬件，或者转而依靠软件，很多地方就像DirectX为3D显示卡所做的一样。在 90% 的声音情形中，依靠软件混合对你的幀速率没有真正发生太多不同。当DirectSound在一些狂热的编码者眼中甚至还不是一丝光线时，Doom引擎就已经产生了。它从来没有得到更新过，因为它从来就没有真的需要更新。 <br/><br/> 当然，你可以使用 SoundBlaster Live！声卡的一些聪明特征，例如房间的回声特性: 一块石窟，或一个礼堂，一个巨穴, 一个足球体育馆等。而且你真的应该使用由硬件提供的混合器，毕竟，那是它存在的目的。这种方法的一个不足之处是程序本身时常无法获得混合结果，因为混合是在声卡内部完成而不是在主存。如果由于某种原因你需要看到产生的音量，你是运气不好。<br/><br/><br/>Music Tracks in Games（游戏中的音轨）<br/> 我们没有过多的谈到游戏中的音乐生成。传统的有两种方法，一种是简单的音乐 .wav 文件(或同等物)。它被预先制作做好，准备运行，和最小忙乱。然而，这些在内存和回放时间方面很昂贵。第二种方式用预设的样本编码MIDI音轨。这时常比较节省内存，但缺点是必须同时把一些声音混合在一起，因而会把声音通道用光。 <br/><br/> 动态音乐就是根据在游戏中目睹的行动改变你的音乐的能力，比如探险用慢节奏的音乐，战斗用快节奏的音乐。预先制作的音乐的一个困难之处是要合拍，因此你可以从一段音乐渐弱到另一段音乐，这对于MIDI音轨比较容易。尽管时常你足够快速地淡出，或者一段音乐在播放另一段音乐之前已经消失了，你能侥幸不被察觉。<br/><br/> 在我们离开这个主题之前，顺便说一下，值得一提的是存在一些公司专门为你的游戏创作特定意义的音乐。FatMan(www.fatman.com) 就是一家这样的公司。音乐可能比其他别的东西更加容易外包，这是他们存在的方式。 <br/><br/> 最后，游戏现在的事情自然是MP3格式，允许巨大的11 ：1的声音样本压缩，然而在送到声音卡之前只花费CPU很少的时间解压缩。当我在Rave Software工作时，在Star Trek Voyager: Elite Force 中，我们设法用MP3在一张CD上面完全支持三种语言，仍然为较多的图形留有空间。主要地，我们 MP3 只用于非玩家角色（NPC）的语音，由于游戏的全部音频效果MP3流和动态解压缩超出了硬件的处理能力，虽然在将来这是肯定可能的。比较新的格式，如来自 Dolby 的 AAC 和来自微软的WMA，以将近两倍MP3的压缩率提供了相等或者更高的音频质量（实际上一半的比特率），可能应用到将来的游戏中。 <br/><br/> 以上是这一章节的内容，下面将是网络和连线游戏环境的开发。 <br/> 第7部份: 网络和连线游戏环境<br/><br/><br/>网络游戏<br/> 我记得一些年前坐在GDC（游戏开发者大会）听负责开发X-Wing Vs TIE Fighter的家伙们题为“淹没在Internet” 的演讲，全是关于让网络游戏实时地在Internet上工作的东西。他们选择那个题目是多么的正确啊。当它开始处理数据包的丢失，乱序，潜伏（一个数据包发送到它的目的地所花的时间）等等时，它确实淹没了。然而它是可能的。对于Internet需要一些聪明和经验，但它是肯定可能的。看看今天大量的连线游戏，从Quake III，Unreal Tournament，Counter Strike一直到EverQuest和Ultima Online。 <br/><br/> 如今大多数真正有长久生命力的游戏都至少有一些连线成分。最纯粹的单人游戏容易玩一次，也许两次，或者甚至三次如果它是非常好的游戏，但一旦游戏结束，就被束之高阁了。如果你想要有任何长久生命力，那么多人连线游戏就是形势的核心所在，并且那意味着和Internet打交道，为编码者打开了那个潘多拉的盒子。 <br/><br/> 那么跟Internet打交道包括些什么呢？首先是要理解Internet是怎么工作的，和点对点与客户机/服务器体系结构的快速讨论。点对点就是你在两台机器上运行游戏，并简单地在它们之间共享输入。每个单独的游戏假定它是正确的，并仅仅在它一幀接一幀的刷新中合并来自另外一台机器的输入。客户机/服务器是一台机器有效地运行游戏，别的机器仅仅是一个终端，接受来自玩家的输入，并渲染服务器让它渲染的任何东西。 <br/><br/> 客户机/服务器的优点是每台机器都将会展现相同的游戏，因为所有的处理都在一个地方完成，没有跨越多台机器，你可以不用考虑每台机器相互之间的同步问题。不足之处是，服务器本身需要有一些重要的CPU可用时间来处理每一个连接的客户机，和一个合适的网络连接来确保每一个客户机及时地接收到它的更新。<br/><br/><br/>了解IP<br/> 我们都已经听说过TCP/IP（传输控制协议/网间协议）和UDP（用户数据包协议）， 在Web网络上有大量关于这些协议的深奥的技术资讯。实际上，在Cisco网站上有一些极好的TCP/IP指导。我们将在较高层面上介绍一些TCP/IP的基本知识，目的是让你更好地了解使用这些标准协议的网络游戏设计者面临的挑战。 <br/><br/> TCP/IP和UDP/IP是两层的通信协议系统。IP层负责网际数据包的传输。UDP或者TCP层将大的数据包传给IP，IP将数据包分割为小的子数据包，为每个数据包加上一个信封，计算出目的地的IP地址，应该如何到达那里，然后将数据包发送到你的ISP，或者不管怎样你连接到网络。 这实在象是在一张明信片上写下你要发送的，贴上邮票，写上地址，塞进一个邮箱，它就送走了。 <br/><br/> UDP和TCP是从你编码者或者游戏接收数据包的高层协议，并决定该如何处理这些数据包。UDP和TCP的区别在于TCP保证数据包的传送和有序，而UDP不保证。UDP是一条直接和IP对话的小路，而TCP是在你和IP之间的一个接口。它像是在你和你的邮件之间有一个管理员助手。使用UDP你会自己为你的信打字，把它们放进一个信封等等。使用TCP你会仅仅向你的管理员口授信稿，管理员会做全部的工作并追踪确认信件送到了。 <br/><br/> 然而，所有这些令人惊奇的为你完成的工作伴随着代价。为了确定数据包通过Internet完好无损地送到了目的方，TCP期待从目的方为它发送的每个数据包发回一个应答包（网络用语是ACK）。如果它在一定时间内没有收到ACK，它就停止发送任何新的数据包，重新发送丢失的数据包，并且将继续这样做直到收到目的方的回应。当你访问一个网页时，我们都已经看到了这种情形，在半途中下载停止了一会然后又重新开始了。可能是一个数据包在什么地方丢失了（假定不时ISP的问题），在任何更多的数据包被发送以前TCP要求重新发送它。 <br/><br/> 这一切的问题是，在认识到出了差错的发送者和实际上正在送达的数据包之间出现了延迟。有时这能花上数秒钟，如果你仅仅只是下载一个文件或一个网页，这不是什么大碍，但如果这是一个游戏数据包而且每秒至少有十次，那么你真的是遇到麻烦了，尤其是因为它停止了其他一切事情。实际上就是这个问题所以几乎没有游戏选择使用TCP作为它们主要的Internet协议，除非它不是一个实时动作游戏。大多数游戏使用 UDP--他们不能保证有序或可靠送达，但它确实很快—或者结果是至少通常比TCP/IP更快。现在我们了解这些了，接下来呢？<br/><br/><br/>客户端预测<br/> 因为 UDP 明显的是快速响应游戏的方式，我们将必须自己处理数据包的丢失和乱序。边而且这是技巧所在。不用说出太多的代码秘密，我就能说有方法。作为开始，有客户端预言，一个被谈论得相当多的词语。当你作为一个客户端连接到一个大的服务器，但是不能连贯地看见来自服务器的更新，客户端预言开始起作用了。正在你的电脑上运行的游戏部分看着你正给它的输入，并在缺乏来自服务器的任何弃绝信息的情况下，对它认为将继续进行的事情作出‘最好的猜测’。它将会显示被猜测的数据，然后当它得到来自服务器的世界的最新状态时，改正它自己，如果需要。你可能会对这个方法的效力感到惊讶。大体而言，大部分时间数据包不容易丢失—大多数时候是一秒的几十分之一，这种情况下游戏没有太多的时间偏离服务器实际上认为正在发生的事情。偏离确实会随着时间变的比较大，大多数游戏里面有一个超时功能，当出现很长时间没有来自服务器的联络时就停止游戏。 <br/><br/> 你正在创造的游戏类型在这里有关系 -- 第一人称射击游戏不需要这样有效的客户端预言，因为它多数情况下仅仅处理“我在哪儿，我是否要射击？”。在第三人称游戏中，你必须更加精确，因此你能够正确地预测你的角色正在播放的动画，并且动作流畅。在这种情形中流畅的动画是完全必要的。Heretic II在这方面有很大的问题，并且是当它开始网络编码时Raven一直不得不处理的最困难的事情之一。 <br/><br/> 当然如果你有一个很不错的网络连接，比如宽带连接，那么这个问题就远没有那么重要。对比较大的数据包有一个更宽的管道，对你的网络连通时间更快速。事实上，宽带对于游戏的主要优点不比较胖的管道多，但大大减少了延迟，特别是你到ISP的第一跳上。对于56K 调制解调器，第一跳典型的延迟是100ms，这已经严重地增加了你到网络上任意一台游戏服务器的潜在连通时间。对于宽带连接比如像DSL，第一跳的延迟时间多半是20ms。使用Windows中一个叫做TraceRoute（TRACERT.EXE）的命令行程序并指定一个目标IP地址或者域名，你能够找出你的第一跳的连通时间。仔细观察第一跳，因为这几乎总是你到你的ISP的网络连通时间。并且观察你在你的ISP的网络内部用了多少跳直到你看见在一个给定跳上列出的一个不同的域名。 <br/><br/> 请注意，宽带并不总是能解决延迟问题。你仍然受最慢的路由器/服务器和数据包从服务器穿越网络到达你的跳数（反之亦然）的支配。有一个宽带连接确实容易缓和这些，但不可能它们最后就消失了。当然，如果你打算要运行某种服务器，你将会需要一个具有足够快速的向上游的数据速率的带宽，因为仅仅一个调制解调器不能够处理一个服务器产生的负荷。 <br/><br/> 值得一提的是，如果你想要在PS2或者Xbox上面玩网络游戏，你将需要一个宽带连接，因为它们两者都不支持调制解调器。<br/><br/><br/>包大小，智能数据传输，和反作弊<br/> 别的必须被处理的事情是数据包的大小。如果你在一个游戏里面*个人都在跑来跑去相互攻击，从一台机器发送到另外一台机器的数据包能变得相当大，达到了一些调制解调器没有带宽处理这些数据的程度。这正在变得特别和那些有着很大的地表系统的游戏有关。这里增加的问题是，因为你有这个很好的地表系统，你能够看得很远，因此能够看见许多其他游戏玩家，使得你为了精确渲染所需要的来自服务器的数据数量以很快的速率增长。我们能做什么呢？ <br/><br/> 好吧，首先必要的是只发送绝对必须的东西给任何给定的客户端，因此他仅仅得到从他的角度观察游戏所需要的东西。发送在他视野以外的人们的数据没有一点意义—他将看不见这些。同时，你最好确保只发送那些每幀之间实际上发生改变的数据。如果一个家伙仍然在播放相同的动画，重新发送数据没有意义。当然，如果数据包丢失时这确实带来一些问题，但这就是为什么好的网络程序员被支付很多金钱，来处理类似这样的东西。 <br/><br/> 还有一些其他的事情也要处理。最近已经有大量的令人苦恼的连线作弊正在发生。这是某些人修改游戏以给他们不正当利益的地方。尽管严格意义上这不是网络的一部分，但它确实发生了。有时人们会创作一些模块，允许他们立即瞄准进入视野的任何人，或者简单地允许他们看穿墙壁，或者让其他游戏玩家看不见他们自己。大部份时间这些事情可以在网络层内部或者在服务器上被处理。任何有100%命中率的人被简单地踢出游戏，因为在人力所及的范围内那是不可能的。<br/><br/> 游戏开发者必须尽一切可能制止作弊行为，但很不幸，人做的东西可以被人突破。所有你能做的就是让作弊变得困难，当确实发生时去尝试发现它。 <br/><br/> 好吧，现在就到这里了。在第8部分中，我们将会看看游戏脚本系统的趣味世界，根据游戏过程中出现的事件来渲染或使能预先定义的场景和行为，协助故事叙述。 <br/><br/> 第8部份: 脚本系统<br/><br/><br/>脚本系统<br/> 我们从第七部分的游戏网络问题来到了脚本系统，因为其呈现的故事叙述机会，最近已经形成一种很大的游戏元素。在一个需要以受控制的方式解释的情景，预先编制的电影脚本是解决问题的方法。在电影中，这通常用来处理或者由主角向一个伙伴解释情形，或者敌人对英雄解释。当然，有其它的方法来做这件事情 -- 叙事者，倒叙，等等 – 但通常是使用实时情景的人们和事件来完成。当然，游戏是不同的，游戏开发者在他们平常的FPS中不应该做太多的倒叙，因为通常会需要载入新的环境或者关卡，以及新的纹理和/或模型。所有这些额外的处理和渲染能影响到主要的游戏序列的性能。你可以重用已经存储在内存里面的场景元素来倒叙，但那样会看上去明显比较粗陋。<br/><br/> RavenSoft 的Star Trek Voyager: Elite Force广泛利用了脚本序列产生游戏中的事件和使用游戏引擎本身的剪辑场景。<br/><br/> 在游戏中设计脚本情节的一个有趣趋势是使用当前极大改进了的3D游戏引擎自己产生剪辑场景。现在这可能像是相当地明显，但是数年以前，当 3D 图形卡还比较简单的时候，剪辑场景通常使用高端3D工作站制作，得到的3D动画然后被记录为一个数字视频文件，以流式文件存储在CD-ROM。你从剪辑场景的漂亮图形画面回到真实游戏的相对粗陋的3D画面，这是相当令人不愉快的失望的事情。但像Half-Life 和 Star Trek Voyager : Elite Force这样的游戏很好地利用了它们自己的引擎产生所有的剪辑场景，结果是剪辑场景和游戏之间的过渡更加平滑。<br/><br/> 把脚本和人工智能区分开来可能是个很好的主意。脚本是你完全控制着一个给定场景，建立玩家几乎总是没有控制的事件，游戏者‘沿着轨道’移动到一个给定地点，或者建立一个游戏玩家需要解决的情形。一个好的例子可能是巨石掉在走廊上，需要游戏玩家找到一个新的逃脱方法。 <br/><br/> 如今有一些不同类型的脚本系统可供程序员或者美术师使用，而且它用非常有条理和逻辑的思想恰当地做这些。第一种是简单的基于文本的，单线索的风格，就像我们程序员习惯的编码。在许多情况，它实际上基於 C，尽管以一种非常简单的形式。 大量这种类似“if this，then do that”的东西。大部分脚本倾向在范围内是相当线性的—意味着它通常由许多在次序上彼此相接的命令组成。在世界中移动角色A指向B。当完成以后，让他讲话，完成以后，移动他指向C。相当简单的事情。<br/><br/> 然后有复杂的东西--允许多重线索，和实际上允许可变情形。可变情形是当脚本开始时你实际上不能确知谁会出现在附近，但是你必须按这样的方式编写脚本以便任何人出现在附近它都将会工作。举例来说--一个正常的简单脚本会有三个家伙，全部被预先定义，全部有一组他们将会讨论的情形。一个可变的脚本将会有三个人,你不能保证是某一个特定的人，并必须按相同的方式工作。或者在一个极端的情形中，也许只有二个，或者甚至一个家伙将会在那里，使得三方交谈有一点困难。 <br/><br/> Raven在Star Trek Voyager: Elite Force中面临的一个很大的问题是这样的情形，使用者可能会想要把一个角色从一条船的某个地方带到另外一个地方，但是从A点到B点的路径可能会随着每次游戏根本地改变。举例来说，他们需要让Munro(你所扮演的游戏主要角色)从发动机舱室到输送舱。 不幸的是由于游戏的非直线性，在事件到达这一点以前你可能已经破坏了涡轮升降机，或者也许 Jeffries 管被损害不能通过。假定当脚本开始的时候我们不知道世界的状态，我们不得不为几乎各种可能发生的事情编写脚本以便适用于这些‘如果。。。怎么办’的情形。而且它仅仅从那里变得更加糟糕。我们能建立的一些情形提供了如此多可能的组合情形，以致于为了一个满意的结论而准确测试每一个可能发生的事情几乎是不可能的。请和在SiN, Star Trek Voyager : Elite Force or Deus Ex中工作的任何人谈谈。QA部门传统地憎恨这些类型游戏，因为这已经使他们的工作比以前更加困难了 50 倍。 <br/><br/> 你能够想象为这些情形编写脚本是何等的困难。但那是今天的非线性游戏路径要求的事情，而且它为何博得了较多的开发支持从而能够努力实现它。<br/><br/><br/>Jim Dose关于脚本系统的论述<br/> 去年底我访谈了Jim Dose--Ritual的前任开发者，现在是Id Software的一个开发者，Doom3脚本系统（和其他一些事情）的设计者。尽管这次访谈有些久了，但仍然是很有洞察力。 <br/><br/> Jim谈了脚本系统和创建一个易用且健壮的系统( 与包含设计者传统想要使用的所有特征相反): <br/><br/> 设计一个脚本系统最难的部份是知道何时该停止。一旦你完成了并开始运行，你发现有许多能够利用它的系统。对于Sin，最初的主意只是要有一个比较容易的方法让关卡设计者描述对象怎样动态的在环境中移动。在项目的后期，我们也使用它来让声音和游戏事件与动画同步，在多个关卡跟踪任务目标，控制HUD的布局和游戏内部电脑控制台用户接口，描述人工智能如何对不同的情形产生反应，以及粒子系统。<br/><br/> 控制复杂度可能也是相当的困难。当你把脚本的力量放进有创造力的人们手中时，他们开始探究他们所能做的界限。时常，他们受启发做一些刚好轻微超出系统能力范围的事情。很容易陷入到这种增加‘仅仅再多一个特征’就允许他们做他们想做的事情之中。随着语言增长，一个可能对最初的规格有意义的语言结构变得严重过度扩充了。在一些时候，重新思考系统变得有意义，但在那时，你可能已经积累了数量巨大的必须重新编写的脚本。和FAKK2一样，Sin遭受了这样的损失。我没有得到对脚本系统进行大规模彻底检查的机会直到我为Rogue's 'Alice'.重写了脚本系统。<br/><br/> 阿们，吉姆。-- Raven已经看到这个恰好在他们的ICARUS系统中出现了。ICARUS 实际上是一种与Jim在上面描述的相同种类的脚本系统，而且负责在Star Trek: Voyager: Elite Force中的所有脚本事件。它在Soldier of Fortune II和Jedi Knight II : Outcast中被重复使用。为了解决系统需要处理的新问题，这些问题在最初的实现中没有被预见/不需要，脚本系统的很多部分已经被重新编写了。<br/><br/><br/>可视化脚本系统<br/> 第二种类型的脚本是可视化脚本系统。使用这种方法，而不是文本文件的编码方式，实际上你能够在真实的游戏环境中使用真实的角色建立你的脚本。你能够追踪角色在世界中行走的路径，定义使用的动画，并且通常得到关于你的脚本实际上将看起来如何的更好的主意。它对我们已经讨论的非线性问题没有太大的真正的帮助，但它确实可以很快速地生成最初的脚本。<br/><br/> 其次，Jim谈论了可视化脚本系统。 <br/><br/> 可视化脚本系统确实有它们的用处，但往往实现更加困难，如果设计得很差，当复杂度上升时就容易让开发者感到困惑。举例来说，人工智能可以用一个流程图似的结构来进行可视化的设计。你能非常容易地可视化地表现人的行为举止方式，用盒子代表状态，箭头代表转化到其它状态，指示角色能够从一个状态转换到另外一个状态的方式。<br/><br/> 脚本的一种通常使用是在游戏世界中控制物体，指示他们他们如何在世界中移动。在一个编辑器中可视化地移动物体到关键位置并播放整个运动的能力对一个设计者可能会更加直观。然而，它确实有它的极限，因为将需要另外一个接口来设计物体在它的移动中必须作出的任何决定。那种能力是把脚本动画片断和类似3DS Max或者Maya 这样的程序产生的动画区分开来。<br/><br/> 在一些时候，使用者可能需要一些方法决定一个脚本为何没有做他们所期望的事情。一些形式的除错工具能使这件工作非常容易。至少，决定哪些脚本正在运行和脚本当前位置的一些方法必需的。在脚本中检查变量，开始，停止，和单步执行的能力也是有帮助的。通常，一个程序师能够在他们的调试器中进行除错，但这个过程要比如果有一些内建的脚本调试器可用时花费的时间更长。<br/><br/><br/> 以上就是第8部份，在接下来的章节中我们将讨论使用现成产品和定制的游戏引擎设计工具的功过得失，然后探究游戏控制机制，开发游戏对象，和一些刺激有趣的事情 (武器系统)。 <br/> 第9部分: 现成产品与定做的游戏引擎设计工具，游戏特定主题<br/><br/><br/>现成产品与定做的设计工具<br/> 我们从第8部份的脚本引擎来到这一章节中的许多主题，我们认为那些铁杆游戏玩家和有志成为游戏开发者的那些人将会发现它们相当有趣。我们将开始讨论现成产品与定制的设计工具。 <br/><br/> 你的工具的选择是你引擎设计的一个非常重要的部份，因为这是你将用来给你的游戏产生内容的东西，是最耗时的部份。在这个过程中有助于节省时间和资源的任何东西都是好的。那些不能的东西就是糟糕的。在那里，那是容易的。<br/><br/> 当然没有那么容易。有比这更多的事情可能会立刻被注意到。你的工具集的选择，和从工具到游戏的资产路径比它听起来更有技巧得多，并受到很多因素的影响，比如，是否适宜手边的工作，费用，内容生产者的熟悉，市场渗透，工具支持等等。当考虑选择现货成品工具，或者即使当开发你自己的工具时，记得开发者实际在做工作，最好能够做需要借助工具做的。一些现货成品工具能在价格上达到那里，当你陷入多个拷贝许可时，费用猛涨。 <br/><br/> 然后就有诱人的可能性从头制造你自己的工具，为你游戏和引擎的需要而设计。这当然需要时间，和程序员大量的努力来产生在开发者友好方式中所需要的东西。快速打造基于窗口的文件转换器是一回事情，从头建造一个完整的关卡设计工具又是另外一回事情。另一方面，如果你确实选择这条道路，最后你会有游戏开发者地带其他人没有的工具，因此你的东西将会看起来是独特的。如今与众不同是一件非常值得想望的事情，而且从群众这些天起突出是一件非常令人想要的事物，产生所有的竞争。<br/><br/> 当然由于内部的工具开发，你需要某人来做所有那些不可避免的小的改变和修正。但这里真正的意义是这是可能的。使用现成的工具，工具开发者会很少因为你需要的一些特征而改变他们的输出文件格式。这样你的东西最后看起来更加通用一些，否则你必须采用额外的步骤使用另外的工具来得到想要的结果，当然会花费开发者更多的时间。 <br/><br/> 值得记住的是如今许多有名的3D工具已经有一段时间的历史了，并且正在产生简直没有错误的产品，更重要的是，对他们所做的已经有一定程度的经验了。 <br/><br/> 如果你选择建造你自己的工具，多半你是，a） 重新创造车轮到某种程度 b） 陷入那些建造现成工具的人们已经遇到过的相同的问题之中，只是他们已经解决了这些问题。时常人们建造一个单一特定的工具花费了相当的时间和努力，并产生了一个远远超出你自己的个人需求的工具。还有，他们有代表性地收编了一些你或者认为是没有用的，或者没有时间自己实现的特征。加上他们典型地有吸收特征你或会没有想有用,或没有时间实现你自己. 这是第三方软件无法争辩的。<br/><br/><br/>插件和目的建造工具<br/> 通常大多数的游戏开发过程最终都是这样的混合，自己开发的文件转换器工具，现成的内容创造工具，和通常那些要增加一些必须的特殊功能的工具的一些附加插件。现成工具在提供你不可避免会需要的功能方面有很长一段时间了，但是正如不可避免，总有一些很有用的，有帮助的，或者完全必须的东西你不能得到。一个小的插件可能是一个很好的替代品，而且时常那就是所走过的路。为特定目的建造的预处理程序也是可用的，比如把TGA文件转换为一个对PS2友好的格式，或者那些相关的东西。<br/><br/> 如果你或你的公司打算建造某种类型游戏的工具，那么这些工具一般是从一个项目到一个项目地演变发展，而不是每次都从头重新建造。如果你变换游戏类型，很好，那些产生具有每个多边形命中能力的高分辨率模型的工具明显地不是一款RTS（即时战略）风格游戏所必须的。 <br/><br/> Gil Gribb，Rave Software的技术带头人，对‘现成的工具’和‘自己动手建造’的问题是这么说的： <br/><br/> "自己开发的工具有能够根据自己产品的需要进行定制的优势，你拥有代码，可以修正任何错误或者增加任何的改进。 <br/><br/> 自制工具的缺点是建造和维护它们是非常昂贵的，通常成本要比现成工具高很多。在许多情况下，由于应用程序范围的缘故，建立自己的工具是完全不可能的，比如说3D建模和动画软件包或者位图编辑软件。" <br/><br/> 当然，如果你想要游戏玩家能够修改你的游戏，而且你自己建立了所有的工具，那么你就必须要向世界发布这些工具。这可能会引起一点点疑惑，记住建立你自己的工具的部分原因是你可以领先你的竞争者。有时侯发布这些工具的源代码甚至可能让你获益匪浅，这确实提供了一种创造内容的方法。再次，Gil Gribb阐述这个主题： <br/><br/> "我是支持发布几乎所有的源代码。我认为我们没有任何来自我们的竞争者的害怕的事情，合法的业务不会想到窃取知识产权。游戏迷，业余游戏制作者，以及游戏的普及都能够从发布的源代码获益。" <br/><br/> 好，我们的游戏引擎剖析系列到这里，当然我们已经特别讨论了许多和引擎相关的主题，下面让我们继续讨论一些与游戏特定相关的部分。<br/><br/><br/>游戏控制机制<br/> 控制机制能够对开发中的游戏带来巨大的差别，有时甚至表明你正在建立的游戏的种类或者风格。 <br/><br/> 尝试在某个时候用gamepad玩一个即时战略类游戏--它不只没有乐趣。有时当你被限制在一个特定的输入装置的时候，例如鼠标和键盘，为你的游戏发明新的控制方法会是一个令人筋疲力尽的过程。当Raven开始开发Heretic II时他们决定做的第一件事情之一就是为用鼠标使用第三人称照相机尝试和找出一个直观的方法。在这以前，大多数游戏采用的是Tomb Raider风格的照相机（第三人称预兆的追逐）他们发现这时常不能正确地工作，在很多情形下会给玩家带来挫折。照相机时常会得到任意的视角，如果可能的话移动相机，而且有时改变玩家的方向。 <br/><br/> 假定他们的目标对象是FPS游戏人群，Raven需要找到一个对FPS游戏玩家来说直观的控制乌鸦座（Corvus）的方式。他们这样做了，但确实花费了一些时间，和一些不同的方式—他们应当让照相机固定在一个方向吗，或者让它是浮动的吗？大多数游戏开发努力—除非一个确定类型游戏的一个没有虚饰的实现—倾向于花费一些研发找出物理控制装置和游戏需要的内部控制机制的最直接的合并。这里是一个暗示—一旦你发现一个方式很起作用，就坚持下去。用这种方式控制游戏内在的东西能把视野，直觉，甚至游戏的焦点完全改变成你从未想要过的东西。发现起作用的东西，证明它起作用，然后就别管它。过分设计控制会导致特征偏离和可察觉的游戏概念问题。 <br/><br/> 像这类特征偏离的一个很好的例子可以在Independence War中看到。这款游戏有着如此多的模式，按键，等等，仅仅熟悉和操纵游戏都不可能。<br/><br/> 很明确这里的关键是简单。一个好的经验法则是，在正常的游戏中，如果你的游戏需要比在普通的gamepad的按键或者你手上的手指更多的按键，那么一些事情需要被重做。注意, 我不是说一款游戏不应该有灵活性—Soldier of Fortune必定有许多可能的按键设定。但通常，当你认为它们大多数实际上都是不需要的时候Quake引擎有一个很好的方式。是的，你可以选择你想要使用什么武器，但你不是必须这样。游戏将会自动地为你那样做。这就是灵活性和过度设计之间的不同。如果游戏需要你按下某个键来选择一个武器，那将会有问题。你理解这个了吗？ <br/><br/> 控制机制不能被过高估价 -- 一款游戏时常将会根据玩家觉得他们对事件或者主要角色有多少控制而获得成功或失败。如果控制被改变，重新定向，或仅仅简单地从他们哪儿移除，它能导致游戏自身缺乏参与，不用说，那是一件很糟糕的事情。在这上面花费时间并让它保持简单，将会有巨大的帮助。<br/><br/><br/>实体和照相机<br/> 现在我们来到了引擎不太令人愉快的部份，也是定义得最少的部分。当游戏运行的时候，游戏在这个部分能变得极端地多出错，耗时间，或仅彻底的极限。 <br/><br/> 在这里我们所谈论的是游戏引擎的 "游戏" 部份。这个部分使用所有的其它技术让一些事物显示在屏幕上，到处移动，让它对你产生反应并且让你对一些事物产生反应。这个系统有许多方法，但现在我将紧扣Quake的方法因为那是我最熟悉的。<br/><br/> 让我们从实体开始。这些可以被定义为‘游戏对象’。现在那不仅仅意谓你在屏幕上看见的模型，虽然实体确定地控制这些 -- 实体也可能是其他的事物。基本上它是游戏在任何给定时间需要知道的任何事物，例如让事情继续进行的定时器，模型的碰撞检测盒，特效，模型，游戏玩家，等等。<br/><br/> 甚至照相机都可能是实体（在几乎所有Raven的产品中都是这样）。照相机在世界中被分配一个有角度的原点，它们每幀都被刷新并告知渲染器应该从哪里得到它的视野数据，and off we go。典型地实体是为了返回到游戏早先的状态而被存储和装载的那些东西。通常在装载过程中使用的方法是把游戏地图装载进来，好像你正在重新开始一个关卡一样，然后装载所有存储的实体，这样他们就返回到游戏存储时它们的状态。Voila，即刻返回一个存储的游戏。当我理解Heretic II的方法时这并不是那么的容易—装载/存储几乎比其他任何事情带给我的问题还多，特别是在协作模式。 <br/><br/>照相机有许多形式：<br/><br/> 自由形式：照相机能去任何地方 <br/> 脚本：照相机可以沿着一条设定的路径前进 <br/> 游戏时间：照相机有必须要遵循的定义的行为 <br/><br/> 仅仅说"嗯，我将仅仅跟随主要的角色"是不够的。这意谓你也可能需要让照相机穿过墙壁，或让它按一些方式移动以致甚至引起一些胃的恶心。让它沿着一些定义的上下运动路径前进也有益处，如同任何玩Descent游戏超过一小时的人可以告诉你的一样。身体和头部习惯于上下是一个静态的变量，并当它不是时，他们不喜欢它。制作Quake 1的 Mike Abrash，曾经告诉我即使当它被定义，他仍然处理 的麦可 Abrash 地震 1,曾经告诉我即使当它被定义,他仍然从他们正制作的游戏感到运动恶心。他提到，对于他来说，离开制作Quake 1一年时间才让他的胃安定下来。啊哈，我们所作出的牺牲。<br/><br/><br/>武器系统<br/> 游戏模块的另外一个部份是武器系统。大多数的游戏有武器系统或类似的东西。 这是在世界中影响其他的物体，而且使他们对给定情形产生反应的东西，--比如说被射击。通常武器系统由许多不同的类型组成；攻击扫描，基于飞弹的，以及范围形式。<br/><br/> 攻击扫描是直接攻击武器。在屏幕上他们产生的效果只是那样，一个效果。当使用它的时候，和武器的实际操作没有任何关系。当你用手枪开火时，子弹被认为立即穿过世界并直接击中在它运动轨迹上的任何人/事物。 <br/><br/> 基于飞弹的武器有一个占用有限时间穿越世界的真实射弹，从而带给对方一些可以躲避的时间。<br/><br/> 基于范围的武器像手榴弹和炸弹一样的东西，不必击中就可以伤害到你；你只是必须处于爆炸范围内。处在那种爆炸范围内的玩家受到飞溅损害。熔岩是另外一种形式的基于范围的武器。 <br/><br/> 那么你如何决定什么被击中而什么没有被击中呢？很好，这个问题把我们带到了追踪，我们将在接下来的物理学和人工智能章节更多的接触追踪。这是一组函数例程，当给定世界中一条从A点到B点的直线时，比如从枪的末端到预先定义的距离，它告诉游戏什么被击中。追踪很棒，但很昂贵，因为他们必须对那条线上的所有多边形进行‘碰撞检测’来看是否有什么地方被击中，更不用说模型和其它对象了。这也是一些物理学的工作方式，从一个给定的角色做一个笔直向下的跟踪可以知道地板位于什么地方。肆意的滥用追踪 — 如，在游戏的一幀中多次使用它们 -- 对于今天许多游戏的速度下降是有责任的。在Jedi Knight II：Outcast，他们的光刀战斗已经遇到了这个问题，因为他们不仅需要知道光刀是否击中了某处的什么和它现在的位置，而且对于它们之间的所有点都得这样，他们对光刀做了多次追踪。 <br/><br/><br/> 好吧，又一个章节结束了，仅仅剩下两个章节了。下面我们介绍人工智能和搜索的更多细节。 <br/><br/> 第10部分: 人工智能和导航（路径发现）<br/><br/><br/>人工智能（AI）<br/> 我们上面已经用了其他九个章节介绍了游戏引擎，现在让我们深入到非常有趣和重要的人工智能主题。人工智能如今正在变成被谈论得最多的仅次于游戏引擎渲染能力的游戏开发领域之一，确实如此。直到大约两年半以前，游戏似乎主要是在考虑你能够渲染多少个多边形，眼睛是多么的漂亮，和… 好…劳拉的胸部是多么的有弹性...既然我们现在已经能够渲染出非常真实的乳房，中心就开始转移到我们实际上用那些多边形做什么了（即玩游戏）。因为它给你提供实际玩游戏的刺激作用和参与游戏世界中正在进行的事情，所以人工智能在这个领域非常关键。<br/><br/> 人工智能包括了全部的东西，从在Tetris中决定哪一块新砖头掉落（这很大程度上知识一个随即数产生器）， 一直到创造基于小组的策略游戏，这些游戏和你交互，并且实际上在你玩的时候向你学习。人工智能包含了许多规则，如果你（作为一个游戏开发者）没有花费足够多的时间让它正确地工作，它会反过来在你屁股上咬一口。所以让我们谈论一些哪些规则？这样你能更好地理解人工智能系统会确实是多么的复杂。为了避免法律上的纠纷，我们将使用一个假设的游戏而不是一个真实的游戏作为例子。<br/><br/> 假设我们的游戏中有坏份子生活在3D世界中，干着他们的事情，而且如果你打搅了他们的正常次序他们就会反抗你（玩家）。你必须决定的第一件事情就是他们正在从事的到底是什么事情呢？他们正在守卫什么东西吗？在巡查？在计划一个聚会？在购买食品杂货？在整理床铺？建立行为的基线是游戏开发者的工作之一。一旦有了这个，你就总有NPC（非玩家角色）或计算机控制的‘人’能够恢复去做的事情，玩家与他们的交互就应当能被完成。 <br/><br/> 一旦我们知道一个NPC角色需要做什么 — 比如它在守卫一扇门，并且在这个区域小巡逻，NPC也必须有‘世界意识’。游戏设计者需要决定NPC的人工智能将如何看见世界，和它的知识范围。你将会仅仅说“计算机知道正在进行的每件事情” 吗？这通常被认为是一件糟糕的事情，因为非常明显计算机能够看见和听见你不能看见和听见的事情，这被当成是在作弊。不是一种有趣的经历。或者你将模拟他的视野，这样他只能够对他能看见的事物作出反应吗？当有墙壁出现时这里就有问题了，因为你开始进入那些我在第九部分提到的‘追踪’例程，看看NPC是否试图对被墙壁挡住的人作出反应。这是一个很明显的人工智能问题，但是当涉及到门和窗户时，这个甚至变得更加复杂了。 <br/><br/> 当你开始为AI刺激例程增加听觉意识时，这依然变得更加复杂了。但是，这个意识是那些关键的“小事情”之一，这些使得假想的游戏世界似乎更加真实，或者能够去除怀疑的悬念。如果你碰到过这样的事情，请举手：你在枪战中跟一个NPC交战，免除了一个NPC，你绕着角落行走并遇到了另外一个NPC依然保持他的缺省行为模式，没有意识到刚刚发生的事情。现在，枪是嘈杂的事物，枪战可能已经明显地提醒了一个“倾听”的NPC有些事情正在进行。避免这种事情的技巧在于找到一个有效的方式来决定声源（即你武器的发射）的距离是否足够接近到NPC能够听见。<br/><br/> 接下来就是决策例程。当我们的巡逻NPC角色能够听到但不能看见某物时，你试图实现什么样的行为呢？他去寻找它吗？不理睬它？你如何决定什么是重要的声音他应该去或者不去调查？如同你看见的一样，这会很快变得非常的复杂。有很多方法来建造处理这些事情的代码，但通常这样是一个好主意，建立一个不是对特定的NPC而是对所有的NPC都起作用的系统，该系统基于你能够在游戏引擎以外的文本文件中建立的属性。这样就不需要程序员为一个给定的角色而改变AI，并且如果你对游戏代码做了改动，它将立即自动地应用到所有的角色，这在大多数情况下是一件好事情。 <br/><br/> 其他的世界意识问题会冒出来，比如这样的情形，两个守卫彼此紧挨着站立，你用狙击武器干掉了一个，而另外一个站在哪儿完全不知已经发生的事情。再者，遵守真实世界行为的细节是一款好游戏和一款伟大游戏的之间的区别。 <br/><br/> 让我们说你已经把所有的刺激-响应部分准备好了—你已经扫描了世界，决定NPC应当对正在进行的一些事情作出反应—他听到了玩家角色发出了声响—并且你（游戏开发者）决定了他应当对这个做些什么—他将去调查。现在更加复杂的事情来了。他如何离开现在的位置，到达他认为发出声音的地方，而不会想通常的数字傻瓜一样跑到墙壁里面，碰到家具呢？继续往下看…<br/><br/><br/>有关正确的路径 --- 世界导航<br/> 快速，准确的世界导航( 也叫做路径-发现) 近来已经成为游戏开发者的圣杯。 让它看起来非常信服是一件非常困难的事情。你需要有局部世界的地理知识—墙壁的位置，台阶，悬崖和建筑物等的边缘。你也需要世界中的对象的知识—比如家具，汽车，尤其是其他人的位置。真正最后的因素是问题所在，一会儿我们将回到这一点上。 <br/><br/> 世界导航通常被分为两个领域，世界导航和局部导航。二者实际上只是范围上的区别，但大多数的程序员分别对待它们，因为这样处理起来容易一些。世界导航例程处理理解房间，门和一般的地理学，并计算出让玩家或者角色从世界中的A点到达B点的一条路径。“它将让你从A点到达B点”，这是一句很容易说的话，不是吗？说起来容易，但做起来很困难。理解世界是一个非常复杂问题，我已经看到过许多尝试过的解决办法。QuakeIII的机器人遵照建造的预先处理过的地图，一般的说法，使用原来地图的地面。预处理器检测地面元素，由地图建造者作上标记，并自己建造一个只使用地面的世界简化地图。机器人并不关心墙壁，因为他们从不接近它们，就像他们遵照地面的地图一样，设计上已经把避免墙壁构造在里面了。 <br/><br/> 其他方法在地图本身里面建造一些小的结点，AI可以追随它们。这些结点通常被建造在彼此的视线里面，有从一个结点到其他所有结点的连接，角色AI能够直接‘看见’，所以你就确保了从一个结点移动到另外一个结点时AI不会试图穿越墙壁。如果有门或者降落物，你能够事先用这些结点对路径的信息编码，于是NPC能够采用适当的行为—等候电梯，打开一扇门，或者从一点跳到另外一点。这实际上是HereticII使用的系统，也是Raven在他们其他的大多数游戏中使用的系统。 <br/><br/> 关于这个主题，3D Realms的Jess Crable，现在为Duke Nukem Forever工作，如是说： <br/><br/> "导航在许多方面是个巨大的挑战，主要是当游戏中有大量正在发生的事情和一些非计划性的东西，比如障碍。为了避免和（或）真实地对非计划性的障碍物导航（例如像另外的AI），AI需要很好地知道正在它周围发生的事情。比较而言另外一个巨大的挑战就是真实感。如果AI正在表现玩家在实际生活中看到的一些东西，比如说一个人，或者一条狗， 那么让它看上去真实可信就更加困难。"<br/><br/> 然后就是局部导航。我们可能有一条路径让我们的 NPC 从他在世界中的位置，移动到他认为听到声音的地方，但你不能盲目地按照这个执行并期望得到看起来不错的结果。这种性质的路径倾向于非常特定于一个给定的目的。当你沿着走廊从一个房间跑到另外一个房间时，它很好，但如果你试图指导他穿越一个巨大的房间时，路径结点方法容易最终得到一些看起来很奇怪的发现路径。这些路径也不是动态的。因为他们被预先建造，他们不容易考虑到世界的任何动态变化。桌子可能有被移动过了，椅子被破坏了，墙壁被摧残，当然，人们会移动。这就是局部导航不同于世界导航的地方。它必须考虑局部世界并导航NPC在里面穿越。它必须知道周围的环境，存在哪些可以选择的路径，并决定选择哪一条。 <br/><br/> 在局部导航中最大的问题是其他的NPC。给定一个发现路径的具体例程，如果你在相同的一般区域中有不止一个NPC，他们都试图到达世界的同一地点，结果是他们都非常容易有相同的路径。然后他们试图沿着这个路径行进，结果彼此遇到一起，然后花费他们所有的时间试图将彼此分开，并且一旦成功地分开了，他们再次试图到达目标，然后我们又再次看到同样的事情发生。这一切看起来都是非常的愚蠢，这不是大多数人想要的效果。所以需要一些路径发现中的变化来避免这种情形，需要一些妥善处理避免的代码。有大量能够帮助解决这种情形的算法。<br/><br/><br/>人工智能和角色动画问题<br/> 当然，当角色自己在世界中行走时你必须完全地决定你想要角色播放什么动画。听起来无足轻重？不是的。关于这个主题，Raven的 Chris Reed—Soldier of FortuneII使用名为LICH的AI系统的现在的负责人—如是说： <br/><br/> "此刻我能告诉你，我们在平滑移动上正有着最大的困难。在一个多丘陵的长满草的丛林中试图让五个角色在彼此附近行走是一个非常困难的问题。让底层系统完美是重要的，因为除非角色在较低层次上（避免墙壁，适当的动画）看起来真实，他们不能够有效地表达任何较高层次决定的智能。由于这个单独的原因，动画和底层的移动是最重要的和最难实现的。它确实需要完美。"<br/><br/> 因此我们已经让我们的角色从A点到达了B点，他自己穿越世界，在途中避免障碍物，正确播放动画，现在到达了这里。他看见了你。接下来做什么呢？很明显更多的是作出决策。他将向你射击。太棒了。你回应射击。现在干什么？当他试着逃走的时候，现在你再次经历全部同样的事情。 <br/><br/> 为了让这些情形看起来令人信服，你看见了这里必须要处理的大量问题。如果你建立你的AI使用没有动画的行为让NPC执行，这能被混合。一些Soldier of Fortune中的AI就是这样的例子。他们受到了指责，因为坏家伙没有以适当的方式对刺激作出反应。当他们明显应该这样做的时候，敌方NPC不扫射，或者不逃跑。部分问题是他们没有扫射敌人NPC的动画，或者让他们往回跑，因为空间的问题。因此世界上所有最伟大的AI代码都不能够解决这个问题。这是所有要考虑的重要事情。 <br/><br/> 想知道隐藏的难点吗？看看我前面所有的描述，然后试着将它应用到一组NPC上，这些NPC彼此必须说话，设定目标，彼此沟通，但不妨碍彼此的方式。一旦你这么做了，试试那些代码，作为玩家的队友做上面所描述的这些，然而不要在枪战中妨碍他。现在这是复杂的。然后这成为乐趣。这是最困难的部分。Raven的 Chris Reed关于AI‘感觉’的一些评论： <br/><br/> "我认为反馈是AI的一个极大的问题。如果角色对于他周围环境的变化不产生反应，游戏的真实感就被完全打破了。这有许多明显的例子(听见枪炮声，看见同伴被击中...)，以及一些更加微妙的事情(当两个人通过门厅时看着彼此并点头致意)。玩家是乐意接受一些生硬和可预测性的，但是这些事物容易把游戏带到现实生活。"<br/><br/> 并且Jess Crable 赞同：<br/><br/> "平衡是非常重要的… 对玩家将会有多大的乐趣至关重要，但还有其他的问题要平衡。游戏玩家时常说他们想在游戏中看见更加真实的人工智能。然而，太多的真实感开始把乐趣带走。在这两者之间必须要有一个好的平衡。变化和随机同样也很重要—行为的变化，和保持在可信范围内的一定程度的不可预测性。"<br/><br/><br/>游戏规则与自然发生的游戏<br/> 在我们关于AI的所有描述中，我们采用的是FPS的方式。有不止一种的AI。我们已经描述的是处理3D世界一组规则。AI远远不止这些。时常最好的AI实际上非常的简单。它就是一组规则，玩家必须响应和处理的响应（或开始）动作的规则。 <br/><br/> 这里应当处理一个被称为“自然发生的游戏”的专业术语。 自然发生的游戏本质上创造游戏将遵守的规则，那将会造成游戏程序员不能预见的情形。 <br/><br/> 举例来说，象棋能被认为是自然发生的游戏。有一组规则，但游戏能够陷入各种程序员不能够以个别方式处理的情形。你不能为每一种可能的棋局情形编码规则。很清楚，游戏玩家每次不会总是面临相同的游戏情景。一定程度上，进行中的游戏情形会根据他的行动而发生变化。Black and White是这种情形的一个完美的例子，和The Sims一样—游戏有它自己的规则，但你如何运用和调和他们是你自己的事情。实际上，你在玩游戏的过程中创造着游戏，而不是照着游戏设计者/程序员已经为你定义的路线进行。 <br/><br/> 有可能把基于规则的，自然发生的游戏方式和FPS环境混合在一起。Half Life中的一些海军陆战队士兵的行为就是这样做的—压制火力和侧翼攻击从设定的规则中动态完成。它看起来是动态的，而且一定程度上它是这样。然而，在FPS世界中仅仅有一组规则时常是不够的。几何和其他AI时常能够打败简单的规则，这让保持正确并依然有趣变得更加困难。所以对那些可怜的AI程序员有一些同情心吧。他们的工作不容易。 <br/><br/><br/> 好吧，下面还有一个章节，仅仅还剩下一个章节了。在最后的章节里，我们将讨论头顶显示，菜单系统，游戏定制和配置，游戏引擎版权与建造，最后是游戏“mods”。 <br/>
页:
[1]
2