Hello guys, before I get into my question I just want to apologise if this is in the wrong section, I can see this question covering both scripting and game design. With that being said I’ll move on with the question.
I am wondering whether or not I should implement an event manager system in a 2D platformer project I’m working on. I have an understanding of how events and delegates work but this question relates to more code architecture. I come from a strict OOP programming background where every class is reposible for one specific thing and and I try to follow the SOLID principle, so far I’ve managed to stick with that principle but as I review the code within the project I notice that a lot of references to other scripts get passed around, we are sort of using a composite pattern and I am looking for ways to make the scripts a little cleaner looking and more efficient so I’ve been looking into creating an event manager script in the hope of minimising the about of reference that are getting passed in. Do you think this is a good approach to combatting the composite pattern or is there an alternative you guys could suggest. Sorry for the long post but I wanted to make you guys understand where I’m coming from and why I’m thinking of implementing this to begin with.
Regards
-Joshmond
You’re using a composite pattern… of course references are going to be passed around. It’s sort of the inherent nature of the composite pattern. A component references its leafs.
You mention an ‘event manager’ to combat this need for references.
What sort of event manager do you mean? Usually an implementation of an Observer Pattern will still require getting a reference to the object you plan to observe. So how is this side stepping the reference issue?
Unless you mean like a global decouple event manager. Where you can send up events to the ether with some id token, and other objects can just listen for those events? If so… I would advise… not exactly a good idea if all you’re trying to do is not have references resulting from a design pattern that inherently is about references.
This is OOP afterall… things are objects… and you reference objects. The entire paradigm is structured around passing around references.
Hey Lordofduct, maybe the using the word “event manager” was wrong, what I’m referring as you correctly pointed out is an adaptation of the observer pattern where there are still references but they are hooked into a manager which is responible for adding and dispatching events. My line of thinking is that by doing something like that it will decouple my logic and would work better for my UI and animations. References are still being passed around but they are being routed to a manager which handles that for you so all events are stored in one script. I can see the benefit of a system like that but I don’t know if it will impact performance.
Regards
-Joshmond
events and UnityEvent are perfect for this. Events work great in an all code setting, UnityEvent works great if you plan to wire things in the inspector.
No need for a manager class for it, they already exist.
Thanks, I’ll probably end up using just plain events or UnityEvents instead of creating a manager for it. Will the order of events/execution mess things up? For example, if I’m running a cutscene in my game and I’m using an event which is subscribed to a method, if then another script runs with another event attached to it will that mess up my game if the other event completes before my cutscene event? What I was orginally going for was something similar to Unit’s messaging system but with a queue to ensure that my events are completed in the order that they are executed/loaded.
Regards
-Joshmond
Depends on what’s going on in the handlers for those events.
If some handler expects some state, and that state isn’t prepared yet… there will be an issue.
But that’s not the events fault, that could be so for any method call.