Events or UnityEvents?????????

Get the Source Code - bit.ly/3bvPaMu
0:00 - The Question
0:27 - Your Preferences? (don't be shy!)
0:46 - Demo (what the code we'll see does)
1:40 - Unity Scene Setup
2:07 - Collector.cs c# code
2:48 - Reference to - • 6 Useful Unity3D Thing...
2:54 - UnityEvent Declaration - OnCompleteEvent
3:18 - Adding or Registering UnityEvent Handler Callbacks
4:55 - Enabling another GameObject with UnityEvent
6:43 - C# Events (Delegates / Actions)
7:18 - C# Event Declaration - OnPickup
7:57 - Invoking C# Events (and null events)
9:12 - Handling Event Callbacks & Event Parameters
10:26 - Invoking UnityEvents
10:50 - Adding More UnityEvents
13:00 - ContextMenu Shortcut to save time
Learn the difference between c# events and unityevents. When to use each, how to use them, and what they're best at.
My Courses - bit.ly/321z4XZ
Join the Group - unity3d.group
Patreon - / unity3dcollege

[@christianconnolly1296]

What have you named the cactus behind you?

[@Unity3dCollege]

Wow... now it needs a name. It has xmas 🎄 lights on it... anyone have suggestions?

[@christianconnolly1296]

@@Unity3dCollege Pokey Joe?

[@ccristian1715]

@@Unity3dCollege GameObject :D.

[@alexanderlogunov5147]

@@Unity3dCollege newgo I guess (from new game object)

[@vladrootgmailcom]

@@Unity3dCollege Coollider? :)

[@thewhiterabbit4268]

We usually use C# events when designers are not supposed to touch or change things (C# events is more natural for our coders workflow and keep it scale-able easy), when ever there's a script where 3D-artist / Designers need to handle their stuff we go for UnityEvents, you teach them quick how it works with +/- and in which order it executes, saves time for our programmers.

[@CamoflaugeDinosaue]

Always answering the good questions the most people don't even know to ask.

[@user-pg5sz2vn1w]

i recently learned how to use the new input system with the input action call back (which sends out a unity event) and i love it. i can definitely see how using that same system for other things would be super handy.

[@Stevedeniese]

This is literally the video I've been looking for for the last couple weeks. Perfect explanation between the use cases, did not realise you could pass parameters in a delegate, so that completely changes my understanding on how delegates work for the better!

[@HadiLePanda]

Really love the improvement on the tutorial presentation, really clear and visual now with the images & rectangles! The concrete examples also make it easy to understand and visualise the knowledge. Good job and I'm really excited for future tutorials of this type :)

[@abnejne4737]

I have been working with Unity for a couple of years now. And been working on a serious project for about a year, but it's like I still learn something new every time I see one of your videos.

[@WilliamB383]

Great Stuff Jason! There's a lot to unpack here but it was all presented clearly and simply. You nailed the difference between C# events and Unity events for me. You also provided answers to questions I did not even know to ask. Thank You

[@raianmr2843]

For people having issues because of the light theme: try to keep a light source behind your monitor and always follow the rule of "light themes in lightened rooms and dark themes when in dark rooms". I know this is super-obvious but way too many people ignore these for whatever reason and have absurd setups that maximize eye strain.

[@0xF81]

Weird, I'm using black themes everywhere even though my room is always lightened

[@chazlewis8114]

Omg, all your vids have been so helpful but this one is an absolute godsend for me. You deserve a medal dude. Thank you so much!

[@bahtiyarozdere9303]

That Context Menu Help was amazing. Thanks a lot!

[@vladrootgmailcom]

Great topic. Myself use System event all the time and UnityEvent when it comes to UI - all the UI elements normally have a lot of predefined events and event system itself goes very smoothly with UI.

[@unitywithzaher1374]

The context menu is the most grateful thing in this video man it could save you a lot of time! thanks for this valuable information

[@nikodemos71]

Completely agree, I was mind blown seeing, I knew the "dumb" way of dragging everything to your list had to have an optimization, just didn't knew what it was xD

[@studentofthecraft]

This is why I recommend your channel to everyone in my office. Great stuff !!

[@aoberthuer]

These videos are so helpful! There are so many ways to achieve things, it is always difficult to decide which approach to use. Mostly so, because it is difficult to find clear advice on when to use which approach and which not. Great!

[@MattRaffel]

I wish more people make videos like you did. This was will organized. Audio was good and clear. Thank you.

[@Luciphear]

Thank you for this video! Been toying around with collectibles and this definitely opens up a lot of ideas of how I'd like to set up a few things in my project.

[@Chronomatrix]

Recently learned how to implement an Event Bus Pattern and I'm in love! What a beautiful thing! I don't have to worry about dependencies anymore.

[@TastiHam]

You can actually multi-select drag and drop onto an empty list to fill it

[@bayrock1337]

I didn't know you could add functions to the ContextMenu, so I found the example to be useful.

[@user-gl1ls1jx3h]

Note that selecting one or more objects will change the inspector, so lock it (icon on top right of inspector window) if you want to multiselect + drag

[@thepolyglotprogrammer]

I love the tips about enhancing developer experience and editor improvements. Good job buddy!

[@IAmLonegamemaster]

After searching half the day this video is what finally helped me solve my problem. Thank you!

[@phillipeaugusto1637]

Thanks for this video Jason.

[@JayadevHaddadi]

I love that you shared the code for this! Thanks Jason:)

[@johnhauge2178]

I am building an interactive book for a theater, and it's littered with custom events, considering I didn't even know about events, this just made my life so much easier!

[@ZackDaly]

Jason! Thank you for another absolutely stellar tutorial. The education you've given me for free on KZbin is something I will always be grateful for. I hope someday I'll be in the financial spot to pay you back but, for the moment, thank you very, very much from the bottom of my poor heart. Haha. THANK YOU, SIR!

[@jarvisx8666]

Hey Jason, thanks so much for these videos. I'm super green when it comes to Unity so your knowledge is very much appreciated!

[@somewhatjp]

i never used UnityEvents but this was super cool to see a simple example that uses BOTH (since i feel like ive seen so many examples of just explaining one or the other) made total sense, thanks :)

[@aaronroot2172]

I’ve only used unity events before this video. I’m pretty code savvy so I’ll probably be using “regular” events in the future, as it sounds better. Also that data context thing you had seems super nice and very helpful (the code part at least)

[@epsil2511]

usefull, clear, short, just perfect as usual!

[@RenegadeVile]

Common C# convention is to use EventHandler or EventHandler as your delegate, instead of Action. Both work, of course.

[@raianmr2843]

C# is way too general-purpose for opposing conventions to come to an agreement. In case of Unity, almost everyone and their moms are using Action over EventHandler unless they have reasons not to. Nonetheless, it makes more sense to set conventions project-wise and have simple guidelines language-wise.

[@RenegadeVile]

@@raianmr2843 This must be a personal experience-type situation then, because I've seen EventHandler used far more than Action personally and in code snippets/articles online. I do agree it's just something you and your team need to decide on for consistency's sake.

[@flaviorodriguez8594]

awesome video, thanks for this Jason!

[@Impossible_Object]

This was super helpful. thanks!

[@manuelmanteconpolo6776]

This kind of videos are really useful thank you so much

[@samiatailia3394]

Thanks, This quick cours helped me a lot. Looking for more new lessons.

[@falconerodland]

this was very helpful, thanks!

[@simoncodrington]

Great explanation mate.

[@StephenWebb1980]

Very helpful. Thank you.

[@olegmagarill1320]

Thank you for this tutorial, I really like what are you doing, you helped me alot!)

[@muzboz]

Awesome, thanks Jason! :D

[@crinklecutchipscringe9167]

To be honest, I keep forgetting how to use events so that's why I'm here xD

[@halivudestevez2]

I was coming for the idea. Before the video as a c# developer, would do most of the events with c# events, except visual events, or gameobject related events. Now lets see the video.

[@LukeClemens]

Great video! You should also mention that Unity events are 38x SLOWER than C# events. That fact is no big deal for most things that events are used for, but if you're going to be firing events rapidly in an update or something, at 38x factor could certainly be noticeable.

[@AvoidingCrisis]

Hi Luke! Do you know where I can check the performance difference? Is it in documentation or an empirical test? Thank you very much for the help

[@sergiorodrigoroyo5079]

This video was really high quality in all aspects. Crystal clear explanation with good editing to highlight how the code relates to the editor. Fairly clean code that reflects the fact that you've done business software for a while. I think you talk a bit too much on some other videos I've seen, meaning that you could be a bit more concise. But this video was amazing. You've got a like and a subscribe :) Keep up the great work.

[@CarstenGermer]

I usually start weighing the decision for Unity and regular events by 'Does level building need to change what goes on here?' If not, regular C#. That in mind, C# events make it easier to add similarly behaving types of objects later. Plus, for bigger projects or projects that may grow more complex in the future it's cleaner and very convenient (later) to have one general or multiple specialized 'event handlers', which can be neatly done with C# events. You can bind events via an event handler easily to Unity objects or UI elements using the editor and with some experience you will create a mix'n match between the two that has projects easy and clean to extend in code or levels.

I think a nice addition to this comparison would be UniRx too, great content :)

[@skizooooooooo]

Great editing!

[@aiartsev]

I think we could've used a discussion on performance and architectural considerations for UnityEvents vs Events. In my team we've moved away from UnityEvents for everything non-UI in order to keep our business layer better separated. Also I think we could benefit from a discussion on the differences of declaring Actiton versus event Action as both are technically possible to use.

[@SunnyValleyStudio]

That is a great tutorial! One thing I wish it had was the difference between "event Action" and "Action" delegate. From what I understand the difference is the "event Action" protects us from setting the OnPickup = null and prevents other classes from calling on it ".Invoke()". In any case great tutorial! I have learner a loot! Thank you for making it.

[@MasterofGalaxies4628]

As I understand it, the "event" keyword lets you register multiple functions to whatever delegate you're declaring so that they will all run when the delegate is invoked. If you don't have that keyword, I think you'll only ever be able to register one function to a delegate at a time (though I'm not quite sure I have that completely right).

[@brownkathy2158]

I use static events(Actions) in the code to decouple the ui from the respective classes, for example an OnScoreChanged event that will notify the UI text, or OnHealthChanged for the health bar. I UnityEvents for things that I want a game designer to change easily and also when I am creating menus for the game. This way I can say that when you click 'Options' you disable 'MainMenu' and enable 'Options' game object.

Nice videos!! Thanks

[@infokubarcade4510]

Very nice things. I completely forgot UnityEvent exists, bc i didn't have the needs but it's very nice. I understood in your other answers why you didn't unsubscribe, so ok. The final trick is amazing, i never use ContextMenu stuff, really useful ! So yeah, i learn't quite a few things here ! And i'm super glad you use the things you said in your previous videos !! The list serialization and the $ quote ! Amazing !

[@zimaml4661]

Greate Thanks Jason

[@vladimircuraciov]

Thank you!

[@williamleebuckley]

One thing I've run into, not so much a problem but an FYI. If I rename a UnityEvent in code, it clears my editor assignments to that event. Done that during a few refactors where I didn't remember what had exactly been assigned. Version Control makes it possible to double check, but I definitely find that to be a weakness of editor-assignment vs code, for what it's worth.

[@Unity3dCollege]

this is one of the biggest issues I run into as well :)

[@kordeyrow]

You can use the attribute "[FormerlySerializedAs]" to prevent that. blogs.unity3d.com/2015/02/03/renaming-serialized-fields/

[@williamleebuckley]

@@kordeyrow Good tip, didn't know that. Don't know that my OCD can abide that, but still really good to know.

[@kordeyrow]

@@williamleebuckley I dont know if I undertood right what you meant. After renaming the UnityEvent you can remove the "[FormerlySerializedAs]" atribute.

[@diliupg]

Good stuff!

[@vordrax1014]

I feel like the editing, sound quality, and overall quality of the videos have been steadily improving since I started watching. It's awesome to see. Good video as well. I don't know if you're allowed to talk about it, but does Pantheon use C# events or Unity Events at all? If so, what's the general mix?

[@pt8306]

I'm the same. Most of my objects have some sort of C# event on them, and this is great for doing things like telling all objects in a raycast to execute their "Hit" function (although this doesn't need events, delegates or interfaces will do fine), or for subscribing to events that need to be watched closely (such as an inventory UI needing to update itself whenever the OnItemAdded event is triggered by a linked inventory). Overall, C# events are my go-to rather than UnityEvents, and are great for controlling functionality between 2 items where the link between them is known at creation time (like two objects that will ALWAYS interact with each other). Another thing you might want to do is wrap a C# event inside a ScriptableObject, as a "Event Object", and let your objects take them as parameters. This lets your artists do things like use the asset menu to create a "GameOver" event, then you can have your GameManager cann that GameOver event (referenced in the inspector), and then other objects that are completely unrelated can simply take an Event in the inspector to listen to it, which gives good-quality event control similar to C# events, but allows you to use the inspector.

[@sannanch7564]

Awesome Video Thank #Jason it helps me a lot in my project

[@MasterofGalaxies4628]

One blend of both events I hit upon not that long ago is wrapping a UnityEvent with a C# event like this: [SerializeField] private UnityEvent _someEvent; public event UnityAction OnSomeEvent { add => _someEvent.AddListener(value); remove => _someEvent.RemoveListener(value); } The specific implementation I used this for was a character prefab death event, so that stuff like Animator and ParticleSystem manipulation could be set up in the Inspector easily while also allowing the decoupling, strong typing, compile-time safety, and most of the other benefits of a C# event for anything external that might need to care about an event you could probably otherwise write as a stock C# event. I do want to emphasize that this was for a PREFAB, i.e. something that probably needs to be built with independence of any specific Scene, as opposed to a level-specific event like in this video. Honestly, though, I feel this particular setup, so long as it isn't overused and abused, is a pretty strong and durable architecture for marrying the benefits of both event types.

[@ironbard4901]

Beautifully written and thought out reply : D

[@hedgeit]

Thank you a lot :)

[@dsoft3131]

Hey jason great video like always. Do you think using unity events is bad idea for mobile game? Unity event performance hungry then regular c# events?

[@mudumbiarun2926]

Hello you are a pure teacher just like my dad he teaches Botany mostly Plants Science and you teaches Computer Science Nice to have a teacher like you Got to know about how to trigger Unity Events

[@12apidxHDxGamerx]

Hi Jason and/or Jason’s community. I’ve recently decided I’m going to get serious about learning game development and I’m going to start with trying Unity. Literally all I know about code is the small random bits I’ve picked up from watching random videos from this channel. I really appreciate your videos, man. My question is, are there some more specific videos here you would suggest a complete and total beginner to watch to get started? Especially interested in any videos that cover fundamentals and good practices to have from the start. Thank you so much!!

[@12apidxHDxGamerx]

Okay...well. My first step should have been checking the play list and seeing “beginner? Start here” LOL I swear I always forget KZbin playlists are a thing for some reason. Still would appreciate any recommendations though, thanks all!!

[@nemanjasekulic711]

tnx for youre video!

[@darkmaigo]

Both are great I can't decide on one .. I bet I'll use them both

[@Ivan_Helsing]

Hello. Wery useful explanation. Thank you for that. You realy make good quality explanation video. It help me with many thinks.

[@ShawnBlais]

I think this misses the main reason you use UnityEvents vs Events which is an architectural one regarding coupling. UnityEvents (that are configured in the GUI) reach outwards into the app and execute methods, and are tightly bound to the scene graph. Events dispatch things blindly, and someone from above must subscribe. This is the first fundamental difference. The second is that UnityEvents force you into the Gui, which is more suited to non-coders. So basically for me, I see UnityEvents as generally an architectural anti-pattern, but recognize that for beginners, or non-programmers, they are might still be the best approach. As a developer myself though, I literally never use them, too hard to maintain, and you leave your compiler in the dark... ie I can't trace back to who turned something off, or called some method, cause the call binding is buried in some component somewhere. If you set up too many of these "game objects calling business logic" things in your scene, you project will turn into spaghetti really quick.

[@uweeby69]

Unityevents don't force you into the gui. I use them from code only often.

[@ShawnBlais]

@Jacob Ya that definitely is not so bad, as at least it's usually a local connection, like the child is directly connecting to parent. Doing that's in the Scene Gui is not going to bite you too often, though still pretty easy for that link to get broken, and you don't notice. If you wire up a listener via code (button.onClick.addListener), you'll usually get a runtime error if anything is wrong, which is preferable to the silent failure of some fxn call just not being made. So I prefer to just grab a reference to the btn in my view controller and add the listener: * Will throw RTE is btn is missing/unlinked * No hidden dependencies/connections that are not visible to compiler * Compiler can always trace back the caller of some important fxn (ending up in your view controller, and not some generic btn) * Less fiddling with massive dropdowns and finnicky gui * More consistent. When you have to use UnityEvents, they act like your other Events in the app. Don't need to wonder if something is mapped in Scene or Code, it's always Code.

[@ShawnBlais]

@@uweeby69 Ya that's a good pt, they don't force you into it, more like they have full GUI support which is better for those non-technical users, where Events can only be used through code.

[@muratcanagic]

@@ShawnBlais so you say i am a master coder and screw you. Unity Events offers both and Events are for only coding, so Events are better?

[@Norivee]

@@muratcanagic Unity Events are better in every way except for performance basically. So if you call an event pretty often, you'd probably want to use an Action event.

[@alikhodaparast1978]

Hi, Thanks for nice Contents :)

[@capdim4739]

I use them pretty much exactly as you describe. 95% of the time I use c# events and only use unity events for very specific one off things that happen in a particular scene so you dont have to clutter code for little edge cases. My only problem with unity events is its easy to lose the serialization on the call backs and that there is no compiler feedback, so I use custom attributes on anything invoked by a unityEvent and a little hacky editor script that lets me see all of those things, as well as logging out everytime a unity event is called and logging out the method name. Useful for when you come back to a scene after weeks and unexplainable things are being called lol

[@alexchacon778]

"Work Hard and Be Nice to People" What a great slogan.

[@Unity3dCollege]

Ya when I saw it i had to grab that thing :) great daily reminder :)

[@frankzander5946]

@@Unity3dCollege Yeah I like that moantra too: shortened it for me to "work hard, be nice" ...easier to say to myself ;-)

[@frankzander5946]

mantra i.e.

[@willpetillo1189]

When thinking about what type of architecture to use, I find it helpful to think about the relationship between the objects along two considerations (1) is the connection a fundamental dependency between the objects (coin always affects text or text always listens to coins) or incidental to the context (a design choice for this scene, maybe different later)? For brevity, I call the former "code-based" and the latter "scene-based". (2) the direction of dependency relative to the direction of the flow of logic. That is, if A happens then B happens: is A dependent on B, B dependent on A, or A and B both dependent on C (which also knows about A and B)? Combine these considerations and you have a 2D graph. Code-based, A -> B dependency = your standard Component.Method() call. Code-based, B -> A dependency = C# Events. Scene-based, A -> B dependency = UnityEvents. Scene-based B-> dependency = those ScriptableObject events that Ryan Hipple talked about in that Unite Austin 2017 talk (or something similar). Code-based, A, B -> C = statics. Scene-based A, B -> C = Singleton. Personally, I find A -> B dependencies much easier to follow (since it matches the flow of how things happen) and use that pattern by default unless there is a compelling reason to reverse it. Also, I prefer creating reusable tools over project specific code whenever possible and making connections on the scene level, rather than hard-wiring them into the code, lends itself better to tool development. Between these two preferences, I use UnityEvents a lot. There are downsides, but most of those are fairly easy to overcome: ScriptableObjects for non-serializable static arguments, a helper script with serializable classes for all the commonly used dynamic arguments, and then writing custom scripts with standard, code-based dependencies when UnityEvent lists start getting long and including lots of related items.

[@paulkohler8868]

I use C# Events a lot for modular sorts of subscriber patterns. Very recently, I'm exploring adding UnityEvent fields (with very specific T0, T1, etc) to some scriptable objects to see if it's a viable way to expose ability scripting to a designer.

[@y01cu_yt]

Thanks!

[@summerWTFE]

Love the Thumbnail 😁

[@trinosan]

Reminder that it's good practice to unsubscribe from events when destroyed or disabled Also, in some cases you could have a public *static* event on those collectibles, so you only need to subscribe once

[@Unity3dCollege]

Unsubscribing is definitely something I shoulda covered :) Making them static may cause an issue though if we wanted to have multiple collectors collecting different things. But if that's not the scenario then there's no reason it couldn't be a single static subscription instead of all of them in a loop, great point :)

[@frankzander5946]

@@Unity3dCollege I always make sure that the subscibe stmt is adjacent to the unsubscribe to make it easy to track if I missed some anywhere. something like this: // delegate to collect everything we need to de - register on Destroy... private delegate void Dreg(); private Dreg dreg; private void Awake() { // register for the event and create an entry in the de-register list //for later execution AttackSubEvents.NewThustTarget += SetEngineThrust; dreg += () => { AttackSubEvents.NewThustTarget -= SetEngineThrust; }; } void OnDestroy() { dreg(); }

[@andersmartensson8659]

Used a lot of UnitEvents with scriptable objects (like in the famous video describing the method), but transferred to mostly C# events. It became a mess with many scriptable objects, and what you pointed out, when changing or editing in the Editor, such connections can be forgotten. With the switch to C# events, you have it all in code, don't have to remember setting it up in the editor again. However, it seems like I'm moving towards some "C# event manager", like Game Manager, but for events, with public callable methods, so other classes can invoke the events. Don't know if this is a good way forward though.

[@PhoenixTheGame]

Basically Delegate events: listeners are hooked up at run-time and the other classes has limited access to the listener list and cannot invoke the event or remove all listeners so that they are protected from sabotage by other classes Unity events - listeners hooked up at design-time or run-time, other classes have somewhat limited access to the listeners list and can invoke the event and remove all listeners Performance Comparsion For 10,000,000 Invoked Events Turns out that Delegate Events are 38x times faster than Unity Events Personally i recommend delegate events for organized structure & better performance

[@NaejDoree]

you can also hook up stuff in code for unityEvents too with AddListener/RemoveListener (and that's why I only use unityEvents) it's less pretty than having the custom opertaor but it allows to combine both wolrds

[@Lyserg1260]

I mostly use UnityEvents for simple UI actions like buttons or OnPointerEnter trying to not subscribe more than one method and mostly those that come from the same object like closing a popup window or highlighting an object. For actions related to game mechanics i prefer regular C# events as they are much easier to debug and trace in code. You can easily find all the event references in your code.

[@DungeonNumber5]

I developed a preference of handling any type of events without UnityEvents. Reason: persistent callbacks on UnityEvents are by definition not managed from code, thus they are the potential source of *weird behaviour* and they may straight up break the abstractions (when object A totally should not care about object B, but _some programmer_ linked them directly via UnityEvent). If anything is controlled by persistent callbacks on UnityEvents, then for the sake of clarity and integrity of your code it should have been controlled by regular callbacks.

[@Unity3dCollege]

I did the same for quite a while. But for some game types, UnityEvents seem to make a lot of sense (especially when working w/ designers who aren't programmers)

[@Elandir]

Nicely exposed Jason. I make extensive use of the two kind of events and I think there are two thinks worth of mention: First, regarding the 'references flow', when using Unity events, the object triggering the event is the one with references to the object with the handler methods while when usind C# events the object with the handler method is the one which must be aware of the object triggering the event when subscribing (true, you can make c# style subcriptions with unity events but for me, if you are going to do that, then you should be using c# events from the beginning). This is interesting as allow you to approach the relations and 'object-to-object awareness' in two opposite ways. Second, in my experience c# events are far more easy to debug. Is easier to check who is subscribed to who and trace back what is happening. In the other hand, Unity Events are faster and more simple to set up (again, only considering Unity events set up from the editor as they don't make much sense when used as c# style). Usually my rule of thumb is 'if events are going to be static, meaning the suscription is performed in editor time and not going to change at runtime Unity events are usually the way to go; in the other hand, if I'm going to do/undo suscriptions at runtime then go for c# events'

[@Mrmder]

Not all heroes wear capes, but I really think you should consider wearing one Jason.

[@joaniepepin4968]

Another distinction is performances. I found a blog the other day that did a test case of both event types and UnityEvent have a much larger overhead! That said, you shouldn't have thousands of events running in loops, so you would probably only notice a difference if your game is already very tight!

[@mikenspired]

Most Important Questions for "When to use Unity Events vs UnityActions or delegates" Is there a possibility your designer or customer ever wants to trigger something when the event occurs, then use a UnityEvent. Do you want this event to be HIDDEN from the designer or customer? then use a C# event or UnityAction. I also keep reading comments saying "Unity Events force coupling in the GUI, or force you to use the gui". You can add listeners via code! I don't feel like Jason did a good job explaining this. I use UnityEvents almost entirely for the "Designer or Customer", but I never use them my self in GUI and instead subscribe to them just like you would a C# event via code.

[@lvladimirov]

Cool video. I was wondering if you have tested the performance between these two cases: 1. Have an event that will alert its listeners to turn on and off their Renderers for example. 2. Instead of triggering an event, simply activate/deactivate a GameObject and have the "listeners" monitor the state of the GO in LateUpdate so that they know when to change the state of the renderers. I dont know how events are structured, but listeners sure must check agains something in order to monitor for events, so at best it should be the same, but more likely a boolean check should be better than an event. (even when its not actually a boolean var but a state of a GO). What are your thoughts?

[@halivudestevez2]

that context menu thing is great! Before this I always did Editor scripts for the sake of 1 button for the inspector....

[@halivudestevez2]

( that is an event, too. an Editor event on the Component inspector ;) )

[@AlexTheProMacGamer]

I kind of agree with Shawn Blais's comment, UnityEvents doesn't really convince me neither. It seems that UnityEvents turn the observer pattern upside down, because the observable (the game object that contains the UnityEvents) is now directly aware of its listeners, and the whole point of calling something an "event" is precisely to decouple the observer from the observable.

[@alexanderlogunov5147]

I prefer to use default c# events or custom observable pattern. I would like to use Unity Events, when I need to delegate job to junior developers, because they are much easier to understand and as far as I know they work in main thread when default events are asynchronous

[@quinnjackson1113]

I have been using a lot of ScriptableObject events for the past year, but all 3 types (unity, c# and SO) are useful in different situations.

[@kordeyrow]

Hi Jason, I usually use UnityEvents instead of c# events, but to prevent things from breaking up easily in the scene, I only link in the UnityEvent the same object that is holding it, so even if I remove all the obejcts from the scene and add them again, the references wont break. And then, when I need to communicate between objects I use ScriptableObjects as Events. The SOEvent would be something like 'OnGemCollected' and may or may not pass any parameter. What do you think about it? Thanks for reading 👍

[@MaZyYTube]

Ohh funny. I just made german version of this same topic but not uploaded yet. I also talk about "Why to use unityevents, (static) events" + scriptableobjects to avoid singletons. Good video btw.

[@sergiorodrigoroyo5079]

One thing I found about UnityEvents is that private variables on the callee don't seem to change at all. So if object A exposes an event and object B's method is the method called when that event happens, if this method changes any of B's private variables, that doesn't work and variables seem to have their default values. I might try this again, but this happened to me a few months ago. Is this normal? I wonder whether I did something wrong, but maybe this is a case for C# events?

[@gamenigeria]

Nice

[@user-mb3jv4yg1n]

Jason my dream to get comment from you, you are the best!

[@YAS-vm8ko]

I learned 6:15 Ctrl+R+R awesome.

[@XtroTheArctic]

I think this correction is important. Event handlers are not registered to the events. They are subscribed.

[@dohruba]

I´m kind of new to unity, so I do not have a preference yet. I have been using simply what I find I could use or make :D

[@Nomarr]

Graeat!

[@Javilingys]

Code from this guy is very cool .. LINQ, private + [SerializeField], Lambda, Hard Consctrctions, etc. It's so cool ) Very hard for me, cause i'm a beginner (maybe), but i wanna learn intermediate or advance style of coding. Other youtubers show simple code with bad practices =((

[@travlake]

Pro tip: try using Rider instead of Visual Studio. It basically teaches you to do all this stuff by suggesting re-writes to your code. Jason has a video recommending it

[@milhouse8166]

@@travlake I found this comment helpful. Thanks

[@nerdin8or]

Agreed. KZbinrs and Udemy instructors will often just show quick & dirty code that does the thing in the video or course title. I am loving how well Jason teaches us to write clean, scalable code.

[@CSNomad]

CodeMonkey does a pretty job of covering intermediate/advance code stuff.

[@Songfugel]

@@CSNomad Not really, he kind of expects you to know it already since he trailblazes thorough everything so fast without explaining half of the things he should have. His content is amazing, but not beginner friendly at all You really notice it if you go over the same content from Jason or Brackey, you realize how much important stuff CM skips in his videos, because they are so obvious to him

[@TheBeardedDoog]

Suggestion: Show the difference between dynamic input and static input to unity event. Hint: You can use dynamic input to prevent having multiple methods or relying on object references. Simplest example, wire a Toggle.OnValueChanged -> gameObject. setActive using dynamic bool