If you read my previous post on events, actions, and delegates in Unity, you may know that I love proper usage of the c# event system for class and object interactions. Using events/actions gives you a clean, maintainable framework for building your games, and allows for easy extension and expansion of your projects without touching the same files over and over. (and breaking things)
Since I wrote that post though, I’ve made two small but important changes to how I’ve been doing things personally.
Events with empty delegates
First, I’ve been defining my events in a slightly different way.
Because Unity doesn’t yet have access to the ?. operator in c#, I started to become frustrated with having to do null checks before invoking every event. Luckily, a buddy of mine named Kyle shared a simple fix.
Instead of having the event be null, I just assign it an empty delegate in the declaration.
Take a look at this ScoreController class for an example.
On line 6 you’ll see the OnScoreChanged event.
Notice that it’s initialized as an empty delegate that just does… nothing.
So now, when I want to call OnScoreChanged (on line #13), I no-longer need to do the null check.
What about performance??
If you’re freaking out and worried about performance, calm down. The overhead of making this call to do nothing is so tiny it’s not going to impact your app performance at all.
Static Events
The other things I’ve started using is Static events.. If you’d asked me a year ago, I’d advise against them heavily. Part of that is just a dislike for static methods due to my life of dependency injection and unit testing. But if you’re not unit testing and using a DI framework, static events can give a great clean way to know when something happens that you want to react to.
What’s this look like?
On line 6 you can see that I have a static event named OnAnyTookShot.
The invocation of this event actually passes in the current instance of the Shootable that took the shot.
Why??
If you take a look at my decalcontroller script, you can see that I use the static event to have the decal controller get notified whenever ANY shootable takes a hit.
This way, my decal controller doesn’t need to know what Shootables exist, it doesn’t need to register for multiple events, and it still gets the shot event and allows me to spawn a decal where it needs to be.
If you want to learn more about the decal controller, I’ve written a bigger post focused on it here
Warning
One thing you want to be sure to do is unsubscribe from these events on destroy.
If you don’t, the instance won’t be able to be garbage collected because of that lingering event registration.
Wrap Up
These are just some minor points I wanted to share.. if you haven’t been using events & actions in your code, I highly recommend you take a look at my previous post on the subject here: https://unity3d.college/2016/10/05/unity-events-actions-delegates/
Using these 2 additional techniques and slightly different format will help take your code to another level of simplicity and make your projects a bit easier to maintain and grow.
Also, if you have some great suggestions (or some questions) about events in Unity, please drop a comment below.