More of a conceptual question. I am building a game for a client and am trying to hold myself to much cleaner code standards this time so it is more readable later. One of the ways I am hoping to achieve this is to have a “game manager” script that receives all events. Meaning, entities don’t (unless it does not affect core gameplay) talk to each other. They talk to the game manager which talks to other entities on their behalf. The reason I am starting to do this is because it seems like after I get 80 percent of the way through a project normally I start to lose track of all the places my events are actually plugged into.
This setup of having a hub of events is way more manageable from an understandability perspective but sometimes it creates events that aren’t necessary. For example, if a bullet hit a target, the bullet couldn’t tell the target with one event. The bullet would tell the game manager that it hit the target and then the game manager would tell the target that it has been hit. Obviously this creates two events instead of one. Is this going to cause me significant performance problems because of the extra events? Does anyone have any suggestions on better organizing events? Thanks in advance. Hoping to open up a bit of a discussion on best practices here. I fear this new method I am trying is a bit problematic.
I’d say that as long as you don’t use events per frame in multiple places eg in a script update method, your system will work quite fine.
Events basically invoke an internal callback method, that is found based on the event name key. Unless you have thousand of unique events, it should be fast to use.
The benefits that you get in the long term when designing an abstract system like the one you propose are usually more important than a micro optimization.
@Jake_Johnson to complement what @Leonidas already mentioned, you could have multiple managers, responsible for their part of the game. Since all entities support events, so instead of one large bus, you could use entity.on() and entity.fire() to reduce the amount of events one manager has to handle, e.g. manager would manager.fire() an event that related part of the game would listen manager.on().
@Leonidas Thank you for the response. Very helpful.
@LeXXik Yours was very helpful too! Thank you. Question about something you said though… I understand that different parts of the game could listen on different manager buses, but does this have any optimization benefits or is it strictly for organizing code? Curious if one manager listening to a lot events on the app level is any faster than multiple managers listening to events on the entity level. I think one large manager will work for what I am doing currently as the game is quite small but I will keep that trick in mind for larger projects down the road.
Whenever I start integrating manager into my projects, I do my best to keep them on the entity level. Sometimes, I will even have sub managers talking to a bigger manager.
The main reason for this, for me at least, is so that I don’t have to worry about unsubscribing from my events whenever I change scenes. Usually, I do my best to make sure that only entities that persist between scenes, like session/activity data capture, or my scene manager itself receive app level events.
As you’ve pointed out, keeping the events linked to managers keeps everything clean and easy to find later.
It’s more of an organizational method, as @eproasim described. As @Leonidas mentioned, unless you have hundreds of events handled by a single entity each frame, then you are fine using one manager to rule them all.