Your event manager component would typically have publish and subscribe methods. So lets say you have a TArray of hash,delegate pairs. Each event you want to be able to use, you register as an event that can be subscribed to (lets say there’s a method RegisterEvent on the component). Other components that want to receive nofication of the event being fired, get hold of the manager component and subscribe to the event with a method that gets called back. Components that want to call the event, simply call Publish on the event they want to send.
So the Event Manager becomes something like:
class AEventPublisherComponent: public AActorComponent
{
EventHashID GetHashForEventName(String name);
bool RegisterEvent(EventHashID hashid);
bool PublishEvent(EventHashID hashid,AActorComponent *sender, void *pData);
bool SubscribeEvent(EventHashID hashid,EventDelegateMethodPtr callbackmethodptr);
// storage for hash/delegate pairs (TArray? TMap?).
}
Then in terms of usage, one component would simply Publish the events it needs to and Register for the ones it wants to be aware of. The downside of this approach is that then ALL components end up being dependant on this publisher/subscriber class wherever it is. But that is mitigated by the fact that once it is up and running and debugged it generally won’t change much. It also has the advantage that then components are not tightly coupled, but instead are coupled only by the intermediate Event manager.
Now I’ve seen both central singleton based “manager” classes and localised per-actor type message handling. In fact my last engine I built had both together. But the core is the same, pass events through a third party and try and keep components from knowing anything about each other directly. Unless you absolutely must have speed, in which case simply store a weak pointer to the class that you need and have some way of ensuring the dependency at least at compile time.