UML软件工程组织
游戏框架设计Ⅰ——游戏中的事件机制
Keywords     游戏开发   事件机制   EventPool

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

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

     1. 游戏中的事件机制

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

     在游戏中：

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

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

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

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

     特别的,对于过程：

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

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

     2. 万事之鼻祖 Event

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

public class Event {

     // 属性

     public string Name { get;set; }// 获取或设置事件的名称

     public string Message { get;set; }// 获取或设置事件的简单描述

     EventTypes EventType { get;set; }// 获取或设置事件类型（枚举EventTypes）

     ListenerCollection Listeners { get; } // 获取响应者的集合

     public bool PoolEvent { get;set; }// 获取或设置事件的简单描述

 

     // 方法

     void RaiseEvent(); // 通知响应者事件的发生

     void AbandonListener( int index ); // 抛弃一个事件响应者，并把它从 Listeners 中移除。

     void AbandonListener(); // 抛弃所有的事件响应者

}

     3. 枚举类型 EventTypes

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

public enum EventTypes {

     LimitedListener ,

     Broadcast

}

     4. 响应者接口 IListener

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

public interface IListener {

     // 通知一个响应者事件的到达。

     void EventArrived( EventArgs args );

}

     5. EventPool

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

public class EventPool {

     // 属性

     public ArrayList Events { get; }// 获取池中所有的事件的集合

     public ListnerCollection Listners { get; }// 获取池中所有的响应者的集合

 

     // 方法

     void AddEvent( Event obj ，bool copyListners ); // 添加一个事件并把它作为广播式事件

     void RemoveEventAt( int index ); // 将一个事件从列表中移除

     void RemoveEvent( Event listener ); // 将一个事件从列表中移除

     void Broadcast( Event event ); // 向列表中的所有响应者广播指定事件（可以是非池中的事件）

     void BroadcastItemAt( int index ); // 向列表中的所有响应者广播池中的指定事件

}

     6. EventArgs

public class EventArgs {

     public Event Event { get; } // 获取传递这个参数的事件

     public object Sender { get; } // 获取事件源

}

     7. UML Diagram

     7. 响应者行为

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

     8. 扩展机制

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

public class CustomEvent : Event {

     public CustomEvent( Condition condition ) {

          _Condition = condition;

     }

 

     public Condition TestCondition { get{ return _Condition; } }

 

     Condition _Condition = null;

}

 

public abstract class Condition {

     public Condition() {}

     bool abstract Test();

}

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

     9. 后记

     以上谈到的只是一个简单的模型，是否实用还要等待实践的检验。欢迎读者的批评与建议。
　
版权所有：UML软件工程组织