Maximum output for minimum input.
…That’s the idea behind Juicifying Your Game. But this can lead to some pretty messy code if you start injecting extra code at every event that happens in your game. This is where messaging/event systems come in handy to ensure that every component of the game is given an opportunity to provide their own juice.
This article is a quick overview of a couple different ways to implement a messaging/event system in your game engine. Typically something similar to the straight observer pattern is used, but there might be situations where using a visitor pattern could assist in more readable and maintainable code.
Straight Observer Pattern
Typically, the observer pattern allows an observer to be registered for notifications when a state change occurs in the system. In this case, we will use it to send game messages to a list of all registered components by calling their handleMessage(GameMessage*) function. This will require all observers to implement a common interface which includes this function and register themselves with the Game Message Manager to receive messages.
void Component1::handleMessage(GameMessage* message)
{
switch(message->getMessageType())
{
case MessageTypeTargetDestroyed:
// Do stuff to this
break;
// etc.
}
}
Observer-Visitor Hybrid
A strong benefit of the visitor pattern is full encapsulation of logic within the visitor. In this case the GameMessage will be the visitor which will visit all observers rather than relying on the observers implementing their own handling logic.
void GameMessageManager::sendMessage(GameMessage* message)
{
foreach(std::vector::const_iterator it = components->begin(); it != components->end(); ++it)
{
message->visit(*it);
}
}
class GameMessage
{
public:
virtual void visit(Component* component) {}
virtual void visit(Component1* component) {}
virtual void visit(Component2* component) {}
virtual void visit(Component3* component) {}
virtual void visit(Component4* component) {}
}
class TargetDestroyedMessage : public GameMessage
{
public:
virtual void visit(Component1* component)
{
// do stuff to the component
}
// etc.
}
This second pattern may promote flexible and reusable public interfaces for certain components because the visitor must perform all actions upon those public interfaces of the components being visited. If you are concerned about your components becoming overladen with message-specific functionality, this pattern may assist in relieving that coupling.