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.
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.
@@biskitpagla 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.
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
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.
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!
Jason! Thank you for another absolutely stellar tutorial. The education you've given me for free on RUclips 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!
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.
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.
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).
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.
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.
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 :)
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.
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
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
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!
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 !
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.
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 :)
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!
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)
4 года назад+1
I think a nice addition to this comparison would be UniRx too, great content :)
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
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.
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.
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.
@@williamleebuckley I dont know if I undertood right what you meant. After renaming the UnityEvent you can remove the "[FormerlySerializedAs]" atribute.
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.
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
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.
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.
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.
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
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.
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.
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)
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.
8:38 - that syntax doesn't always work perfectly fine! It is not multithread safe, as some other thread might remove the last element after we checked for null. Always use the ? operator
When it comes to C# events, according to the standard we should be using event EventHandler / event EventHandler, not event Action / event Action. I haven't heard about UnityEvents before, but I doubt I will use them. I dislike referencing stuff in the inspector. I have PTSD because pretty often my Unity loses those references at random which causes multiple random NullReferenceExceptions.
If ita for an external audience or library id go with the event handler, but for internal projects I really prefer the action syntax to avoid extra code. Undertand the view completely tho :)
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.
@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.
@@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 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.
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!!
Okay...well. My first step should have been checking the play list and seeing “beginner? Start here” LOL I swear I always forget RUclips playlists are a thing for some reason. Still would appreciate any recommendations though, thanks all!!
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
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 :)
@@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(); }
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.
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.
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 =((
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
Agreed. RUclipsrs 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 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
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.
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'
Hello, I have a question for experienced people here. Is adding event listeners to too many game objects on a scene a good choice? Can it reduce frame performance? Let's say we have a puzzle game where every piece has an instance of a class that listens for game events and calls its own functions and behaves accordingly. Is this a good design pattern? (1 event causes n objects to react vs. 1 controller controls n objects.) C# event system makes things really easier and quicker to implement this way. Or should we code a single controller to control multiple objects in such scenario? I also wonder the interior working system of events in C#. Do they listen for invokes in a loop(which would impact performance), or do they have a special system that links all the listeners to the event and only calls them when needed? (like a linker)
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.
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
If you already use references to obj to register events it makes no sense NOT to directly accessing the data then, no need for events, if you have a direct reference
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?
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!
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?
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
Posting this before getting 1 minute into the video. I prefer C# events for just about everything except where I have to tie into Unity's own object lifetime, or Update, LateUpdate, etc. Why scaffold on Unity's higher level stuff when the C# language has interface enough on it's own?
I was somewhat interested in events, but the ContextMenu peaked my interest! I was looking to make easy button in editor without writing custom editor, but could not find any good solution (I ended up using serialised bool that is checked in update loop, and if true, run method and set bool to false. Secured with # if UNITY_EDITOR, and sadly not working outside of runtime).
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.
I would love to use C# events, but to subscribe to a C# event on some kind of object you need a reference to it, and I don't really want to depend on the GameManager in every single script that needs to know about GameLose event.. decoupling things is the very reason I want to use events. What is a clean solution to this? I am thinking of using a ScriptableObject as a mediator between them and depending on that instead, which could work and would make it easier to test the reaction to the event on every object separately or make prefabs that don't search for or depend on anything scene-specific, but I have no idea if calling events from them is any less performant.
You can use the Unity Events like normal events, registering to the Unity Events from the code, without defining actions on the inspector. So in that case, what is the advantage of standart events vs Unity events? What about invoking an Unity Event from another class, do you think that's a good idea when needed? Do you think this is an advantage over normal events?
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
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.
Thank you, I have a question about unityEvent. I don't understand how to remove a listener once it has been added from the inspector. I keep a trace of the gameObject function in a UnityAction but when I remove it, nothing happens in the inspector. Is this normal?
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 👍
What have you named the cactus behind you?
Wow... now it needs a name.
It has xmas 🎄 lights on it... anyone have suggestions?
@@Unity3dCollege Pokey Joe?
@@Unity3dCollege GameObject :D.
@@Unity3dCollege newgo I guess
(from new game object)
@@Unity3dCollege Coollider? :)
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.
Common C# convention is to use EventHandler or EventHandler as your delegate, instead of Action. Both work, of course.
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.
@@biskitpagla 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.
Always answering the good questions the most people don't even know to ask.
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
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
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.
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!
Jason! Thank you for another absolutely stellar tutorial. The education you've given me for free on RUclips 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!
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.
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!
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.
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).
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.
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.
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
I wish more people make videos like you did. This was will organized. Audio was good and clear. Thank you.
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 :)
That Context Menu Help was amazing. Thanks a lot!
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.
After searching half the day this video is what finally helped me solve my problem. Thank you!
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
You can actually multi-select drag and drop onto an empty list to fill it
I didn't know you could add functions to the ContextMenu, so I found the example to be useful.
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
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!
This is why I recommend your channel to everyone in my office. Great stuff !!
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.
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 !
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.
Weird, I'm using black themes everywhere even though my room is always lightened
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 :)
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!
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)
I think a nice addition to this comparison would be UniRx too, great content :)
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
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.
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.
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.
this is one of the biggest issues I run into as well :)
You can use the attribute "[FormerlySerializedAs]" to prevent that.
blogs.unity3d.com/2015/02/03/renaming-serialized-fields/
@@kordeyrow Good tip, didn't know that. Don't know that my OCD can abide that, but still really good to know.
@@williamleebuckley I dont know if I undertood right what you meant. After renaming the UnityEvent you can remove the "[FormerlySerializedAs]" atribute.
I love the tips about enhancing developer experience and editor improvements. Good job buddy!
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.
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
"Work Hard and Be Nice to People"
What a great slogan.
Ya when I saw it i had to grab that thing :) great daily reminder :)
@@Unity3dCollege Yeah I like that moantra too: shortened it for me to "work hard, be nice" ...easier to say to myself ;-)
mantra i.e.
I love that you shared the code for this! Thanks Jason:)
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.
Beautifully written and thought out reply : D
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.
Hey Jason, thanks so much for these videos. I'm super green when it comes to Unity so your knowledge is very much appreciated!
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.
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
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.
You are really good at explaining thing. Thanx!
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.
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)
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.
8:38 - that syntax doesn't always work perfectly fine! It is not multithread safe, as some other thread might remove the last element after we checked for null. Always use the ? operator
When it comes to C# events, according to the standard we should be using event EventHandler / event EventHandler, not event Action / event Action.
I haven't heard about UnityEvents before, but I doubt I will use them. I dislike referencing stuff in the inspector. I have PTSD because pretty often my Unity loses those references at random which causes multiple random NullReferenceExceptions.
If ita for an external audience or library id go with the event handler, but for internal projects I really prefer the action syntax to avoid extra code. Undertand the view completely tho :)
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.
Unityevents don't force you into the gui. I use them from code only often.
@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.
@@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.
@@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?
@@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.
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!!
Okay...well. My first step should have been checking the play list and seeing “beginner? Start here” LOL
I swear I always forget RUclips playlists are a thing for some reason.
Still would appreciate any recommendations though, thanks all!!
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
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 :)
@@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(); }
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.
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.
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 =((
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
@@travlake I found this comment helpful. Thanks
Agreed. RUclipsrs 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.
CodeMonkey does a pretty job of covering intermediate/advance code stuff.
@@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
usefull, clear, short, just perfect as usual!
Hello. Wery useful explanation. Thank you for that. You realy make good quality explanation video.
It help me with many thinks.
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.
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'
First ! Usually use normal events, but I've been programming for a very, very long time.
Nice to see some more uses for unity events :)
Same here, i always have to remember the good times to use unityevents :)
To be honest, I keep forgetting how to use events so that's why I'm here xD
Hello, I have a question for experienced people here. Is adding event listeners to too many game objects on a scene a good choice? Can it reduce frame performance? Let's say we have a puzzle game where every piece has an instance of a class that listens for game events and calls its own functions and behaves accordingly. Is this a good design pattern? (1 event causes n objects to react vs. 1 controller controls n objects.) C# event system makes things really easier and quicker to implement this way. Or should we code a single controller to control multiple objects in such scenario?
I also wonder the interior working system of events in C#. Do they listen for invokes in a loop(which would impact performance), or do they have a special system that links all the listeners to the event and only calls them when needed? (like a linker)
Having the listeners won't be an issue. Only adding and removing them is slow, bit invoking them is really quick, almost like a simple method call.
@@Unity3dCollege Thank you for your answer.
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.
Thanks for this video Jason.
Thanks, This quick cours helped me a lot. Looking for more new lessons.
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
If you already use references to obj to register events it makes no sense NOT to directly accessing the data then, no need for events, if you have a direct reference
Love the Thumbnail 😁
This kind of videos are really useful thank you so much
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?
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!
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?
still no idea, seems like you could just hook up the referrences in code without using events at all? whats the strong case for using events?
awesome video, thanks for this Jason!
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
Hello, will you do please some deep tutorial on multithreading in unity (c# jobs system) or multiplayer (photon unity networking)?
Well that can be answered quickly. If you're beginner or not a programmer you use UnityEvents. Whenever else c# events.
Great explanation mate.
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.
Both are great I can't decide on one .. I bet I'll use them both
Posting this before getting 1 minute into the video. I prefer C# events for just about everything except where I have to tie into Unity's own object lifetime, or Update, LateUpdate, etc. Why scaffold on Unity's higher level stuff when the C# language has interface enough on it's own?
Why don't you need to pass the collectible when you register HandlePickup in the foreach loop?
Here's the gem summarized: 11:37
Not all heroes wear capes, but I really think you should consider wearing one Jason.
I was somewhat interested in events, but the ContextMenu peaked my interest! I was looking to make easy button in editor without writing custom editor, but could not find any good solution (I ended up using serialised bool that is checked in update loop, and if true, run method and set bool to false. Secured with # if UNITY_EDITOR, and sadly not working outside of runtime).
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.
I would love to use C# events, but to subscribe to a C# event on some kind of object you need a reference to it, and I don't really want to depend on the GameManager in every single script that needs to know about GameLose event.. decoupling things is the very reason I want to use events. What is a clean solution to this?
I am thinking of using a ScriptableObject as a mediator between them and depending on that instead, which could work and would make it easier to test the reaction to the event on every object separately or make prefabs that don't search for or depend on anything scene-specific, but I have no idea if calling events from them is any less performant.
Whats the difference between using ,
1 public event Action someEvent; and
2 public Action someEvent ?
that context menu thing is great! Before this I always did Editor scripts for the sake of 1 button for the inspector....
( that is an event, too. an Editor event on the Component inspector ;) )
This was super helpful. thanks!
You can also just make that List an IEnumerable in a lot of cases, unless you really need List specific methods (which you do here, but just an FYI).
You can use the Unity Events like normal events, registering to the Unity Events from the code, without defining actions on the inspector. So in that case, what is the advantage of standart events vs Unity events? What about invoking an Unity Event from another class, do you think that's a good idea when needed? Do you think this is an advantage over normal events?
Do you have any particular scenario in mind where you would actually need to invoke an event on another class?
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
Very helpful. Thank you.
Awesome, thanks Jason! :D
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.
Thank you for this tutorial, I really like what are you doing, you helped me alot!)
Thank you,
I have a question about unityEvent.
I don't understand how to remove a listener once it has been added from the inspector. I keep a trace of the gameObject function in a UnityAction but when I remove it, nothing happens in the inspector. Is this normal?
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 👍
What about sending information over events? Which one do you prefer? I could not manage to do it with UnityEvents.