how to represent event data in event-driven communication?

Question

I'm trying to create a central event dispatching system using kind of an Observer pattern for my small RPG project, and I need advice on how best to represent event data.

I'll have an EventManager that registers listener classes for different event types defined in a static enum such as Event_Input_KeyPressed or Event_Game_ActorMoved. It will store events in a queue and dispatch them to the corresponding listeners, which will each have a method handleEvent(Event e) or something.

Each event will be an object of type Event, which holds data such as its event type.

My question is, since the nature of the event data differs considerably between event types, how should this data be represented? I'm not yet sure exactly what types of events I will want to create in the future, so I want this to be as flexible as possible. For example, an event could trigger other events if certain conditions are true (ie. when the player pressed the action key, a door opens if the player is in a certain location and has a key). Is XML or scripts a good choice? Another way I can think of is to create a custom class for every general event, like ActorEvent or MenuEvent, but that seems really inefficient and inflexible. Also, since some objects such as Character only need to know very specific events like when the "w" key is pressed, I figure they don't need to be notified when other keys like "h" are pressed. Is it viable to create event types that specific or is there a better way? ie. Event_Input_KeyPressed_W

Thanks

Answer 1

1. Create concrete implementations of your events, extending from the Event base object. Firstly, it will be easier to distribute the objects - that is in your queue, you would only need to do a instanceof to determine how to handle the object.
2. Your event listener code becomes MUCH simpler and more tightly controlled. There's no chance that a mouse event will be past to a key event. Also, you won't need to test and cast the event object at the listener level
3. I can't see why you couldn't create a "filtered" event listener that will only want to be notified of a particular condition of a particular event, in fact, I think it's a neat idea.
4. I'd probably devise some kind of pluggable dispatching mechanism. That means when you add a new event type, you won't need to update the queue, you can simply register a new dispatcher. Depending on what you might want to achieve, your queue would pass the event to the dispatcher (providing some means for the dispatcher to get list of listeners). The dispatcher would determine if it knows how to handle the event or not. The dispatcher would then dispatch the event to the required listeners (and depending on what you want to achieve), return a result saying if the event was dispatched or not.

That's MHO

Answer 2

• As you say the structure of different event types are different it is better to create concrete classes for each event. You don't need to create a class for each key! but generally keyboard events
• You say characters should only be notified of a specific keys. I don't know what is the overhead of notifying the character and let that object ignore unrelated keys but if this is a common pattern among classes for example you have 10 different classes that may react to a special set of keys, it would be nice to not repeat codes and implement a dispatcher layer between events and listeners. One kind of disptachers can be KeyFilterDispatcher that receives a list of keys and filters events based on that. Another kind of dispatchers can be seqDispatcher that only disturbs listeners if multiple events are considered in a specific order! I like the pluggable disptacher idea MadProrammer said. Also you may want to create pipes of dispatchers too!