游戏框架设计基础流程

      事事互相联系才能构成一个整体，因此事件机制是在游戏中普遍存在的，是游戏构成不可或缺的。下面我们先来了解下什么是事件机制。

　　事件机制在很多高级程序设计语言中都有支持。譬如VB、C#（delegate）、C++Builder（并不属于C++的范畴。C++Builder中的事件处理器必须用关键字closure<闭包>修饰）等等，甚至在html中也可以见到它的身影。事件机制的引入使软件系统变得更加易于理解——它使一种语言（平台）更加接近于这个世界的真相。事情的发展变得像现实世界中那样顺理成章。某一事件的产生引发了一系列其他事件的产生，这些事件要么是结果要么又会引发一系列事件的产生……如此这般，信息才得以在事件的新陈代谢中延续，世界才得以向前发展。在某些游戏设计过程中的一项重要任务就是模拟现实世界的某些特征，以期实现机器与用户的更加亲密的沟通。事件机制就是很好的一例。我们需要事件来使我们的系统更加人性化。

　　我想，在我继续进行下面对讨论之前，先简单介绍一下“事件”这个东东。

　　1.游戏中的事件机制

　　联系是普遍存在的。事事有联系、时时有联系，整个世界是一个相互联系的统一整体。一个人的行为、物的状态的改变或事的进展过程的某一阶段可以引发一个事件。一个事件的发生或许会引发另外的事件——通过人的感知、大脑的反映，然后作出决策，付诸行动——也或许，就这么蒸发掉，无人知晓。但无论如何，在这一过程中，我们总能抽象出一些实质性的东西来。就像下面的图示：

　　在游戏中：

　　事件源——表示任何可以引发事件的对象。譬如，一个“人”、“坦克”、“建筑物”、“地面”。

　　事件——表示任何可以处理的事件。譬如，“感冒”、“射击”、“倒塌”、“有对象经过”。

　　响应者——表示任何对某事件感兴趣的对象。

　　响应器——表示对某事件感兴趣的对象对某一确定事件作出的反应。

　　特别的,对于过程：

　　通知——发生在事件与响应者之间。我们把它分为两种方式：有限听众式、广播式。对事件感兴趣的对象（响应者）只有确定的有限个（只有一个的情况下，可以叫做点对点式）的情况就是有限听众式。而对于广播式，事件并不知道会有哪些（个）对象对自己感兴趣。它向所有可以接收事件通知的对象广播事件。

　　触发——响应者发现自己对特定事件需要做出相应的行动时就会触发事件处理器，并同时传递需要的事件信息给它。对于响应者，它也可以选择沉默——自己了解事件但并不作出行动。因此这个过程的决定权在响应者手上。

　　2.万事之鼻祖Event

　　我们需要一个类来表示所有事件的普遍性质。

　　3.枚举类型EventTypes

　　这个枚举类型指示事件通知过程的类型：有限听众式、广播式。

　　4.响应者接口IListener

　　该接口只有唯一的方法EventArrived()。事件发生时会调用这个方法并传递相关参数。这个参数必须是EventArgs或由它派生而来。

　　5.EventPool

　　一个事件池。当且仅当需要事件广播时我们才需要它。需要注意的是AddEvent方法。它把一个事件添加到池中，第二个参数指定是否将该事件已经指定的响应者亦添加到广播的响应者中。事件添加后，其Event::EventType属性会被设置为EventTypes.Broadcast。

　　6.EventArgs

　　7.UMLDiagram

　　8.响应者行为

　　响应者实现IListener接口后就可以响应事件了。在EventArrived()方法中，你可以直接处理事件，抑或是调用其它的事件处理器（响应器）。C#中有很好的解决方案——委托——替代函数指针的最有效的方法。在C++中也可以用虚拟函数表来模拟委托机制。总之，在响应器上的解决方案是很灵活的。在实际开发中，可以根据不同的环境做出不同的选择。

　　9.扩展机制

　　在一个游戏中，除了已经定义好的事件外，其剧情或功能可能会要求玩家自行定义一些事件。这就需要一种可扩展的方案。我们引入了CustomEvent类——继承自Event，以及Condition类。

　　初始化一个CustomEvent类时必须同时传入一个Condition类。Condition类必须被继承。Test()方法在适当的时候被调用以检测是否可以引发这个事件。

　　10.结语

　　模型是否实用需要通过不断学习与实践检验，上文所提还是理论雏形，更多教程请关注课课家“游戏开发”板块。