Events are very new (to me) and a very difficult topic for me to understand. I’m trying to understand events as best I can, and have a basic understanding (I wrote some simple code). Are they used often in professional Unity3D scripting, or should I move on in my text book?
1 Like
Events are pretty new, but I can tell you that I now use them extensively in my professional work. They are great for decoupling components that would otherwise become an intertwined mess.
Be sure to check out my 15-minute video, The Real Power of UnityEvent.
Also, if you’re feeling brave, you might browse the UnityEventComponents project a few of us are working on. These are stock, reusable components based around UnityEvent that you can drop in and use in a variety of projects. Just be forewarned, this code is still pretty green and is likely to change a bit as it ripens. But all this code has been battle-tested in real projects, and browsing the source (all located under the “trunk” folder) will at least give you an idea of some of the ways they can be used.
2 Likes
You may wish to learn about coupling, and why it can be bad for your codebase. Events can help decouple parts of your program from one another.
1 Like
My current (and also first) game is horribly coupled. I want to refactor and clean it up so badly, but I know I’ll never finish it, because code cleaning is a slippery slope.
Goal here is to just finish, but for the next project, I’m looking hard predator-style at Events.
Thanks for the reply. May I ask, in what area of your professional work that you work with events the most?
Also, feeling brave about reading your source code for UntiySourceComponents. 
Man, I use them everywhere.
For example, one project I’m wrapping up now is a sort of match-3 board game. There is a GameBoard class that’s responsible for managing all the pieces, and (with some helper classes of course) detecting when the game is won or lost, when a trophy has been captured, etc. All of those happenings are exposed as UnityEvents, which I then use to show the appropriate UI elements, update the trophy display, play sounds, etc. The GameBoard class knows about none of this stuff; it just says, “Hey, the game has been won.” And then half a dozen other things happen as a result of that.
Using those UnityEventComponents, I have events that fire when the level is loaded, which tell objects to configure themselves (generally calling some “UpdateFromData” method that examines the game state or persistent data). Sometimes a level-loaded event triggers a TimedRelay component, which fires another event after some adjustable amount of time; I use this to display initial instructions which then fade away (using that TimedRelay to invoke a public method on my CanvasGroupFader component).
Obviously I use them with UI stuff like buttons too, but I don’t stop there; my CanvasGroupFader component, for example, fires events when it starts fading and again when it has finished. I sometimes use that to synchronize a fade in/out with some other action. So for example, on the map screen I have a “ZoomedInStuff” group that fades in when you click an area of the map, but at the same time the map itself lerps its transform, and a little diary image slides in from the bottom, all synchronized via events. I can snap that sort of thing together without writing a line of code, and when the designer says “no no, I meant for you to do this first, and then do that,” I can quickly reconfigure the event handlers in the new way.
By this point, I pretty much have anything that any class does invoke an event when it begins or ends doing it, and anything that detects something, invoke an event when it detects it. And any class that does something, I expose a public method to cause it to do that. And then I just snap those suckers together like Legos!
I don’t think even the folks at Unity, on the whole, understand just how important UnityEvent is. Prior to the addition of this in 4.6, this was the gaping hole in Unity’s whole component-based software approach: there was no good way for one component to cause something to happen in another component. You would end up coupling your components together via properties, or using FindComponent, or (at best) rolling your own event system on top of C# events, but even then you had to hook everything up in code. UnityEvent isn’t perfect, but it’s dang close — the editor support is great, and when you use that, it cleans up after itself when objects are destroyed. Life is good!
2 Likes
I also use events all the time, although I use Advanced C# Messenger, rather than the UnityEvent system: http://wiki.unity3d.com/index.php/Advanced_CSharp_Messenger
I’m not terribly familiar with the UnityEvent system so I can’t comment much on the difference, but I believe it is a more targeted event system, whereas Advanced C# Messenger is more about broadcasting events to anyone who happens to be listening.
Do you really have to sign up with that service? I don’t want to create a space or whatever hoops they make you jump through, I just want to see what you made. Perhaps host the code on GitHub instead?
No, you shouldn’t have to sign up just to view stuff. Let me fix the permissions… OK, sorry about that, please try it again.
(And of course we considered GitHub, but strongly prefer svn over git, and other tools that Assembla provides over those that GitHub provides.)
P.S. When the code has stabilized, been properly cleaned up & documented, etc., I also plan to put it in the Asset Store as a free package.
Sweet, please put me on the notification list
Events are a slippery term in programming. The general term simply refers to something that happens at a single point in time. There are at least four specific uses of the term in the Unity environment that I have come across. They are all kind of related, but different. Knowing which one you are dealing with will help.
C# Events: These are really just fancy delegates. You can subscribe, unsubscribe and invoke them. That’s about it.
Unity Events: These are C# events configured to work well in the Unity environment. They have the advantage of being serilisable in the editor, meaning you don’t have to be a programmer to use them.
Execute Events: This is a class that lets you call specific interfaces on other GameObjects. The technique used to be called SendMessage.
OnGUI Events: This is data sent through the legacy GUI system when things happen, like input events, layout events, repaint events and so forth. For the most part you can ignore these events, but you will still see them around in editor scripting.
2 Likes
@Kiwasi , that’s an excellent summary of how this term has been overloaded. I just want to add one thing:
The other neat thing about UnityEvent is that the events hooked up in the editor are automatically cleaned up, too — they get removed automatically when either object involved is destroyed. This is a nice advantage, since other forms of cross-referencing tend to make references that prevent objects from getting garbage collected if you’re not careful. (But that applies also to UnityEvent listeners added in code; you have to remember to clean those up yourself.)
For this reason, as well as just plain convenience, hooking up UnityEvents in the editor isn’t just for non-programmers… I live and breathe code, but in my newer projects I’m using serialized UnityEvents all over the place.
1 Like