"A delegate is just a variable which holds a method instead of data" omg this helped me understand it right away. It's SO SIMPLE but nobody explains it simply that this is all it is lol. Thanks!!
If you have someone explaining things to you in a straight and simple manner, actually, even complicated things becomes understandable. I had a similar realization, when I looked into delegates / Action / Func - but from another RU-vidr, some years ago. This guy (Tarodev) is excellent - things like this makes me believe in humanity again. People helping each other online, for no other reason than being nice / polite to others.
I came here looking for a solution to fully decouple my game scripts, and walked away with the wisdom that it doesn’t need to be that way. Thank you, Matt!
Gotta say, this all makes way more sense after working for a few years as a front end dev with React. JavaScript, especially React, does this all the time.
@@Etienne_H For the UI. You could have a bullet hit something, and either the bullet or the object it hit could register it in the game by calling a "Hit" event. Then you can have the UI listening for the Hit events, and updating a scriptable object that is recording Total Hits, etc. Then the UI would read from the scriptable object every second. (I don't know how this would perform with thousands of bullets flying around, its just an example.)
A delegate is literally a fancy, managed wrapper for a function pointer. You can even obtain a function pointer from native code and marshal it into a C# delegate, then pass that delegate around and call it just like any other delegate. This can also work in reverse. Under the hood, a delegate _is_ a function pointer, it just uses a different declarative syntax and hides the actual address and other complexities from you so it can be used more intuitively. I manually declare delegates sometimes, but many of the most common signatures you'd want to use already have a predefined version like a delegate void with no parameters or several parameters can be declared with Action and Action and when you want to return stuff there's Func and Func (there's variants with numerous parameters like T1, T2, T3, etc). That covers a _lot_ of delegate usage, and it's hard to think of some it won't cover. So why ever declare your own? Well, for intuitive and expressive naming, of course! It can clearly express your intent as a programmer and also make things a bit more type safe. You may not want to use Action for an event representing two totally different things so no one can confuse the two and create hidden bugs that can be hard to find. If it just uses an Action or Func, you can easily have another programmer mix stuff up and have criss-crossing events creating undesirable or fatal behaviors. But if you have two types of delegate clearly named things like _MenuActionDelegate_ and _KeyInputDelegate_ it gets much harder to confuse those things or use the wrong thing! That's a pretty contrived example, but in a real project you'll see how that makes sense if you think about it ... So, sometimes, it's actually kind of _smart_ to manually define a custom delegate, even if that signature is already defined by built-in ones like Action or Func. Keep in mind, there's _nothing_ special about Action or Func, they're just common delegate declarations exactly like the ones we declare ourselves. Many people don't know this and think those are some kind of special classes with their own fancy code but they're not. This is literally the definition of Action, as follows: public delegate void Action(T obj); That's it! That's the entire definition/implementation of Action, just a common delegate with one generic parameter. Nothing special about it other than what the .NET Framework does beneath the hood with _all_ delegates we declare. Microsoft just included these built-in delegate definitions so we'd all have predefined ones that cover almost all the use cases, so we wouldn't have to waste time or add clutter to code if it didn't make any sense to. If I want to quickly use a delegate in one place in my app and be done with it, I'd hate to have to stop and decide where I should go define a delegate signature and then come back to my method I was working on and use it ... much easier to just use a Func or something as a temporary use delegate. But anytime I'm creating something like a custom event system that's consumed from other classes, I do take the time to define my own custom delegates for the sake of clarity and expressiveness ...
P.S. - As always, enjoyed the video and enjoy throwing in my two cents on these topics. It's refreshing to see someone teaching important C# fundamentals and good practices in the Unity world, as there's so much awfulness out there, haha. I share these videos with junior devs on our team that are curious about the topics and want additional information and they enjoy these too! 🙂
im a bit confused. "So why ever declare your own? for intuitive and expressive naming" couldn't you just use the predefined types but name it something that wouldn't cause confusion? eg. public event action MenuActionEvent; i dont see the need to declare your own delegates if the predefined ones fit your need
So many people sound like they're just reading from the docs when teaching something. I'm always amazed at how you DON'T do this, but really deliver the material in an understandable way. Brilliant video.
I've been trying to understand exactly what a delegate is for far longer than I would like to admit. This clear and concise example at the start of the video just made it straight up obvious. Thank you!!
I thought I knew the topic but you somehow always add to my knowledge. Thanks to you I found out what "event" keyword does and how "Func" differs from "Action". Your explaining is so wide and simple at the same time. Thanks!
This video (and channel) is an absolute gold mine. I really wish this was explained like this to me earlier, it's so clear now. Thanks for taking the time to put this together, I will recommend this video to any confused beginners I might encounter along my way.
I love that you used real world practical gaming examples. Sometimes I learn about these new programming concepts but its not clicking why I would use them.
Loved that this is one of the first videos about events that the person mentions the downside of events/decoupling, which is lack of clarity, and harder debugging, so it's something to definitely use with caution, especially the "static" version of it, since you now can subscribe from literally any script without even holding a reference to a specific instance. Really nice video!
Ok, Tarodev, gotta say, this was a really good video. I started programming in C# at my first official job in 2003 (ya, v1.0, when most people thought .NET was a super sketchy idea), and I learned all these language features that long ago. AND YET, I still learned something by watching your video. And I was engaged the whole time. Srsly, excellent job.
Well damn I wish I'd seen this years ago. I know how to use delegates but did not know that simplified way of writing them as Actions and static actions. Thanks!
All the video after you said you never use delegates I thought "what's with passing em down?" And in the end you even got this, nice work. I use em for these damn coroutines. In my game I want to know when the animation is finished and start something new. There delegates have been the best solution.
I started using delegates in my game to implement the behavior system, since I can store all the behavior conditions and calculations within struct that I can put into a list and reorder as needed. Something else you can do is store class extensions functions as delegates, ex: function = this.extensionFunction. I do this to keep my scripts organized by defining the behavior functions themselves as extensions to my behavior class.
You've gotta love it when someone Really knows the subject matter, and how to relay it. That was an excellent explanation, thank you. You are a step above the other 'monkeys' :D
There are 2 reasons why I use more rarely (static) events: the subscribing/unsubscribing part and the "voyeur"-ability this functionality gives - everyone can subscribe, also he can subscribe redundantly, but I don't want that! I want to limit access and know exactly who gets triggered and who listens - you clearly state it in the video => REDUCED CLARITY! (bravo for giving Pros and Cons on the concept!!!)
I've used delegates in my game mixed with interfaces to change the functionality depending on interactions. It's been super useful to allow my function to change and be called without me having to worry about what it is actually calling.
I already knew plenty of things about C#, but i could never wrap my head around how delegates work. Your video made it clear to me. Also, static events seem really useful for my stuff, and i cant really tell why i havent learned them before. Thank you! Best wishes!
I wasnt ready for this video when I first started watching but I have recently stated calling Unity Events so now I am able to understand this much better. Honestly your channel is amazing! Your personality is hilarious...love all the zingers!
I love the detail into C# in your videos. They have helped me strengthen my skills as a developer. I don't use Unity but I do use C# with Godot and your videos have helped me immensely. Keep up the great work and thank you for what you do!
Special thanks for the beautiful picture, beautiful buttons, beautiful sprites, in total - beatifull visual work in your videos which in no way relate to the topics of your videos, but it's very pleasing to the eye Probably this video not for beginners and your explanation not the best but doesnt matter, your videos so good It's like comparing buggy win 10 and mac os with amazing controls
In our workplace, we avoid using UnityEvent. This is because in the past we would spend hours debugging why Foo() is being triggered randomly only to see that Foo() is in a random UnityEvent in a random animation or prefab. The problem is that if a function is invoked by a UnityEvent, the stack trace will not say which object is invoking that function. The IDE will also mark the function as "not used" so it shows as greyed out and somewhere down the road, a new programmer works on the project and deletes the function tied to a UnityEvent causing all sorts of bugs. It's less designer-friendly but having functions be explicitly triggered through code only helps reduce bugs in general. This has somewhat been alleviated though ever since we all switched to Rider because Rider knows if a function is used in a UnityEvent.
This is a major problem for the entire scriptable object architecture workflow. It's toop hard to keep track of what's triggering what. I stick with standard functions, too.
I see some JB Rider shortcuts being used. I'd be interested in a video detailing some of the JB Rider tips as it relates to Unity development.. Maybe you can get them to sponsor the video or something :)
Nice summary. One note though: multicast is not about having the event keyword or not. It’s about registering multiple callbacks (methods) in the same delegate. In old versions of C#, there was two types of delegates, one for single cast delegate and one for multicast. They simplified the thing by only keeping the multicast one.
One thing I like about Actions is that you don't need a definition like Delegates, just the signature. A good tip is that if you are going to create some kind of custom "EventArgs" to send a group of data, prefer to use struct unless a class is necessary, that will generate less garbage. (that is the struct's function anyway 😁)
Really Helpful video, as usual, I recently found the 2048 and grid game video. Ngl those types of videos are really great for learning. I found it very helpful. Learned a lot, Thank you!!. Hope you make long videos like those covering a variety of topics.
Nice video and nice information regarding's this topics. I will have to work with them in order to understand them better but now at least I have a general understanding of them so thank you for this video :)
I try to keep the visualization / UI totally decoupled from game logic and Events (or UnityEvent more specifically) provide a good one-way communication between them. Though sometimes I run into a problem when subscribing and invoking happen in the same frame (new instantiated class subscribes to an event which invokes during the same frame - thus not triggering whatever function I wanted). Thanks for the video anyway! I've always found delegates to be hard to understand.
I have a use case for the Func. I have a decoupled system for an RPG style character-trait system. (Charming, Strong, Brawler ect.) Every NPC in my game have a data script with an enum list of all the traits they have. However some trait a contraditary like Charming and Awkward. So I made a static func with a return type of bool that took the TraitEnum as an input along with a list of traits. Now I have another script stores all the data about the trait, their bonuses and which other traits they contradict This other script have a function of type bool CanAddTrait(Trait currentTrait, List OtherTraits) There is probably a better way to do this, but it solves my problem, separates the two classes, and is easy to do testing with
Dude, you create insanely useful, extremely well explained videos! I like your short on-spot examples to demonstrate everything. Keep up the good work! I hope you make a cooperative video with Jason Weimann and Codemonkey, so your channel gains more popularity. In my opinion you beat both of them: Jason sometimes drifts away from the topic and Codemonkey's tutorials gotta always get paused to check what he speedtyped and moved off screen immediately after that.
@@Tarodev :D just don't watch the sequel. I am being honest with you, watching constantly tutorials for a decade (since Brackeys entered and basically (re)defined the gamedev youtube tutorial scene) in case there is something new in Unity that I missed. You are really good at explaining. Fact.
@12:30 About unsubscribing; Normally I subscribe and unsubscribe exactly like you suggest here (@13:12). But in rare occasions, I found myself having to subscribe to events from multiple locations in my codes. This easily lead to accidental subscriptions to the same event multiple times, which results in it being fired multiple times with each call. In situations like this, it is possible to unsubscribe first, and then subscribe in the next line. If you are not already subscribed, nothing happens. If you are, you make sure to only add one listener.
On the Event part. I guess you did not mention it in order to keep it simple, but events can also have "add" and "remove" which function like a getter/setter on a property. You can check for not having duplicate listeners or methods with this.
@@Aryazaky yes, like a get/set, you can add {} to the add and remove and do things inside. Note that you need an underlying private delegate. Just like a property. You can then use the GetInvocationsList().Contains to check if the listener being assigned is already assigned. Or any other thing you want.
I've heard of delegates but never even conceptualized the idea in my head while I was using it left and right on javascript. I even learned actions and func before delegates and events and it seems so much easier this way. I have to admit I found delegates way too convoluted in c#
Shortest explanation about differences between delegates and events: An Event is a delegate with 2 restrictions: 1- You can not invoke the delegate reference directly 2- You can not assign to it directly A bit longer(but sweet and funny)explanation: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-NgrnCMaxIXM.htmlfeature=shared
This is fantastic! You explain the subject so clearly, it helped me out so much. Do you have any plans to cover Observables in the future? I'm trying to learn it at the moment but there doesn't seem to be many tutorials out there that cover the subject in detail.
My final comment before going back to work. I learnt not long ago that local functions are much more efficient than anonymous functions (local function: you can declare a function inside a function) I guess round 2 on the amazing performance vid could be great?
I'm a strong believer in local functions and use them a lot, but had no idea how the performance benefit. I'll have to look into that. I think I'll be doing round two benchmarking very soon.
Great explanation! I became a huge fan of events since I discovered them, but at a certain point I also became too obsessed. As you say in the end, it's good to decouple things when needed but sometimes it might just make your game architecture overly complicated if you decouple too much. One question I have is: for objects that are constantly being enabled/disabled I usually subscribe to events on OnEnable and unsubscribe on OnDisable. But what about objects that remain enabled throughout the lifetime of a scene and only get disabled/destroyed when a new one is loaded? I usually subscribe on Awake, in those cases... but should I bother to unsubscribe on OnDestroy anyway?
I'm constantly disabling UI-elements and I have trouble getting events to work properly. I was wondering if instead of disabling/enabling, it was better to make the UI-elements invisible? But you claim here it works if you assign the subscription in the Awake? Do you mean C# or Unity-events, or both? P.S. If you know any good videos for learning proper UI-programming in Unity please share, I find it somewhat cumbersome or hard to wrap my head around.
