Your kind words are much appreciated. Go tell 100k of your closest friends and lets get the channel rolling ;) I do feel like I've found a decent format with this series of videos. No nonsense. No fluff. No fumbling (or not much). No extraneanous information. Just an idea and examples boiled down to the minimum needed to understand.
Simply amazing. I've struggled to understand delegates for hours (watching lots of tutorials), but this just made everything a whole lot easier. Thank you so much.
3:11 This is the best explanation of Delegates that I've heard so far and was what helped to make it finally click with me. And as you immediately follow up with, it's not just any kind of variable, but an Array[] or List type of variable, allowing multiple functions to be assigned to that one delegate.
When thinking about tightly coupled code i always get flashbacks of one of my first big unity projects. I had so many errors just because of code running to late/to soon. Objects not being ready yet, and so on. I think learning to decouple systems is a really important step in becoming a better programmer. And delegates/events are pretty confusing when starting out, at least they were for me. So great job with that video :)
Thanks! When I "discovered" this pattern it changed my code forever, but I definitely didn't understand all of what I was typing. And I 100% agree decoupling code is huge!
I've been struggling to understand the Observer pattern and its implementation for weeks now, but this video finally made it click for me! Thank you so much!
Using UnityEngine and Using System can lead to ambiguous references. I.e. if you are using Random.Range you will get the VS error "'Random is is ambiguous reference between 'Unity.Random' and 'System.Random'". To fix this, declare which method to use, i.e. "using Random = UnityEngine.Random;"
Thanks a lot for this Tutorial. I tried implementing the Observer Pattern in my Project and an error was driving me nuts: Argument Type "void" is not assignable to parameter type "System.action". Turns out I forgot that you have to omit the parentheses () when subscribing the method to the delegate, haha😁 Just putting this here in case someone else is having this problem.
I like the way you break design patters down into crisp and clear examples. I think your lucid explanations will be a watershed moment for many. Bravo!
Great explanation, I've been using observer pattern quite often now...but I still suffer from understanding one simple thing: what is the actual difference between writing "public static event Action OnThisThingHappen;" and "public static Action OnThisThingHappen;" The last one is without "event" keyword. I use both and cannot se the difference... What's the practical benefit of using "event" in this specific case? (given that there is already an "Action" which does the same thing as for me)
The keyword "event" puts restrictions on what other classes can do with the action. Without the event keyword other classes could invoke the action - which I generally don't like. Also other classes can assign a function, not just add/subscribe a function, to the delegate this would effectively unsubscribe all other functions. Again, not something I want to have happen.
I somewhat get the concept but still can't understand the implementation so in the CritterDisable class you use Ondisable function to invoke whenever the object is disabled but are you disabling the Scoredisplay to unsub as well? I mean I get it almost every single example has OnDisabled and On Enabled function but what are we really disabling in order to unsubscribe is it just convention? that part confuses me. Second part that I don't understand Is all the functions subscribed to event called at the same time, or is there one main function that gets triggered when subbed functions called by their own? if so...(brain melts) anyway I give up :) I think this is one of those limits that I have but thanks your video was the clearest explanation among the tuts I've seen.
This is definitely not an easy pattern to grasp and the notation and implementation is about as clear as mud until it clicks - I found it really helpful to make a video about it ;) In all seriousness, the unsubscribing in an disable function is to prevent errors from being thrown. If you don't do that and the object is destroyed an error will be thrown when the delegate/event/action is invoked because the object that is subscribed is null (i.e. destroyed). Using the OnEnable and OnDisable to subscribe and unsubscribe is a way to ensure that when the object is on it's subscribed and vice versa. If you have multiobjects (functions actually) subscribed to an event they get called in the order that they subscribed. It is very hard or nearly impossible to control the order that they are subscribed and thus called. I think of a delegate as a list of functions. When an function is subscribed it gets added to the list. When the delegate is invoked it simply goes down the list and calls each function in the list - I envision a for or foreach loop iterating through the list of functions. Lastly, on the critter script the reason the "critter kill" action is invoked in the OnDisable is because when the critter is killed it's turned off. So invoking the action there is the "safest" way to ensure that it gets called when the critter dies. It could also be called by the object doing the killing, but for me that's not a super clean implementation. This way no matter how the critter "dies" or is turned off the action is invoked. Hope that helps a bit :)
@@OneWheelStudio Thanks a lot definitely helps a lot it cleared out lots of questions I had, still confused about subscribing and who is doing the listening but that's on me :). also one last question for the last part of the video you declare the critter kill action in critterdisable class, wouldn't it be better approach to declare it from the showscore class (since its managing the UI related stuff) and subscribe to that event from the critter because lets say we have other type of enemies to kill wouldn't it create more separate actions to subscribe for Showscore class?
This is better than many paid udemy courses. I would like a video about assembly definitions, especially how to use these in a complex project. I keep getting stuck with cross referencing..
excellent explanation, thanks! I had to run it multiple time at half speed to have a chance to grasp all of it (...I'm a little slow :-) but I managed to get a better idea about the the concept in the end.
Thank you so much for explaining this, I've been using Events for so long but never really understand what it does. After watching this video, all my codes are now very visible
Great video and well explained. But as i'm an idiot, i will need to watch it at least ten times! So, for the rest of the day, i shall be doing just that, as well as attempting mock ups. Wish me luck! Update: I finally get it! After all these years! How i lived without them is beyond me. Can't thank you enough! Thank you for this.
I'm a programming student looking to get into game dev. I've been looking to learn the basics of data movement in Unity and this is soooooo good. Thank you! Edit: also my head was spinning the whole time watching this video but I took notes and it's actually super easy once it clicks. Thanks again dude! Subbed
I'll be honest as a person who already understands this, I know the very recent me who didn't understand would not have understood based on this video - I can't say what made me understand delegates, actions, func and so on but things just got very clear. I'll try to reiterate what was said here in a way that I feel I would have understood: Delegates, func and so on use subscribers. Think of it like subscribing on YT and hitting the alert icon. When you do this you are an observer, when the subscribed channel posts something you are alerted and take actions or not based on that alert. With that said you C# class that will be observing a particular thing needs to subscribe first. Generally the easiest way to do this with maximum decoupling of the code is to make a public STATIC class. In that class you write out all of your invoke situations so: onCritterDied or onPlayerJumped and so on. They should look like this: public static event Action onCritterDied; Inside the you can put variables and classes which can help identify or carry over data. So: or , the overloads goes on for a while so is all possible. Using a Func allows for the same stuff but you can also add a return type which is always the last overload variable. So say you had: var item = StaticClass.SpawnBullet(bulletPrefab); The static class would have: public static event Func onSpawnBulletRequest; public static void SpawnBullet(GameObject bullet) { onBulletSpawnRequest.Invoke(bullet); } This is a good way to communicate with a pooler that you don't want to reference from any other script. On the pooler you just OnEnable or Start or Awake put: StaticClass.onSpawnBulletRequest += DoSpawnStuff; Be sure to unsubscribe also, hope that translated things for someone.
I'm a seasoned dev, although I mostly focused on web solutions. I've had done a few test projects in Unity and made a few playable demos, but what I'm having the most difficulty is structure, from assets to code. I thing I noticed in your video, it looks like your scripts are very "atomic" What I'd do probably is have some kind of critter class that handles everything critter related, including it's disposal, but then I'd struggle connecting any kind of events there. I can see benefits and drawbacks on both sides, but which approach would be better in general?
With a delegate you're replacing the reference of a component with a static class reference. If you were to delete the class, all those that subscribed to any delegate in there will throw up compiler errors. It hinders refactoring, this is not much better than before. That's where UnityEvent comes in. When a critter is killed, a UnityEvent is raised. the "coupling" is in the scene instead of code. Then there's also the Scriptable Object event pattern. A talk given by Ryan Hipple explains this. I'd prefer UnityEvent over the use of delegates. Scriptable objects takes it a step further but that could be messy for the project files. Which is why I personally use a combination of both. ScriptableObject if it are many objects (or dynamically instanced), UnityEvent if it is only a few (non dynamically instanced).
Sebastian Lague's has it's entertaining strengths, but explaining code is not one of them. At this point i have seen my fair share of RU-vid tutorials about events and what comes arround it but this one from One Wheel Studio is one of the best in explaining it clearly, only do i wan't to give the advice to wave your hands less while explaining. I hope you find a monetizing way to develop yourself further in this area!!! The other youtuber which does a decent job about events is Infallible Code.
"Delegates can be thought as a variable that can be assigned a function as a value." That's the conclusion I finally figured out after watching a bunch of other tutorials on youtube. I wish I watched this video earlier and didn't have to figure this out myself! But I think that statement could be put a little bit more precisely: A delegate is *the class* of a variable that can be assigned a function as a value, while an event is the actual variable of that class (though it's not just a regular variable, but a collection of that class).
I'd be a bit careful with that definition... as long as you can use them that's way more important than the definition... but "event" is a keyword that puts restrictions on the delegate.
Hey, wanted to say that this video has been very helpful for me so far, I've been getting back to this video frequently Now, recently I noticed something about actions which I think might have been a big misunderstanding on my part. Whenever I heard that they helped in decoupling the code I thought that meant that if I called an action on a class, eventual errors on other classes that were listening to the action would not pass on to the class calling the action, but I see now this is not the case. In my game I have a static action called by the enemies when they die, and the UI is listening to this. What happened is that when there was an error on the UI itself when trying to execute on the listened action, this error would propagate back to the enemy, which in turn would not die because it got an error before the destroy gameobject line. So I wanted to ask, is there an implementation for the observer pattern which stops the error from propagating back?
I'd want to see the code! An error in the listener should not cause the event sender to stop functioning. Unless the event sender is also dependent on the listener. Which is definitely an issue and sounds like a problem. Basically, events should be "fire and forget" meaning whoever is invoking the event doesn't care if anyone is listening. If that's not true then I'd argue it may not actually be the "observer pattern." Happy to take a look at the code. Jump over to the OWS discord (link in the description) and ping me.
I think your code execution simply stops because of the error, so it doesn't continue with the enemy. Sounds simple but you need to make sure there are no errors in your UI (or anywhere else). You can use things like null checks (with debug warnings) to account for unexpected behavior so at least it doesn't break the code execution.
FINALLY! A video that explains it in an understandable way and a reasonable amount of time without pouring unnecessary code into the examples. You've got a new deserved subscriber!
I think that this "simple implementation" is somehow misleading. The different classes are not completely decoupled as you still have to use references to subscribe / unsubscribe to / from different events. For example, if you remove or rename the Critter class you will get errors in all your subscribers.
Dude! I've been trying to make an Action work for like, 30 minutes, and 5 minutes of your video solved my problem!!! Thanks a lot! Keep up the good work! Liked and subscribed!
Ya know, I had to watch this a few times to really understand it, but this absolutely blew my mind on just how simple and effective it is. Outstanding explanation ;-)
Thanks! this one got some time to enter in my head, but after this video, Sebastian's one and a few others also, finally think I got the delegates stuff.
This makes perfect sense but I have one question. Should you only use events if the event has more than one function subscribed to it? As in, if the event is raised and is only calling one function when doing so would you not be better off just calling that function seperately in another class through a reference or static call? Please answer because I'm working on a team with a few others and I'm using events to call single functions. The only explanation I can give to them why I'm doing so is because of tidyness and so that I don't run into spaghetti code. However, they disagree and think using events in this way just over complicates things.
Hey there. Maybe this will help? At the end of the day events are all about de-coupling code which is huge if a project grows beyond a small prototype. I'd argue even a small game jam prototype is big enough to benefit from events. Sure, if only one function is currently subscribed that might feel like extra work to add events. But is it? If you call a function on another object it needs to be public. It can be static but that doesn't always work for a given situation. It can often require many variables to be static or janky hacks. Having too many public functions is NOT awesome and can cause headaches and more work down the road. Things should only be public only if they NEED to be public. If the function isn't static then you have to get and often cache a reference to the object that has the function. Yuck! I avoid this whenever possible. Notice above I said functions "currently" subscribed. Events are amazing time savers when you have a new idea or create a new system and discover it needs to have a connection to an older system. Adding features is SOOO much easier if you are using events. Simply subscribe to what events matter and you are done. You've add a new mechanice or system and none of the old systems care. No changes to old code needed. That is unless you don't have events in which case you have to go edit old code and find the right place to call the public function on the new system. Are you really telling me no one is going to try to add a new idea. I call BS. Same idea in reverse if you rip out a system. If you are calling public functions on that system you now have errors to clean up. If you were using events - it's generally way less of an issue. Events and other programming patterns aren't always about what you NEED right NOW but are about future proofing your code and making tomorrow's programming easier even if that means today's programming might be a tad slower. 100% folks can over engineer code, but using events is not one of those instances. All that said, events can go to the dark side. If you have events that call functions that also invoke events than call functions that invoke the original event. Yikes! I've been there. Death loop!!! The other potential issue is you can't realistically control the order that functions subscribe and thus get called. Both of these issues, in my experience, can be engineered around or avoided with well thought out structure. Hope that helps. If it doesn't... Call them big dummies and tell them your dad can beat up their dads. I guess I'm feeling sarcastic?
@@OneWheelStudio thanks so much for your answer, it has really helped a lot!:) Basically I have a singleton class that contains all my events. I then have subscriber classes that add their functions to these events. Finally, I have additional classes which actually call the functions from the main singleton class which raise the said events. My team doesn’t like the fact that they have to jump between different scripts to figure out how everything works. So I’m wondering if that’s expected when working with events or if I’m using too many classes and just following the observer pattern incorrectly. Any feedback is much appreciated by the way:) I am relatively new to using events and do like them as I have ran into spaghetti code before and they really seem to prevent it from forming.
Okay, that does sound a bit complicated and I think misses out on the de-coupling that is possible. In my opinion the events should be in the classes that would invoke them. For example, if there is an EnemyDies event it should be in an enemy class. Subscribers to this event (UI or SFX for example) then directly subscribe to the static event of EnemyDies in the Enemy class. No singleton. No functions to invoke. The Enemy class is fully 100% in charge of when that event gets invoked. This is a key reason to use the event keyword - only the class with the delegate can invoke it. Wrapping an "event" in a public function defeats some of that purpose. It can also be a good practice to send a reference to the invoking class with the delegate. This way when EnemyDies is invoked all the subscribers can check which enemy or what type of enemy died (if necessary).
great video, I have a silly question though, why would you want an Action or Event to be static if they already broadcast and any subscriber can subscribe to it without them being static? I am not getting that
Being static means there is only one action/event of that name. It also makes them easier to access as you don’t have to get a reference to a particular object. There are cases where I have made actions not static. That was when I wanted a particular object to broadcast or I wanted to subscribe to a particular object. For example I had a bunch of spaceship chunks and I wanted to know when A particular one was damaged.
@@OneWheelStudio Thank you for your reply, I can't wrap my mind around it, why would you want to access the Action? I thought the whole idea of using an Action or Event is they broadcast to subscribers so subscribers don't have to access it! no ? I apologise I am new to this , can you give an example when you would want to access an Action ... thanks a lot
@@Berndr I should have said "subscribe" instead of "access."To be clear, making an action non-static is something I very rarely do and coming up with a decent example isn't easy. A key piece here (I think) is understanding what the keyword "static" does. If an enemy script has a static variable for health, then all the enemies share that variable or in other words have the same health. If the variable isn't static (which would be the normal way) then each enemy would have it's own health. It's similar with actions. Let's imagine you have a game where you wonder around and "make friends" and you want to stay up to date with what's going on with your friends. So when you meet a new friend you subscribe to some of their actions for example "ateGoodMeal" or "madeNewFriend." Also imagine that the function that is subscribed simplify prints out a message or provides some notification. If this action was static then whenever ANY possible friend, even if you haven't met them, in the entire game ate a good meal the message would print out. You know someone had a good meal, but not who or even if they are your friend. Not the best, potentially confusing and maybe almost useless. Now if that action isn't static, then you're subscribed to the action from YOUR friend. Which means you will only get notifications or messages when YOUR friends have a good meal. Much more useful! This concept is not easy. Hope that helps a little. :) If not or you just have more questions come on by the OWS discord (link in the description).
Wow, finally I understand the intricacies to "delegate" because you started slowly at the base. You have a real talent for explaining complex things (as I have seen in your other videos), thanks for your effort!
I define it as just “public static Action myAction;” and this way I can access it from everywhere I want. But what I couldn't understand in the video was why you also add the keyword “event” before the “Action”. Isn't an action also an event ?
Adding the keyword event restrictions what can be done. If it’s an event you can only add += or subtract -= subscribers. Without it you can set the subscriber with = and override or remove previously subscribed functions. Also you can invoke the action from another class unless it has the event keyword. Hope that helps.
I've seen several of your videos but this one got me to subscribe. I'm a beginner so I need this simple explanation style and throwing a shout-out to Sebastian Laque was most respectful. Good Job .
bro im tryin g to make a gameObject play a certain animation when the player boolean isOnSprint is true. Should i use Func in this case because i want the class to notice when this boolean is true or false and from there play the animation feedback.
It's a bit hard to say without knowing how it's all wired up, but I don't think you need to use a Func. A regular event or action should do the trick. An action can send a parameter.
wow this was great. You are a great teacher and use great examples! It's very cool you explain WHY this pattern is used and what it protects against. Sometimes it's the "why" that is missing in tutorials. The "why" makes the pattern stick! Also, thanks for the words of encouragement throughout the tutorial. =-))
Hmmm, I have one further question about the Events system (sorry if it's been answered below). Say I have a prefab, e.g. a Wave gameobject, and at runtime I instantiate 10 Wave's, each with its own ID. In my system, other gameobjects are only supposed to observe one of the 10 Waves at a time. Is this only possible with GameObject.Find("Wave" + ID).GetComponent(), etc, etc? Or would such a thing be possible with delegates and the events system? Thank you in advance!
Events are amazing and game changing once you start to use them. One thing to watch out for is events invoking events. Meaning if one script is listening to an event and then calls a function that itself invokes an event you can end up with crazy loops - to the point of locking up the game. Also if multiple systems are listening to a given event you can potentially end up with "race conditions" where one system is responding before another - I've seen inconsistencies between the editor and a standalone build in this regard. Those aren't reasons to not use events - they aren't perfect - but in general definitely better than singletons. ;)
Ive been learning to Code with AI and this video cuts straight to the heart of what I've been tip toeing around. Amazing video, this has changed everything. Subbed
Woohoo this is super precise and informative! Through your video I'd attained 90% clarity, with the remaining 10% that is still puzzling me is the "Eventhandler" and the "Eventargs", much appreciated if you can explain their usage within the Event System context.
I've been working on a game for a year and the coupling has gone out of hand. I've been trying to understand the observer pattern for a few months and I think the critical issue for me was public static variables. I have a CS degree and they drilled into us never to use public or static variables. My project references every other class directly, which has turned into a nightmare for super classes like the game controller or UI. Your video really helped me understand actions and events. I'm going to rewrite my project with this pattern.
