插件和目的建造工具
通常大多数的游戏开发过程最终都是这样的混合，自己开发的文件转换器工具，现成的内容创造工具，和通常那些要增加一些必须的特殊功能的工具的一些附加插件。现成工具在提供你不可避免会需要的功能方面有很长一段时间了，但是正如不可避免，总有一些很有用的，有帮助的，或者完全必须的东西你不能得到。一个小的插件可能是一个很好的替代品，而且时常那就是所走过的路。为特定目的建造的预处理程序也是可用的，比如把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点，他自己穿越世界，在途中避免障碍物，正确播放动画，现在到达了这里。他看见了你。接下来做什么呢？很明显更多的是作出决策。