游戏引擎全剖析(9-11)

第9部分: 现成产品与定做的游戏引擎设计工具，游戏特定主题

 

现成产品与定做的设计工具
　　我们从第8部份的脚本引擎来到这一章节中的许多主题，我们认为那些铁杆游戏玩家和有志成为游戏开发者的那些人将会发现它们相当有趣。我们将开始讨论现成产品与定制的设计工具。 

　　你的工具的选择是你引擎设计的一个非常重要的部份，因为这是你将用来给你的游戏产生内容的东西，是最耗时的部份。在这个过程中有助于节省时间和资源的任何东西都是好的。那些不能的东西就是糟糕的。在那里，那是容易的。

　　当然没有那么容易。有比这更多的事情可能会立刻被注意到。你的工具集的选择，和从工具到游戏的资产路径比它听起来更有技巧得多，并受到很多因素的影响，比如，是否适宜手边的工作，费用，内容生产者的熟悉，市场渗透，工具支持等等。当考虑选择现货成品工具，或者即使当开发你自己的工具时，记得开发者实际在做工作，最好能够做需要借助工具做的。一些现货成品工具能在价格上达到那里，当你陷入多个拷贝许可时，费用猛涨。 

　　然后就有诱人的可能性从头制造你自己的工具，为你游戏和引擎的需要而设计。这当然需要时间，和程序员大量的努力来产生在开发者友好方式中所需要的东西。快速打造基于窗口的文件转换器是一回事情，从头建造一个完整的关卡设计工具又是另外一回事情。另一方面，如果你确实选择这条道路，最后你会有游戏开发者地带其他人没有的工具，因此你的东西将会看起来是独特的。如今与众不同是一件非常值得想望的事情，而且从群众这些天起突出是一件非常令人想要的事物，产生所有的竞争。

　　当然由于内部的工具开发，你需要某人来做所有那些不可避免的小的改变和修正。但这里真正的意义是这是可能的。使用现成的工具，工具开发者会很少因为你需要的一些特征而改变他们的输出文件格式。这样你的东西最后看起来更加通用一些，否则你必须采用额外的步骤使用另外的工具来得到想要的结果，当然会花费开发者更多的时间。 

　　值得记住的是如今许多有名的3D工具已经有一段时间的历史了，并且正在产生简直没有错误的产品，更重要的是，对他们所做的已经有一定程度的经验了。 

　　如果你选择建造你自己的工具，多半你是，a） 重新创造车轮到某种程度 b） 陷入那些建造现成工具的人们已经遇到过的相同的问题之中，只是他们已经解决了这些问题。时常人们建造一个单一特定的工具花费了相当的时间和努力，并产生了一个远远超出你自己的个人需求的工具。还有，他们有代表性地收编了一些你或者认为是没有用的，或者没有时间自己实现的特征。加上他们典型地有吸收特征你或会没有想有用,或没有时间实现你自己. 这是第三方软件无法争辩的。

插件和目的建造工具
　　通常大多数的游戏开发过程最终都是这样的混合，自己开发的文件转换器工具，现成的内容创造工具，和通常那些要增加一些必须的特殊功能的工具的一些附加插件。现成工具在提供你不可避免会需要的功能方面有很长一段时间了，但是正如不可避免，总有一些很有用的，有帮助的，或者完全必须的东西你不能得到。一个小的插件可能是一个很好的替代品，而且时常那就是所走过的路。为特定目的建造的预处理程序也是可用的，比如把TGA文件转换为一个对PS2友好的格式，或者那些相关的东西。

　　如果你或你的公司打算建造某种类型游戏的工具，那么这些工具一般是从一个项目到一个项目地演变发展，而不是每次都从头重新建造。如果你变换游戏类型，很好，那些产生具有每个多边形命中能力的高分辨率模型的工具明显地不是一款RTS（即时战略）风格游戏所必须的。 

　　Gil Gribb，Rave Software的技术带头人，对‘现成的工具’和‘自己动手建造’的问题是这么说的： 

　　"自己开发的工具有能够根据自己产品的需要进行定制的优势，你拥有代码，可以修正任何错误或者增加任何的改进。 

　　自制工具的缺点是建造和维护它们是非常昂贵的，通常成本要比现成工具高很多。在许多情况下，由于应用程序范围的缘故，建立自己的工具是完全不可能的，比如说3D建模和动画软件包或者位图编辑软件。" 

　　当然，如果你想要游戏玩家能够修改你的游戏，而且你自己建立了所有的工具，那么你就必须要向世界发布这些工具。这可能会引起一点点疑惑，记住建立你自己的工具的部分原因是你可以领先你的竞争者。有时侯发布这些工具的源代码甚至可能让你获益匪浅，这确实提供了一种创造内容的方法。再次，Gil Gribb阐述这个主题： 

　　"我是支持发布几乎所有的源代码。我认为我们没有任何来自我们的竞争者的害怕的事情，合法的业务不会想到窃取知识产权。游戏迷，业余游戏制作者，以及游戏的普及都能够从发布的源代码获益。" 

　　好，我们的游戏引擎剖析系列到这里，当然我们已经特别讨论了许多和引擎相关的主题，下面让我们继续讨论一些与游戏特定相关的部分。

游戏控制机制
　　控制机制能够对开发中的游戏带来巨大的差别，有时甚至表明你正在建立的游戏的种类或者风格。 

　　尝试在某个时候用gamepad玩一个即时战略类游戏--它不只没有乐趣。有时当你被限制在一个特定的输入装置的时候，例如鼠标和键盘，为你的游戏发明新的控制方法会是一个令人筋疲力尽的过程。当Raven开始开发Heretic II时他们决定做的第一件事情之一就是为用鼠标使用第三人称照相机尝试和找出一个直观的方法。在这以前，大多数游戏采用的是Tomb Raider风格的照相机（第三人称预兆的追逐）他们发现这时常不能正确地工作，在很多情形下会给玩家带来挫折。照相机时常会得到任意的视角，如果可能的话移动相机，而且有时改变玩家的方向。 

　　假定他们的目标对象是FPS游戏人群，Raven需要找到一个对FPS游戏玩家来说直观的控制乌鸦座（Corvus）的方式。他们这样做了，但确实花费了一些时间，和一些不同的方式—他们应当让照相机固定在一个方向吗，或者让它是浮动的吗？大多数游戏开发努力—除非一个确定类型游戏的一个没有虚饰的实现—倾向于花费一些研发找出物理控制装置和游戏需要的内部控制机制的最直接的合并。这里是一个暗示—一旦你发现一个方式很起作用，就坚持下去。用这种方式控制游戏内在的东西能把视野，直觉，甚至游戏的焦点完全改变成你从未想要过的东西。发现起作用的东西，证明它起作用，然后就别管它。过分设计控制会导致特征偏离和可察觉的游戏概念问题。 

　　像这类特征偏离的一个很好的例子可以在Independence War中看到。这款游戏有着如此多的模式，按键，等等，仅仅熟悉和操纵游戏都不可能。

　　很明确这里的关键是简单。一个好的经验法则是，在正常的游戏中，如果你的游戏需要比在普通的gamepad的按键或者你手上的手指更多的按键，那么一些事情需要被重做。注意, 我不是说一款游戏不应该有灵活性—Soldier of Fortune必定有许多可能的按键设定。但通常，当你认为它们大多数实际上都是不需要的时候Quake引擎有一个很好的方式。是的，你可以选择你想要使用什么武器，但你不是必须这样。游戏将会自动地为你那样做。这就是灵活性和过度设计之间的不同。如果游戏需要你按下某个键来选择一个武器，那将会有问题。你理解这个了吗？ 

　　控制机制不能被过高估价 -- 一款游戏时常将会根据玩家觉得他们对事件或者主要角色有多少控制而获得成功或失败。如果控制被改变，重新定向，或仅仅简单地从他们哪儿移除，它能导致游戏自身缺乏参与，不用说，那是一件很糟糕的事情。在这上面花费时间并让它保持简单，将会有巨大的帮助。

实体和照相机
　　现在我们来到了引擎不太令人愉快的部份，也是定义得最少的部分。当游戏运行的时候，游戏在这个部分能变得极端地多出错，耗时间，或仅彻底的极限。 

　　在这里我们所谈论的是游戏引擎的 "游戏" 部份。这个部分使用所有的其它技术让一些事物显示在屏幕上，到处移动，让它对你产生反应并且让你对一些事物产生反应。这个系统有许多方法，但现在我将紧扣Quake的方法因为那是我最熟悉的。

　　让我们从实体开始。这些可以被定义为‘游戏对象’。现在那不仅仅意谓你在屏幕上看见的模型，虽然实体确定地控制这些 -- 实体也可能是其他的事物。基本上它是游戏在任何给定时间需要知道的任何事物，例如让事情继续进行的定时器，模型的碰撞检测盒，特效，模型，游戏玩家，等等。

　　甚至照相机都可能是实体（在几乎所有Raven的产品中都是这样）。照相机在世界中被分配一个有角度的原点，它们每幀都被刷新并告知渲染器应该从哪里得到它的视野数据，and off we go。典型地实体是为了返回到游戏早先的状态而被存储和装载的那些东西。通常在装载过程中使用的方法是把游戏地图装载进来，好像你正在重新开始一个关卡一样，然后装载所有存储的实体，这样他们就返回到游戏存储时它们的状态。Voila，即刻返回一个存储的游戏。当我理解Heretic II的方法时这并不是那么的容易—装载/存储几乎比其他任何事情带给我的问题还多，特别是在协作模式。 

照相机有许多形式：

　　自由形式：照相机能去任何地方 
　　脚本：照相机可以沿着一条设定的路径前进 
　　游戏时间：照相机有必须要遵循的定义的行为 

　　仅仅说"嗯，我将仅仅跟随主要的角色"是不够的。这意谓你也可能需要让照相机穿过墙壁，或让它按一些方式移动以致甚至引起一些胃的恶心。让它沿着一些定义的上下运动路径前进也有益处，如同任何玩Descent游戏超过一小时的人可以告诉你的一样。身体和头部习惯于上下是一个静态的变量，并当它不是时，他们不喜欢它。制作Quake 1的 Mike Abrash，曾经告诉我即使当它被定义，他仍然处理 的麦可 Abrash 地震 1,曾经告诉我即使当它被定义,他仍然从他们正制作的游戏感到运动恶心。他提到，对于他来说，离开制作Quake 1一年时间才让他的胃安定下来。啊哈，我们所作出的牺牲。

武器系统
　　游戏模块的另外一个部份是武器系统。大多数的游戏有武器系统或类似的东西。 这是在世界中影响其他的物体，而且使他们对给定情形产生反应的东西，--比如说被射击。通常武器系统由许多不同的类型组成；攻击扫描，基于飞弹的，以及范围形式。

　　攻击扫描是直接攻击武器。在屏幕上他们产生的效果只是那样，一个效果。当使用它的时候，和武器的实际操作没有任何关系。当你用手枪开火时，子弹被认为立即穿过世界并直接击中在它运动轨迹上的任何人/事物。 

　　基于飞弹的武器有一个占用有限时间穿越世界的真实射弹，从而带给对方一些可以躲避的时间。

　　基于范围的武器像手榴弹和炸弹一样的东西，不必击中就可以伤害到你；你只是必须处于爆炸范围内。处在那种爆炸范围内的玩家受到飞溅损害。熔岩是另外一种形式的基于范围的武器。 

　　那么你如何决定什么被击中而什么没有被击中呢？很好，这个问题把我们带到了追踪，我们将在接下来的物理学和人工智能章节更多的接触追踪。这是一组函数例程，当给定世界中一条从A点到B点的直线时，比如从枪的末端到预先定义的距离，它告诉游戏什么被击中。追踪很棒，但很昂贵，因为他们必须对那条线上的所有多边形进行‘碰撞检测’来看是否有什么地方被击中，更不用说模型和其它对象了。这也是一些物理学的工作方式，从一个给定的角色做一个笔直向下的跟踪可以知道地板位于什么地方。肆意的滥用追踪 — 如，在游戏的一幀中多次使用它们 -- 对于今天许多游戏的速度下降是有责任的。在Jedi Knight II：Outcast，他们的光刀战斗已经遇到了这个问题，因为他们不仅需要知道光刀是否击中了某处的什么和它现在的位置，而且对于它们之间的所有点都得这样，他们对光刀做了多次追踪。 

　　好吧，又一个章节结束了，仅仅剩下两个章节了。下面我们介绍人工智能和搜索的更多细节。

 

 

第10部分: 人工智能和导航（路径发现）

 

人工智能（AI）
　　我们上面已经用了其他九个章节介绍了游戏引擎，现在让我们深入到非常有趣和重要的人工智能主题。人工智能如今正在变成被谈论得最多的仅次于游戏引擎渲染能力的游戏开发领域之一，确实如此。直到大约两年半以前，游戏似乎主要是在考虑你能够渲染多少个多边形，眼睛是多么的漂亮，和… 好…劳拉的胸部是多么的有弹性...既然我们现在已经能够渲染出非常真实的乳房，中心就开始转移到我们实际上用那些多边形做什么了（即玩游戏）。因为它给你提供实际玩游戏的刺激作用和参与游戏世界中正在进行的事情，所以人工智能在这个领域非常关键。

　　人工智能包括了全部的东西，从在Tetris中决定哪一块新砖头掉落（这很大程度上知识一个随即数产生器）， 一直到创造基于小组的策略游戏，这些游戏和你交互，并且实际上在你玩的时候向你学习。人工智能包含了许多规则，如果你（作为一个游戏开发者）没有花费足够多的时间让它正确地工作，它会反过来在你屁股上咬一口。所以让我们谈论一些哪些规则？这样你能更好地理解人工智能系统会确实是多么的复杂。为了避免法律上的纠纷，我们将使用一个假设的游戏而不是一个真实的游戏作为例子。

　　假设我们的游戏中有坏份子生活在3D世界中，干着他们的事情，而且如果你打搅了他们的正常次序他们就会反抗你（玩家）。你必须决定的第一件事情就是他们正在从事的到底是什么事情呢？他们正在守卫什么东西吗？在巡查？在计划一个聚会？在购买食品杂货？在整理床铺？建立行为的基线是游戏开发者的工作之一。一旦有了这个，你就总有NPC（非玩家角色）或计算机控制的‘人’能够恢复去做的事情，玩家与他们的交互就应当能被完成。 

　　一旦我们知道一个NPC角色需要做什么 — 比如它在守卫一扇门，并且在这个区域小巡逻，NPC也必须有‘世界意识’。游戏设计者需要决定NPC的人工智能将如何看见世界，和它的知识范围。你将会仅仅说“计算机知道正在进行的每件事情” 吗？这通常被认为是一件糟糕的事情，因为非常明显计算机能够看见和听见你不能看见和听见的事情，这被当成是在作弊。不是一种有趣的经历。或者你将模拟他的视野，这样他只能够对他能看见的事物作出反应吗？当有墙壁出现时这里就有问题了，因为你开始进入那些我在第九部分提到的‘追踪’例程，看看NPC是否试图对被墙壁挡住的人作出反应。这是一个很明显的人工智能问题，但是当涉及到门和窗户时，这个甚至变得更加复杂了。 

　　当你开始为AI刺激例程增加听觉意识时，这依然变得更加复杂了。但是，这个意识是那些关键的“小事情”之一，这些使得假想的游戏世界似乎更加真实，或者能够去除怀疑的悬念。如果你碰到过这样的事情，请举手：你在枪战中跟一个NPC交战，免除了一个NPC，你绕着角落行走并遇到了另外一个NPC依然保持他的缺省行为模式，没有意识到刚刚发生的事情。现在，枪是嘈杂的事物，枪战可能已经明显地提醒了一个“倾听”的NPC有些事情正在进行。避免这种事情的技巧在于找到一个有效的方式来决定声源（即你武器的发射）的距离是否足够接近到NPC能够听见。

　　接下来就是决策例程。当我们的巡逻NPC角色能够听到但不能看见某物时，你试图实现什么样的行为呢？他去寻找它吗？不理睬它？你如何决定什么是重要的声音他应该去或者不去调查？如同你看见的一样，这会很快变得非常的复杂。有很多方法来建造处理这些事情的代码，但通常这样是一个好主意，建立一个不是对特定的NPC而是对所有的NPC都起作用的系统，该系统基于你能够在游戏引擎以外的文本文件中建立的属性。这样就不需要程序员为一个给定的角色而改变AI，并且如果你对游戏代码做了改动，它将立即自动地应用到所有的角色，这在大多数情况下是一件好事情。 

　　其他的世界意识问题会冒出来，比如这样的情形，两个守卫彼此紧挨着站立，你用狙击武器干掉了一个，而另外一个站在哪儿完全不知已经发生的事情。再者，遵守真实世界行为的细节是一款好游戏和一款伟大游戏的之间的区别。 

　　让我们说你已经把所有的刺激-响应部分准备好了—你已经扫描了世界，决定NPC应当对正在进行的一些事情作出反应—他听到了玩家角色发出了声响—并且你（游戏开发者）决定了他应当对这个做些什么—他将去调查。现在更加复杂的事情来了。他如何离开现在的位置，到达他认为发出声音的地方，而不会想通常的数字傻瓜一样跑到墙壁里面，碰到家具呢？继续往下看…

有关正确的路径 --- 世界导航
　　快速，准确的世界导航( 也叫做路径-发现) 近来已经成为游戏开发者的圣杯。 让它看起来非常信服是一件非常困难的事情。你需要有局部世界的地理知识—墙壁的位置，台阶，悬崖和建筑物等的边缘。你也需要世界中的对象的知识—比如家具，汽车，尤其是其他人的位置。真正最后的因素是问题所在，一会儿我们将回到这一点上。 

　　世界导航通常被分为两个领域，世界导航和局部导航。二者实际上只是范围上的区别，但大多数的程序员分别对待它们，因为这样处理起来容易一些。世界导航例程处理理解房间，门和一般的地理学，并计算出让玩家或者角色从世界中的A点到达B点的一条路径。“它将让你从A点到达B点”，这是一句很容易说的话，不是吗？说起来容易，但做起来很困难。理解世界是一个非常复杂问题，我已经看到过许多尝试过的解决办法。QuakeIII的机器人遵照建造的预先处理过的地图，一般的说法，使用原来地图的地面。预处理器检测地面元素，由地图建造者作上标记，并自己建造一个只使用地面的世界简化地图。机器人并不关心墙壁，因为他们从不接近它们，就像他们遵照地面的地图一样，设计上已经把避免墙壁构造在里面了。 

　　其他方法在地图本身里面建造一些小的结点，AI可以追随它们。这些结点通常被建造在彼此的视线里面，有从一个结点到其他所有结点的连接，角色AI能够直接‘看见’，所以你就确保了从一个结点移动到另外一个结点时AI不会试图穿越墙壁。如果有门或者降落物，你能够事先用这些结点对路径的信息编码，于是NPC能够采用适当的行为—等候电梯，打开一扇门，或者从一点跳到另外一点。这实际上是HereticII使用的系统，也是Raven在他们其他的大多数游戏中使用的系统。 

　　关于这个主题，3D Realms的Jess Crable，现在为Duke Nukem Forever工作，如是说： 

　　"导航在许多方面是个巨大的挑战，主要是当游戏中有大量正在发生的事情和一些非计划性的东西，比如障碍。为了避免和（或）真实地对非计划性的障碍物导航（例如像另外的AI），AI需要很好地知道正在它周围发生的事情。比较而言另外一个巨大的挑战就是真实感。如果AI正在表现玩家在实际生活中看到的一些东西，比如说一个人，或者一条狗， 那么让它看上去真实可信就更加困难。"

　　然后就是局部导航。我们可能有一条路径让我们的 NPC 从他在世界中的位置，移动到他认为听到声音的地方，但你不能盲目地按照这个执行并期望得到看起来不错的结果。这种性质的路径倾向于非常特定于一个给定的目的。当你沿着走廊从一个房间跑到另外一个房间时，它很好，但如果你试图指导他穿越一个巨大的房间时，路径结点方法容易最终得到一些看起来很奇怪的发现路径。这些路径也不是动态的。因为他们被预先建造，他们不容易考虑到世界的任何动态变化。桌子可能有被移动过了，椅子被破坏了，墙壁被摧残，当然，人们会移动。这就是局部导航不同于世界导航的地方。它必须考虑局部世界并导航NPC在里面穿越。它必须知道周围的环境，存在哪些可以选择的路径，并决定选择哪一条。 

　　在局部导航中最大的问题是其他的NPC。给定一个发现路径的具体例程，如果你在相同的一般区域中有不止一个NPC，他们都试图到达世界的同一地点，结果是他们都非常容易有相同的路径。然后他们试图沿着这个路径行进，结果彼此遇到一起，然后花费他们所有的时间试图将彼此分开，并且一旦成功地分开了，他们再次试图到达目标，然后我们又再次看到同样的事情发生。这一切看起来都是非常的愚蠢，这不是大多数人想要的效果。所以需要一些路径发现中的变化来避免这种情形，需要一些妥善处理避免的代码。有大量能够帮助解决这种情形的算法。

人工智能和角色动画问题
　　当然，当角色自己在世界中行走时你必须完全地决定你想要角色播放什么动画。听起来无足轻重？不是的。关于这个主题，Raven的 Chris Reed—Soldier of FortuneII使用名为LICH的AI系统的现在的负责人—如是说： 

　　"此刻我能告诉你，我们在平滑移动上正有着最大的困难。在一个多丘陵的长满草的丛林中试图让五个角色在彼此附近行走是一个非常困难的问题。让底层系统完美是重要的，因为除非角色在较低层次上（避免墙壁，适当的动画）看起来真实，他们不能够有效地表达任何较高层次决定的智能。由于这个单独的原因，动画和底层的移动是最重要的和最难实现的。它确实需要完美。"

　　因此我们已经让我们的角色从A点到达了B点，他自己穿越世界，在途中避免障碍物，正确播放动画，现在到达了这里。他看见了你。接下来做什么呢？很明显更多的是作出决策。他将向你射击。太棒了。你回应射击。现在干什么？当他试着逃走的时候，现在你再次经历全部同样的事情。 

　　为了让这些情形看起来令人信服，你看见了这里必须要处理的大量问题。如果你建立你的AI使用没有动画的行为让NPC执行，这能被混合。一些Soldier of Fortune中的AI就是这样的例子。他们受到了指责，因为坏家伙没有以适当的方式对刺激作出反应。当他们明显应该这样做的时候，敌方NPC不扫射，或者不逃跑。部分问题是他们没有扫射敌人NPC的动画，或者让他们往回跑，因为空间的问题。因此世界上所有最伟大的AI代码都不能够解决这个问题。这是所有要考虑的重要事情。 

　　想知道隐藏的难点吗？看看我前面所有的描述，然后试着将它应用到一组NPC上，这些NPC彼此必须说话，设定目标，彼此沟通，但不妨碍彼此的方式。一旦你这么做了，试试那些代码，作为玩家的队友做上面所描述的这些，然而不要在枪战中妨碍他。现在这是复杂的。然后这成为乐趣。这是最困难的部分。Raven的 Chris Reed关于AI‘感觉’的一些评论： 

　　"我认为反馈是AI的一个极大的问题。如果角色对于他周围环境的变化不产生反应，游戏的真实感就被完全打破了。这有许多明显的例子(听见枪炮声，看见同伴被击中...)，以及一些更加微妙的事情(当两个人通过门厅时看着彼此并点头致意)。玩家是乐意接受一些生硬和可预测性的，但是这些事物容易把游戏带到现实生活。"

　　并且Jess Crable 赞同：

　　"平衡是非常重要的… 对玩家将会有多大的乐趣至关重要，但还有其他的问题要平衡。游戏玩家时常说他们想在游戏中看见更加真实的人工智能。然而，太多的真实感开始把乐趣带走。在这两者之间必须要有一个好的平衡。变化和随机同样也很重要—行为的变化，和保持在可信范围内的一定程度的不可预测性。"

游戏规则与自然发生的游戏
　　在我们关于AI的所有描述中，我们采用的是FPS的方式。有不止一种的AI。我们已经描述的是处理3D世界一组规则。AI远远不止这些。时常最好的AI实际上非常的简单。它就是一组规则，玩家必须响应和处理的响应（或开始）动作的规则。 

　　这里应当处理一个被称为“自然发生的游戏”的专业术语。 自然发生的游戏本质上创造游戏将遵守的规则，那将会造成游戏程序员不能预见的情形。 

　　举例来说，象棋能被认为是自然发生的游戏。有一组规则，但游戏能够陷入各种程序员不能够以个别方式处理的情形。你不能为每一种可能的棋局情形编码规则。很清楚，游戏玩家每次不会总是面临相同的游戏情景。一定程度上，进行中的游戏情形会根据他的行动而发生变化。Black and White是这种情形的一个完美的例子，和The Sims一样—游戏有它自己的规则，但你如何运用和调和他们是你自己的事情。实际上，你在玩游戏的过程中创造着游戏，而不是照着游戏设计者/程序员已经为你定义的路线进行。 

　　有可能把基于规则的，自然发生的游戏方式和FPS环境混合在一起。Half Life中的一些海军陆战队士兵的行为就是这样做的—压制火力和侧翼攻击从设定的规则中动态完成。它看起来是动态的，而且一定程度上它是这样。然而，在FPS世界中仅仅有一组规则时常是不够的。几何和其他AI时常能够打败简单的规则，这让保持正确并依然有趣变得更加困难。所以对那些可怜的AI程序员有一些同情心吧。他们的工作不容易。 

　　好吧，下面还有一个章节，仅仅还剩下一个章节了。在最后的章节里，我们将讨论头顶显示，菜单系统，游戏定制和配置，游戏引擎版权与建造，最后是游戏“mods”。 


第11部份: 最后的章节

 

前端
　　你已经看到了菜单系统，你可能理解游戏内的头顶显示（HUDs）时常是游戏经历中被忽视和诽谤的部分。最近，这个领域开始被给人印象非常深刻的Black and White所关注，这款游戏实际上没有HUD。在Peter Molyneux经历了Dungeon Keeper以后，它在屏幕上大量的图标，他决定游戏的大部分被这些图标占用了，主要的屏幕没有被足够利用。因此他决定废除所有这些东西。Peter迈了大胆的一步，我们为你喝彩。很不幸，这种方式适用于B&W这类风格的游戏，但它并不总是对其他种类的游戏有用。 

　　大体而言HUDs应该是不引人注意的，只提供你需要的关键信息；这本身会在设计团队中引发争议。Soldier of Fortune的最初设计在屏幕上有一个图标，当被击中时向你准确显示身体的哪个部位被击中。当他们决定他们不准备为不同身体部位的伤害而处罚玩家时，最后这个被丢弃了。在一些早期的Soldier of Fortune的屏幕截图上，依然能够在屏幕的右上角看见这个图标。 

　　在一个完美的世界中HUD是可配置的，因此你能决定显示什么，在哪里显示，显示多久。如果你觉得不需要局部雷达，那么它应当可以被移除掉。任何显示的HUD信息应当有一定程度的alpha（透明度），因此如果需要你能透过它们看见后面的事物。 

　　说到配置，我是一个游戏个人设定的十足的狂热者。因为没有即时存储设备存储配置文件，在游戏机游戏上不是广泛地可以获得配置，这足够公平。但是随着PS2和Xbox硬盘驱动器的来临，我期待在将来看见配置被更多地使用。能够被定制的每件事物都应当这样，如同我看见的一样。很明显，也应当为每件事物提供合理的缺省配置，因此玩家不必一屏一屏地进行枯燥的选择过程---一会儿我们将更多地讨论这个---玩家应当能够根据个人的喜好和可获得的计算能力定制游戏经历。 

　　回到缺省事物，保持必需的修改最小化非常重要。作出最少的决定而快速进入游戏总是一件好事情。Mortal Kombat，甚至QuakeIII都有一个非常快速的游戏进入系统。少许选择，然后你就进入游戏了。这并不意味着你不能有一个接一个的菜单允许你改变每件事物，但它们不应当是必需的且应当已经有合理的缺省设置了。如果甚至在你进入游戏以前你必须用14个屏幕设置一个角色，可能是第一次你可能没有关于你正在选择的线索而且仅仅会做任何事情以通过屏幕，可能做了一些会极大影响初始游戏体验的事情。而且有可能它将会是不利的影响，作为一个游戏程序员/设计者，我在这里告诉你无论你做任何事情，让玩家第一次选择一些愚蠢的事物，无需让它更糟糕你就会有足够的机会制造很差的第一印象。 

　　藉由关于配置和HUDs（连同前面十个章节的大量信息）的简要论述，我们最终结束了关于现代游戏引擎的主要建造元素的讨论。当然，依赖于游戏的类型和谁在制作它们，每个特定的游戏对这个清单有它自己的添加（或者减少）。然而，有一些对于游戏引擎实际上不是引擎设计部分的其他元素，但是它们却需要一些关注。

游戏引擎许可与组件
　　如今如果你要制作一款游戏，时常最快的开始方式就是购买现有的游戏引擎许可证并在此基础上开发---这就是Raven所做的事情，最近使用Quake3引擎编写了Star Trek Elite Force。Half Life基于Quake 1引擎，Deus Ex基于Unreal，这个清单还在继续。如今有两种许可证方式---一个完全的游戏引擎（或游戏操作系统如Jason Hall授予LithTech），或者一组给定问题的部分解决方案。这方面一个好的例子会是RenderWare，这是一个渲染场景的部分解决方案并给你提供一些物理。你不能仅仅拍着一些模型并把它们称为完成了的游戏---还需要有声音系统，游戏机制，等等。但它确实给了你一个建立游戏的坚实基础。还记得我在渲染和物理学章节提到的所有数学知识吗？很好，这样你就避免了所有那些东西。 

　　藉由LithTech，Unreal和Quake，你确实得到了完全的解决方案 -- 或至少是创始者为他们的游戏所需要的全部解决方案。记住QuakeIII是可以多人玩的，不时建立在单人游戏的基础之上的比如说Unreal Tournament。使用QuakeIII，你失去了单人游戏需用的某些系统，像读取/存储，脚本等等。你只是的到了Id公司制作一款游戏需要的东西，而不一定就是你所需要的东西。有时侯如果系统的一个局限恰好是你所需要的东西时，这可能是一个真正的缺点。给Star Trek Voyager加入读取/存储和脚本：Elite Force不是野餐，但是必须的。然而，使用Quake3引擎依然是领先的开端。

　　Unreal有名的Tim Sweeney 对于今天一些流行的预先打包的游戏引擎解决方案有一些评论。

　　"我认为我能公平地比较游戏引擎 (Quake，Unreal等) 和游戏组件如 RenderWare 和 Karma。游戏引擎是包含游戏开发的所有技术方面的组织严密的框架：渲染，编辑工具，物理学，人工智能，网络，等等。

　　它们针对那些想要一个完全的，现成的解决方案的开发者，以便他们能够把精力集中在游戏可玩性和内容上。像RenderWare这样的游戏组件针对那些正在开发他们自己的技术但不想在一些已经很完善的技术领域做重复开发的开发者。 

　　游戏引擎有解决游戏开发中全部技术问题的优点，有容易把一些包括游戏类型的假设建立在里面的缺点。举例来说，Unreal已经被用来制作第一人称射击游戏，第三人称动作游戏，角色扮演游戏，甚至弹球游戏。但是没有人用它制作飞行模拟类游戏—它不是适合这种游戏的技术。游戏引擎带着完整的源代码而来，这是祝福 ( 你能完全看见内部正在发生什么，你可以自由地根据你的需要扩充它)，也是诅咒 (如果你改变它，你将必须把变化合并进新的版本之内)。

　　游戏组件有解决所关注领域的技术问题的优点，如渲染或者物理学，不用花费大量的时间在这方面就可以比典型的开发者做得更好。他们的缺点是把这些组件整合进你的引擎其余部分就是你自己的事情了，这有时候会相当复杂。游戏组件一般没有完整的源代码伴随，因此并不总是很清楚他们内部做了些什么。" 

　　谢谢Tim，很精妙的分析。

建立你自己的游戏引擎?
　　你可能建立自己的引擎而不是购买许可证。这避免了谁拥有什么，版税等所有的法律纠纷，而且如果你产出了质量足够好的东西，你甚至能够向别人出售许可证。然而，正如已经指出的那样，这需要时间和金钱来完成，更不用说绝对优秀的程序员了。LithTech 已经发展了很多年，与Unreal类似。很有趣，主要是因为变化的硬件和API版本，实际上Unreal最初的版本花费了四年时间才完成。当他们刚开始的时候，软件渲染是唯一的游戏。当开发正在继续的时候，3dfx带来了Glide，然后是Nvidia的TNT显卡（从那时起硬件和APIs确实有了更多的进步）。这就是它为何支持这么多不同的渲染途径的原因。当然在一个相同的引擎内支持所有这些是一场编码恶梦，但那是另外的事。每个引擎有模块化的方式， 并且当一个模块---比如说，脚本---变得过时了或者需求变化了，你只需要把它抽出来并开始做一个新的模块。

　　Quake引擎经历时间有更加完整的进化发展。相应于Id公司下一个游戏的一组需求，当John Carmack创造了在当时的硬件上运行最快的东西时，引擎的每个版本都经过了完全的重写。QuakeII完全重写了不少于四次，我个人看到了QuakeIII的机器人代码的三个不同的版本。其他的开发者也没有能够避免这种情形。John Scott，建造了Soldier of Fortune II的地表系统，曾对我提到，在动态地表生成上他曾尝试了许多方法让物理学正确地工作。 

　　建造技术或者完整的引擎不是件容易的事情。当今的游戏引擎需要许多，许多的系统，就如同许多人们尝试创造‘下一个大的引擎’时所发现的那样，从屏幕上文本的简单显示到高级人工智能。并且如我前面提到的，不断发展的新技术使得建造一个快速，高效的引擎是一个变化的目标。事实上，我见到有人仅仅为了让一个带alpha的纹理正确地显示而在PS2的混合模式上花了四天时间。

　　值得考虑的其他引擎有Garage Games的Tribes 2引擎---被称为The Torque Game Engine。我的理解是它可以收取微小数量的许可费用，将来有一些版税协议。这是的确值得考虑的事情。你可以在这里看到这个引擎的特征细节http://www.garagegames.com/index.php?sec=mg&;mod=v12&page=features 。 然后就是Serious Sam 引擎。这也是需要许可证的，的确值得看一看。如果你对它有兴趣的话，可以联系God Games---他们应当可以给你指明正确的方向。 

　　在网络上有一些你可以下载的自由引擎---首先想到的是Crystal Space引擎。你可以从这里下载http://sourceforge.net/projects/crystal ;，并在你的游戏中随意使用。这不是一个专业的引擎，但看看所有的部分如何结合在一起时常是一个好的学习经历。

　　还有就是最初的Quake Engine，现在已经被Id公司开放源代码。对于任何有抱负的游戏程序员来说这是一个很好的开端----下载它，编译，开始调整。值得记住的是，这个擎是许多年以前的了，与Quake III或者新的Doom没有多少相似性。重复一遍，它确实是个好的开始。你能从这里找到发现好的资源网页http://www.inside3d.com/qip/home.shtml ;。

　　确实，这一切都是时间与金钱的事情。如果你没有时间开发一个新的引擎，就不要介意花钱使用第三方的引擎，去购买一个吧。注意，对于要求使用他们引擎的团队，如今大多数引擎许可团体有很合理的途径。尽可能地让许多人们使用他们的技术，因此这种经验变成了工业标准，这对他们有好处。

‘Mod’社区
　　看一眼任何在线游戏服务器的统计数字，显示出Counter Strike服务器比任何其他游戏服务器都要多。和它最近的竞争者（Quake III或者Unreal Tournament）相比，几乎有两倍的CS服务器。 

　　游戏 mods 全部来自于一些编辑程序，这些程序让游戏者能够修改DOOM最初的.WAD文件，提供他们自己自家制造的关卡设计和纹理。人们开始玩这些(大致)自家建造的工具，并且也发现了他们可以产生其他人想玩的关卡。Id注意了这个趋势，而且将Quake系列引擎带到了一个新的阶段，这样设计游戏，使得游戏是用户可修改的。他们甚至发布他们自己的设计工具，指令，而且甚至---喘口气---游戏中的代码，如此有抱负的游戏程序员可以在Quake Universe中玩。你可能从这个创造出自己版本的Quake连线经历。许多今天的业内大师来自这种早期的修改经验。现在有名的设计者如LevelLord和CliffyB在这个行业中就是这样开始的。最高的荣誉来自一位名叫ZOID的绅士，他提出了3Wave CTF，第一个‘夺取旗帜’的游戏，游戏中需要人们组队---连线游戏从纯粹的死亡竞赛以来的第一次进化发展。 

　　一些游戏是如此的流行以致于他们每年都有事件发生。比如说，Quake有一个QuakeCon，在Mesquite Texas，Id软件公司所在地，举行的一年一次的quake大会。人们带着他们的PC来到这里，或为了看最新的mods或是展示的基于Quake引擎的游戏。 

　　如今你制作的任何游戏需要或者有杀人者可多人玩的经验，或者有可以非常容易修改的内容这样连线‘修改者’能利用你的游戏并制作出其他游戏来。这一切延长了你游戏的生命，有希望卖出更多，人们购买它，可以下载mods来玩最新的Quake III修改版本：The Teachers Strike Back。但你不能仅仅生产一款游戏，发布你的工具，就袖手旁观。实际上你最初必须把代码设计成不需要程序员就可以容易地扩充, …好吧, … John Carmack。

　　作为一个开发者，你需要在那里可以见得到，并为那些在家中想利用你的游戏和用它做点别的什么的人们提供经验和帮助。这种支持可以有许多形式----一个亲切友好的词语，一段代码，建议，宣传或只是金钱。只要有这个它时常不介意采用何种形式。 

　　在这里你选择哪个第三方工具用来建造内容可能是至关重要的。在Raven，过去我们已经做了一些开发决定，在这方面没有什么帮助，由于我们为大多数的建模和所有的动画需求使用了SoftImage。虽然它是制作我们需要的动画的最好工具，对于家庭业余爱好者来说它太过昂贵了。这就给那些家庭业余爱好者在扩充我们制作的内容时带来了问题，因此他们容易抛弃我们转而寻求那些比较容易制作内容的游戏。在建造或者选择一个引擎时这确实是值得留意的事情。为了响应制作游戏mods，Discreet在市场上发布了一个3D Studio Max的‘lite’版本，称为gmax。最好的是，它是免费的。如果你想要试一试，你能从这里抓取它http://www.discreet.com/products/gmax/gmaxconsumer/index.html ;。

　　最后在线游戏的成功时常能追踪到 mod 社区，因此我认为感谢他们做了件好的工作是公平的。我过去时常说，在行业中到达一个‘真正的’工作最快的方式是从一个mod开始，说明你有完成它的训练并用它作为一个面试获得者。不能说，"我能做这个" 就像已经完成了一样。因此去到那里并开始吧。你损失什么了吗？

有关作者
　　Jake Simpson 是一个游戏程序员，断断续续在这个行业已经有大约20 年了。他在英国本土从15岁开始，在C64的时代，Sinclair Spectrums和 BBC Micros，经历了 Amiga 和ST，离开了一段时间，然后90年代中期至后期在Mideay Games写街机游戏。他最近在Raven Software工作过，制作有Soldier of Fortune， Heretic， Hexen， Star Trek : Voyager : Elite force 和 Jedi Knight II : Outcast，在北加州的Maxis可以找到他，为Will Wright的游戏产品工作。业余时间他为GameBoy Color和Advance编写代码，因为“你能尽可能地远离C++编码，而且，如同John Carmack所说，底层编程对程序员的灵魂有好处”。

(全文完)