This article is also available on Medium.
Several weeks ago, we implemented a simple event mechanism that allows us to better separate the systems in our game and avoid too-strict relationships. The first draft was meant to be very explicit and, because our class hierarchy was not as clearly defined as it is now, it was easier to use an intermediate struct,
CustomEventData, to represent the type of data that could be sent in an event.
However, this implementation is far from ideal. In particular, if we start adding more and more data types to our events, we’ll have to remember to add fields to this
CustomEventData struct and update all constructors. And differentiating between “typed” and “not-typed” events was important at first to understand the event system well, but it’s a bit user-unfriendly in the long run.
Now that we’re more fluent with C# and type casting (especially thanks to our multiple glances at polymorphism and inheritance), we can improve this system and leverage C#
object variable type! 🙂
Refactor of the
The new class I propose for
EventManager has two main differences with the previous one:
- typed events don’t use a
CustomEventDataclass anymore, rather we’ll be using the C#
objectvariable type that is very “lazy” and can be casted into anything quite easily further down the road (it’s sort of like a “any type of variable is accepted here” flag ;))
- we don’t differentiate between events and typed events anymore in our trigger/listener calls: instead, we’ll take advantage of C# function overload to automatically register the event as a typed event if some data is provided, else as a plain old (non-typed) event
So here’s the full code of the new
EventManager class (that will replace the previous one):
As you can see, it still has the same overall structure and works the same way as it did before. We simply removed all usage of the
CustomEventData type and “merged” the trigger/listeners functions using overloads.
Now, we need to update the various scripts that used events to match this new system. Basically, we’ll have to:
- replace all occurrences of the
RemoveTypedListener()) method with the simple
- replace any occurrence of
CustomEventDatainstances with a basic
objectvariable and then, in our listener callback functions, cast the received data into the proper type so the compiler knows what actual type the variable boils down to in the end.
Changes in the
UIManager, we need to change the listeners declaration and their callback functions – the following snippet of code shows all the modified functions:
Changes in the
BuildingButton, only the
OnPointerEnter() function changes:
Changes in the
UnitManager, we also have a couple of typed events that have to be adapted:
And that’s it! We can now remove completely the
CustomEventData class and we won’t have to worry about adding/removing/modifying the fields of this struct in the future!
This was a really quick interlude, just to remove this small thorn in our side while it’s still manageable 🙂