前言
一款游戏如果可以让玩家对其人工智能引擎进行修改和拓展，那么能极大丰富游戏的内容。然而，玩家并非开发人员，而且你也不应该强迫他们去学习一种虚构的编程语言，甚至对其结果进行调试。如果你想要自己游戏中平均程度的玩家能改造游戏，那么简洁性是一个关键的因素，而通过实现一个可扩展的触发器系统，就能达到此目标了。
触发器系统简介
触发器系统时专门做某件事情的一段集中的代码：它将对各个条件进行检验，继而执行相应的事件响应。如果有一组条件满足了，那么对应的一组反应就会被执行。这个简单的系统结构优秀、易于实现，而且很容易对之使用数据驱动的方法。它可以用来解决各种不同的问题，尤其适合让设计人员（比如策划）和玩家进行修改。最棒的一点是，有了它以后，我们就可以更容易地创建一个好玩的、崭新的、交互式的环境让玩家来探险了。
对象自有的触发器系统
我们可以考虑为每个代理、对象或任务加上一个其自有的触发器系统类。并不要求每个对象都有这么一个系统，不过如果能有这么一个触发器系统的实例的话，对象就可以把自己的数据封装在内部，这样可以使得系统更加灵活，更加面向对象。另外，也可以给特定的物体加上触发器。
定义条件
条件可以是任何一个你在游戏中进行量化地事件或是状态。条件在可执行文件里面是固定的，但是可以对之使用参数或是关卡编辑器进行高度自由的配置。下面列出一些可能的条件：
一个敌人逼近了玩家；
玩家的生命值低于x%；
玩家被杀；
玩家与人物X对话；
玩家离点（x,y,z）的距离在R之内；
玩家装备了对象X；
玩家收到了X消息；
玩家的背包里有对象X。
使用布尔逻辑组合条件
为了得到更加灵活的条件限制，我们最好使用布尔操作符，如AND、OR、NOT，或是XOR，将条件关联起来。例如下图组合：
定义响应
响应可以是游戏中的任何一个你想改变的状态或是动作。这些也是执行文件中设置好的，但是它们可以使用参数或是关卡编辑器对之进行定制。下面列出了一些可能的响应：
关卡/任务结束了；
开门、关门、锁门、打开门锁；
播放音效；
使玩家/敌人X进入无敌状态；
把玩家或是敌人X移动到位置（x,y,z）处；
产生X个Y类型的生物；
杀死X个生物。
如果某组特定的条件得到了满足，相应的响应就会被执行了。不过，我们可以对其进行扩展，以让其响应包含一组响应。使用该方法后，当条件被触发后，它可以同时对多个事件造成影响，或是随机选择其中一个进行响应了。
求取触发器的值
当我们通过条件定义了一个触发器以后，我们还需要一个框架取得其值以得知何时应该触发这个触发器。第一个需要考虑的地方就是要决定一个特定条件应该是事件驱动的（触发器系统将等待得到一个事件通知），还是应该对世界进行轮询。实际环境中，你会希望有比较大的灵活性，可以随意选择创建世界驱动或是轮询模式的条件，如果能把这两个模式都加入进来那就最好了。
对于事件驱动条件，我们需要一个接口以让事件能进入此触发器系统。最简单的方法就是使用事件消息。事件消息只是一个简单的通知以通报某个事件发生了，另外此消息还携带了相关的数据。
对于轮询类型的条件，我们可以在触发器系统内部调用一个更新函数以便让每个轮询条件自己去完成相应的工作。而事件驱动的条件则会忽略这个函数调用。
不管在触发器系统中进入了一条事件消息或是进行了一个轮询更新函数调用，我们都需要采用一个方法将其与整个条件判断关联上。
在使用事件驱动的条件时一定要注意它们必须得记住其事件，一直到被重置为止。在某一个点上，为此特定触发器设置的条件都返回适当地值，使得触发器被触发。当一个触发器被触发时，它会记住这一点，以后不会再被重复触发。
一次性触发与载入次数
所有触发器都应该有两个额外的由设计人员定义的属性：
bool SingleShot; //此触发器是否只应该被触发一次
float ReloadTime; //如果可以触发多次，那么需要多久才能被重置 这两个属性可以使得一个触发器被多次触发。SingleShot属性决定了此触发器是否应该只触发一次还是可以触发多次。如果SingleShot是“false”，那么ReloadTime就决定了在触发器重置其所有条件和再次接受条件之前所需要的时间。
使用标志和计数器将触发器结合起来
只有当一个触发器能够到达某些中间状态，而且这些状态可以为此系统中的其他触发器所能访问到的时候，这些触发器才能结合起来。因此，每个触发器系统都在其内含有一组标志和计数器以用于跟踪那些被触发的触发器。为了得到一个尽可能通用的结果，我们可以让每个触发器创建任意的标志，通过字符串来访问它们。触发器系统将会在一个标志需要被访问或是被设置的时候创建它，然后将其保留下来一直到系统被销毁。
通过这些标志和计数器，我们就可以在触发器系统中做下标记或是对事件进行计数。
加入标志和计数器之后，现在的触发器系统变成了一个非常类似黑板系统的东西。标志和计数器构成了黑板，而触发器则是知识源，它们对黑板数据进行操作。然而，由于触发器主要是与黑板外界来的数据打交道，因此一般来说，触发器系统并不是一个黑板系统。
触发器系统与脚本语言的对比
触发器系统的功能在加上状态信息后，越来越像脚本语言的功能了。以下是使用触发器系统的优点：
触发器系统能在GUI界面里面完全定制。
脚本语言极少能够提供如此简单和健壮的编辑特性。而且不必担心什么语法错误，因为触发器已经定好了针对条件与响应的结构。
触发器系统对用户而言更方便。
触发器的概念很容易理解，而且会有更多人去使用它。
触发器系统是有边界限制。
由于触发器系统已经做了很好的限制，因此用户操作一般不会导致游戏的崩溃。这是因为触发器只会执行一组在很小范围内的、经过良好测试的、仅限于有限几种的动作（响应）。
触发器系统在实现和修改方面都很快。
实现触发器系统相比使用完整的脚本语言得到实现来说只需要很短的一部分时间。如果触发器系统需要几个星期来实现，那么脚本语言则需要几个月甚至几年才能实现。
对触发器系统来说，其文档记录工作比较容易。
相对而言，一个触发器系统在编写文档和例子方面比较容易。这是因为如果你想在游戏发布了以后，用户能自己改造关卡，那么这份东西你总要写的。
局限性
此处描述的系统的主要局限性就是扩展不够好。不过，我们可以添加一些额外的代码来去除无关的触发器。其中相邻裁剪被证明是一个相当有效地方法。
此系统的另一个局限性在于定义条件和响应的词汇在执行文件中已经被固定死了。因此，如果想要进入代码内部需要开发人员进行特意的改动。这也是一件好事，因为它能帮助你保护自己的游戏以防止随机的，或是恶意的改造行为。
结论
对于很多开发进度紧张的游戏来说，有一个可扩展的触发器系统的开发可能不太现实，但是它确实是一个有用的特性，可以为你的游戏增值并增加其深度。此外，有了可扩展的触发器系统，关卡设计人员就不用非得称为熟悉的开发者才能设计情节了。虽然看上去触发器系统的解决方案好像太简单了，但是我们的目标是要让设计人员和玩家能够使用它。如果越容易设计内容和关卡相关的情节，那么你的游戏也就越大，你的玩家也就会越高兴。
个人观点
通过本文学习，我们应该可以了解一些简单游戏编辑器的制作想法。通过触发式系统，开发员可以制作一个个“轮子”，只要再加上一些可视化的“特技”，就能将这一个个“轮子”变成丰富的各类组件，非专业人员就能组装这些组件更轻松的加入实际游戏开发中。虽然真正的一个游戏编辑器不仅仅这么简单，但触发式系统帮我们打开了编辑器制作的大门。如果你开发的是一款中小型游戏，并想将更多的游戏内容交由玩家来创作，单独开发的一个触发式系统完全能够胜任这项工作。虽然触发式系统可能会耗费相对比较久的时间，一旦完成你的“纺织机”，游戏的小型“创意工坊”就可以正式开始运转了！
学习资源
-
- 《游戏编程精粹3》第三章第五节
2668
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
