如同在第1章中所提到的那样，我们设计的脚本编程系统应该能够充分实现它所应具备的所有功能，不过，我们也不应该过于求全责备。因此，了解各种脚本编程系统分别能够完成什么工作以及它们各自常见的应用领域，对于你成为一名脚本编程高手而言也是非常必要的。

因此，本章将主要负责帮助读者熟悉脚本是如何应用到现实的游戏工程中的。通过了解你所学知识是如何真正被应用到实际工程中的方法通常就是巩固你所学知识的最好方法，因此，但愿本章所列举的材料能够很好地帮助读者理解第1章中所学习的内容。其实，有关游戏脚本的内容在前面已经有所涉及：第1章中虚拟的RPG工程通过实例向读者演示了脚本是如何简化游戏设计的，这些处理原本会需要很多方面的内容。本章将通过一些更加详细直接的内容来帮助读者了解脚本编程，从而使读者所了解的内容并不仅仅只局限于角色扮演游戏（role-playing games）。为了保证这些游戏脚本应用实例的多样性，本章也将简单地涉及到其他完全不同的游戏类别，以及另外一个在游戏界中获得同样关注的游  戏——第一人称射击游戏（the First-Person Shooter）。

此外，我还要顺便提一下，如果你是抱着将你所学知识应用到现有工程中的单纯目的来学习本书的话，或许你已经清楚地知道你需要建立一套脚本系统，并且能感觉到你应该能够掌握它的背景知识。然而，姑且不管你的技术水平和你的学习目的是什么，我都建议你暂时不要考虑这些问题。这不仅是因为本章将要涉及到一些基础的、几乎是非技术性的内容，而且它还在为后面的章节打基础。本章所介绍的概念将会贯穿本书的其余部分，因此，毫无疑问，理解这些概念非常重要。下面就开始来学习本章内容。本章将介绍脚本系统是如何用于解决下列问题的：

  ●       RPG游戏中与内容相关的部分——非玩家角色和场景细节。

  ●       RPG游戏中的物品、武器和敌人。

  ●       第一人称射击游戏中的物品、迷题和机关。

  ●       第一人称射击游戏中敌人的行为。

2.1  编写脚本的普遍目的

就如同在第1章中解释的那样，实现脚本编程系统的最根本原因就是要避免硬编码。如果将游戏内容和游戏引擎相分离，你就可以在不需要重复编译整个工程的情况下调整、测试和修改游戏运行的机制和特性。它也同时使得游戏在编译、打包和封装以后还能够很容易地进行扩展，如图2.1所示，游戏逻辑也可以被视为模块化内容，允许它像图形和声音一样灵活和可交互。

所有的修改和扩展部分都可以被玩家下载并能够快速地被游戏所识别。有了这样一套系统，你的游戏就可以无限制地进行扩展了（当然，只要人们能够编写出新的脚本和内容）。

因为游戏引擎和游戏内容的完全分离，使得在没有一行具体游戏代码的情况下游戏引擎仍然是可以编译运行的，因此，游戏玩家使用的真正的游戏完全可以由脚本和其他一些媒体，如声音和图形组成。这就意味着当游戏玩家购买游戏软件的时候，他们实际购买了两个分离的部分：一个编译过的游戏引擎和一系列可以对游戏功能进行扩展的脚本。因为这种模块化结构（modular architecture）的出现，全新的游戏如sequels和spinoffs就可以只以脚本的形式发布并且可以在无须修改玩家已经拥有的游戏引擎的情况下运行。

图2.1  游戏内容和游戏引擎分离

这种方法的一种常见应用就是以“情节（episode）”的形式发布游戏。这就意味着游戏软件店在销售游戏软件的时候只出售25%左右的游戏内容，以及可以在上面运行游戏的游戏引擎。当游戏玩家完成了第一个游戏情节的时候，他们就可以以较少的费用下载或者购买另外的如patches和add-ons样式的游戏情节。这就允许游戏玩家在完全购买整个游戏之前就可以尝试玩这个游戏，同时也使得在游戏玩家需要的情况下，游戏开发者可以发布新的游戏情节。游戏开发者就可以不需要花费数百万美元设计和编写一个全新的游戏引擎并为游戏设计一个完整的结局。其余的情节也完全可以在基于脚本和现有引擎的基础上只使用上面所花费用的一部分来设计完成，并且同时使游戏玩家玩得更加开心。

如果你了解这一点的话，脚本似乎适用于所有类型的游戏。不要因为第1章中的例子使得你误以为只有RPG游戏才需要使用这种技术。几乎是所有的游戏都可以从脚本中获利，即便是复制过来的PacMan，通过给不同颜色的幽灵分别指派不同的脚本来控制它们的动作也会使得它们具有各自独特的智能。所以，我想使你牢记的第一件事就是这些东西是多么灵活和应用广泛。总体来说，通过将脚本系统一定程度上引入到游戏当中可以使得各种类型和种类的游戏组织和编写得更好。

所以，为了使得我们的起点更为扎实，我们仍然从分析RPG游戏开始来学习编写脚本。毫无疑问，这次我将会讨论更多的细节问题，至少带你进入到一些更加熟悉的领域。