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 EventManager class

The new class I propose for EventManager has two main differences with the previous one:

• typed events don’t use a CustomEventData class anymore, rather we’ll be using the C# object variable 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

#tutorial #unity #games #csharp #interlude #rts