Quote:Quote:
The individual components do not send the events, but they create them (e.g. Life component sees entity.Life = 0, so it creates an EntityDeadEvent) and then they give them to their parent SubSystem.
Actually I have no methods in the components (only getter and setters), so the component would not know by itself that it's dead. The LifeSubSystem would check if the child component is dead and then create the event. I don't see how a component can create an event on its own since there is no Update() method in the component.
If the LifeSubSystem checks its child components, that would require it to poll all of its child components every update. Depending on your specific game, that may be a poor way of handling the situation.
Perhaps in a setter method you could create an event if Life = 0. Something like this pseudocode:
class LifeComponent { private: int Life; public: void SetLife(int l){ Life = l; // Check for Life = 0 if(Life == 0){ // Create event // Note: Here's where you would include this components EntityID# and any other information you want Event deadEvent(...) // Give event to parent SubSystem mySubSystem->sendEvent(deadEvent); }Your event system may depend on how you create your components. This may be an ugly way of creating events, or it may work out good for you.
Quote:Quote:
When a SubSystem receives an event from another SubSystem (e.g. LifeSubSystem sends event to VisualEffectSubSystem) it could pass the event on to all of its child components who care to receive the event.
How does the SubSystem know which child components care about the event?
The child component will register themselves to receive events of a certain type. Perhaps the type could be of which SubSystem is sending the event. This registering could be done twice; the SubSystem registers with the EventManager, and the components register with the SubSystem. Keep in mind that it's not necessary to register yourself with anything, but you wouldn't receive any events. You could also have your SubSystem register for events while none of its child components are registered with the SubSystem. In this situation, you could have the SubSystem do whatever it wants; it could destroy some components or create some, or instead send a new event, all without the child components knowing of any such event.
Any class that cares about an event must inherit the EventListener interface. Then, registering for events is as easy as:
// VisualEffectSubSystem registering to receive events of type Life (i.e. from the LifeSubSystem)
EventManager->registerListener(this, EventType::Life);
Quote:
Then a more general question about this approach:
Since almost every time something is happening, wouldn't it be too much events going around the subsystems? For example: when the player has lost some health points there would be en event EntityLostHealthEvent going to every SubSystem. There would be quite a lot of such events.
Probably not. The beauty of an event-based system is that all the systems can be very loosely coupled (if not independent). The LifeSubSystem does not know of any other system; all it knows is that when a components Life = 0 it should send an event saying that "EntityID# has 0 Life." Then, anything that is registered to receive those type of events will receive the event and can handle the event appropriately.
In large games there are typically EntityMoved events which fire every time any entity moves. That's a lot of events, but it makes sense. The SoundFXSubSystem would receive this event and play the appropriate sound file (e.g. a Tank moves and the SoundFXSubSystem receives the event and plays the 'TankTracks.wav' file). So, as you can see, there will probably be a ton of events in your game. If you manage memory correctly, you shouldn't have any problem with the number of events being transferred through your game.
