So my understanding is that you define a delegate. Then you create an instance of the delegate with the event keyword. Then, using that instance, you can subscribe methods to this event…
You can also subscribe the same method as many times as you want.
Then you can trigger that delegate and every subscribed method will be executed.
Is this throughout the entire project namespace in which the delegate was defined?
I think if we could have a classic Unity General Discussion about events, it would be pretty dang helpful.
Seems to me that it’s kind of like an object that contains a list of references to methods, and it can be triggered like a method rather than having a trigger method.
Why doesn’t Unity Free come with the dark theme? Why does Unity cost so much when Epic gives people money to use Unreal? How do I read a variable in one script from another? And I tried literally everything and read every Google search result, but I still don’t know what NullReferenceExceptions are all about.
On a less classical note: Events and delegates were part of C# when it made its debut fifteen years ago. They have been thoroughly explained, demoed, and used to death elsewhere on the Internet. So I doubt that discussing them here would add much to what is already out there.
I guess he’s talking about the Unity implementation of events. Namely UnityAction, UnityEventBase, UnityEvent, UnityEvent, UnityEvent<T,T,T,T> and the persistent and non-persistent listeners.
It took me quite some time to get an overview on this topic and currently attempting to extend the UnityEventDrawer to display up to 4 parameters instead of 1. It’s hard
Btw if anybody has special infos about the C# roadmap, allocating a byte of memory for a real “void” return type in a future C# version would be the greatest news ever. Func<T,void> would cut down the Unity event implementation code size by a great chunk.
I like using them this way. Its nice to be able to setup behind the scenes a lot of conditional logic that responds when certain things happen. For instance Character runs TakeDamage(int amount) to which a UI element is subscribed to and the UI element runs its RefreshCharacterHealth() method and only has to make one call for it instead of just lazily doing it in Update.
That can scale up fast if you start having a lot of objects and if you’re not using a subscription event of some kind its going to result in a lot of unnecessary overhead.
You forgot make me an MMO. I’ll share the profits.
Many of the new users gain a fair bit from discussing these concepts within the Unity frame work. I’ve learned quite a few different techniques from the random code discussion. So I can’t say it will hurt anything.
I think the biggest unity relevant issue with events and delegates really comes down to stuff like lifetime management. Some of these issues (especially in the context of unity game objects and destroy) can get pretty tricky, fast.
Some of the issues with closures specifically and how they relate to garbage collection can really require a lot of discipline and attention to detail to manage properly (in unity or outside of unity, many programmers really don’t understand closures very well - or the difference between a closure and just an anonymous method (if thats the right nomenclature)).
I personally tread lightly here, since I am not comfortable with my understanding of how some of the unity stuff relates to garbage collection. This is not to say that I avoid them, but I do try to keep my usage as simple as possible to avoid problems.
Maybe. Then again, reading the rest of those websites out there… it’s so boring. This place is fun and educational.
Basically, as for the way I’m currently doing things with drag and drop event components (OnThis, OnThat) and reusable, generalized, chainable effect components… I am still lacking a way of wiring up scene-wide, custom events. What I’m thinking is I can add a “OnEvent” script component onto a GameObject and specify which event I want to subscribe to via an enumeration, most likely, wire it up on Start() and then add the TriggerEffect() method as a subscriber. OnDestroy() in that same component would also do unsubscribing, so it will be I think the word is “atomic”.
So, you know, scene wide events without iterating over every object and saying, “hey… stuff just happened”. Either that, or just adding a reference of the gameobject to a manually cultivated collection of subscribers (that checks for nulls and that does automated unsubscribing) when broadcasting the events. I would like to hear people’s thoughts on the matter.
My scrolling shmup uses a custom notification system I wrote to do the kind of things you are talking about. The event usage is a little trickier when using object pooling. I ended up subscribing to receive notifications in OnEnable and unsubscribing in OnDisable as I recall.
Anyway, it is a very easy way to decouple a Unity program. As you mentioned I have an enumeration of notification types and each object can subscribe to one or more as needed. The enemies all subscribe to the PlayerBeacon for example. The player broadcasts this beacon once or twice per second informing whoever is listening of the current player position. The enemies receive that information and use it for targeting shots at the player and otherwise reacting to its location.
I am not using Unity events or C# events though. I have a delegate callback based system where each subscriber identifies itself via its Unity InstanceID. A message can easily be sent directly to one specific object perhaps responding to a query for information and a message can be broadcast to all who are listening. I like to think of it as these objects are on the radio talking to each other.
By combining such a system with a queue you have a lot of flexibility Basically everytime an event comes in (at least for certain types) just add it to a queue instead of processing it immediately. Then once per update pull a notification off the queue and process it. Most things are probably better processed upon arrival. Just mentioning the queue as addititonal food for thought.
I do like the radio analogy. I tire of trying to coordinate things through methods. The advantage I’m seeing for the Unity Events is the fact that they are already capable of being exposed to the editor, I’m willing to wager that there are other thoughtful features they have as well that help with game coding. Unity is about 2-3 steps ahead of me, generally, as soon as I think of something that would be useful I discover it’s already implemented in the engine.
