游戏引擎剖析（八）

原文作者：Jake Simpson
译者： 向海


第8部份: 脚本系统


脚本系统
　　我们从第七部分的游戏网络问题来到了脚本系统，因为其呈现的故事叙述机会，最近已经形成一种很大的游戏元素。在一个需要以受控制的方式解释的情景，预先编制的电影脚本是解决问题的方法。在电影中，这通常用来处理或者由主角向一个伙伴解释情形，或者敌人对英雄解释。当然，有其它的方法来做这件事情 -- 叙事者，倒叙，等等 – 但通常是使用实时情景的人们和事件来完成。当然，游戏是不同的，游戏开发者在他们平常的FPS中不应该做太多的倒叙，因为通常会需要载入新的环境或者关卡，以及新的纹理和/或模型。所有这些额外的处理和渲染能影响到主要的游戏序列的性能。你可以重用已经存储在内存里面的场景元素来倒叙，但那样会看上去明显比较粗陋。

　　RavenSoft 的Star Trek Voyager: Elite Force广泛利用了脚本序列产生游戏中的事件和使用游戏引擎本身的剪辑场景。

　　在游戏中设计脚本情节的一个有趣趋势是使用当前极大改进了的3D游戏引擎自己产生剪辑场景。现在这可能像是相当地明显，但是数年以前，当 3D 图形卡还比较简单的时候，剪辑场景通常使用高端3D工作站制作，得到的3D动画然后被记录为一个数字视频文件，以流式文件存储在CD-ROM。你从剪辑场景的漂亮图形画面回到真实游戏的相对粗陋的3D画面，这是相当令人不愉快的失望的事情。但像Half-Life 和 Star Trek Voyager : Elite Force这样的游戏很好地利用了它们自己的引擎产生所有的剪辑场景，结果是剪辑场景和游戏之间的过渡更加平滑。

　　把脚本和人工智能区分开来可能是个很好的主意。脚本是你完全控制着一个给定场景，建立玩家几乎总是没有控制的事件，游戏者‘沿着轨道’移动到一个给定地点，或者建立一个游戏玩家需要解决的情形。一个好的例子可能是巨石掉在走廊上，需要游戏玩家找到一个新的逃脱方法。

　　如今有一些不同类型的脚本系统可供程序员或者美术师使用，而且它用非常有条理和逻辑的思想恰当地做这些。第一种是简单的基于文本的，单线索的风格，就像我们程序员习惯的编码。在许多情况，它实际上基於 C，尽管以一种非常简单的形式。 大量这种类似“if this，then do that”的东西。大部分脚本倾向在范围内是相当线性的—意味着它通常由许多在次序上彼此相接的命令组成。在世界中移动角色A指向B。当完成以后，让他讲话，完成以后，移动他指向C。相当简单的事情。

　　然后有复杂的东西--允许多重线索，和实际上允许可变情形。可变情形是当脚本开始时你实际上不能确知谁会出现在附近，但是你必须按这样的方式编写脚本以便任何人出现在附近它都将会工作。举例来说--一个正常的简单脚本会有三个家伙，全部被预先定义，全部有一组他们将会讨论的情形。一个可变的脚本将会有三个人,你不能保证是某一个特定的人，并必须按相同的方式工作。或者在一个极端的情形中，也许只有二个，或者甚至一个家伙将会在那里，使得三方交谈有一点困难。

　　Raven在Star Trek Voyager: Elite Force中面临的一个很大的问题是这样的情形，使用者可能会想要把一个角色从一条船的某个地方带到另外一个地方，但是从A点到B点的路径可能会随着每次游戏根本地改变。举例来说，他们需要让Munro(你所扮演的游戏主要角色)从发动机舱室到输送舱。 不幸的是由于游戏的非直线性，在事件到达这一点以前你可能已经破坏了涡轮升降机，或者也许 Jeffries 管被损害不能通过。假定当脚本开始的时候我们不知道世界的状态，我们不得不为几乎各种可能发生的事情编写脚本以便适用于这些‘如果。。。怎么办’的情形。而且它仅仅从那里变得更加糟糕。我们能建立的一些情形提供了如此多可能的组合情形，以致于为了一个满意的结论而准确测试每一个可能发生的事情几乎是不可能的。请和在SiN, Star Trek Voyager : Elite Force or Deus Ex中工作的任何人谈谈。QA部门传统地憎恨这些类型游戏，因为这已经使他们的工作比以前更加困难了 50 倍。

　　你能够想象为这些情形编写脚本是何等的困难。但那是今天的非线性游戏路径要求的事情，而且它为何博得了较多的开发支持从而能够努力实现它。


Jim Dose关于脚本系统的论述
　　去年底我访谈了Jim Dose--Ritual的前任开发者，现在是Id Software的一个开发者，Doom3脚本系统（和其他一些事情）的设计者。尽管这次访谈有些久了，但仍然是很有洞察力。

　　Jim谈了脚本系统和创建一个易用且健壮的系统( 与包含设计者传统想要使用的所有特征相反):

　　设计一个脚本系统最难的部份是知道何时该停止。一旦你完成了并开始运行，你发现有许多能够利用它的系统。对于Sin，最初的主意只是要有一个比较容易的方法让关卡设计者描述对象怎样动态的在环境中移动。在项目的后期，我们也使用它来让声音和游戏事件与动画同步，在多个关卡跟踪任务目标，控制HUD的布局和游戏内部电脑控制台用户接口，描述人工智能如何对不同的情形产生反应，以及粒子系统。

　　控制复杂度可能也是相当的困难。当你把脚本的力量放进有创造力的人们手中时，他们开始探究他们所能做的界限。时常，他们受启发做一些刚好轻微超出系统能力范围的事情。很容易陷入到这种增加‘仅仅再多一个特征’就允许他们做他们想做的事情之中。随着语言增长，一个可能对最初的规格有意义的语言结构变得严重过度扩充了。在一些时候，重新思考系统变得有意义，但在那时，你可能已经积累了数量巨大的必须重新编写的脚本。和FAKK2一样，Sin遭受了这样的损失。我没有得到对脚本系统进行大规模彻底检查的机会直到我为Rogue's 'Alice'.重写了脚本系统。

　　阿们，吉姆。-- Raven已经看到这个恰好在他们的ICARUS系统中出现了。ICARUS 实际上是一种与Jim在上面描述的相同种类的脚本系统，而且负责在Star Trek: Voyager: Elite Force中的所有脚本事件。它在Soldier of Fortune II和Jedi Knight II : Outcast中被重复使用。为了解决系统需要处理的新问题，这些问题在最初的实现中没有被预见/不需要，脚本系统的很多部分已经被重新编写了。


可视化脚本系统
　　第二种类型的脚本是可视化脚本系统。使用这种方法，而不是文本文件的编码方式，实际上你能够在真实的游戏环境中使用真实的角色建立你的脚本。你能够追踪角色在世界中行走的路径，定义使用的动画，并且通常得到关于你的脚本实际上将看起来如何的更好的主意。它对我们已经讨论的非线性问题没有太大的真正的帮助，但它确实可以很快速地生成最初的脚本。

　　其次，Jim谈论了可视化脚本系统。

　　可视化脚本系统确实有它们的用处，但往往实现更加困难，如果设计得很差，当复杂度上升时就容易让开发者感到困惑。举例来说，人工智能可以用一个流程图似的结构来进行可视化的设计。你能非常容易地可视化地表现人的行为举止方式，用盒子代表状态，箭头代表转化到其它状态，指示角色能够从一个状态转换到另外一个状态的方式。

　　脚本的一种通常使用是在游戏世界中控制物体，指示他们他们如何在世界中移动。在一个编辑器中可视化地移动物体到关键位置并播放整个运动的能力对一个设计者可能会更加直观。然而，它确实有它的极限，因为将需要另外一个接口来设计物体在它的移动中必须作出的任何决定。那种能力是把脚本动画片断和类似3DS Max或者Maya 这样的程序产生的动画区分开来。

　　在一些时候，使用者可能需要一些方法决定一个脚本为何没有做他们所期望的事情。一些形式的除错工具能使这件工作非常容易。至少，决定哪些脚本正在运行和脚本当前位置的一些方法必需的。在脚本中检查变量，开始，停止，和单步执行的能力也是有帮助的。通常，一个程序师能够在他们的调试器中进行除错，但这个过程要比如果有一些内建的脚本调试器可用时花费的时间更长。


　　以上就是第8部份，在接下来的章节中我们将讨论使用现成产品和定制的游戏引擎设计工具的功过得失，然后探究游戏控制机制，开发游戏对象，和一些刺激有趣的事情 (武器系统)。