Events or UnityEvents?????????
Vložit
- čas přidán 17. 07. 2024
- 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
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.
Always answering the good questions the most people don't even know to ask.
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 :)
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!
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!
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 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
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.
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!
This is why I recommend your channel to everyone in my office. Great stuff !!
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.
I wish more people make videos like you did. This was will organized. Audio was good and clear. Thank you.
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
That Context Menu Help was amazing. Thanks a lot!
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 love the tips about enhancing developer experience and editor improvements. Good job buddy!
After searching half the day this video is what finally helped me solve my problem. Thank you!
Jason! Thank you for another absolutely stellar tutorial. The education you've given me for free on CZcams 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.
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 :)
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 love that you shared the code for this! Thanks Jason:)
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.
usefull, clear, short, just perfect as usual!
awesome video, thanks for this Jason!
Thanks for this video Jason.
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 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.
This kind of videos are really useful thank you so much
Thank you for this tutorial, I really like what are you doing, you helped me alot!)
This was super helpful. thanks!
Great explanation mate.
You are really good at explaining thing. Thanx!
Thanks, This quick cours helped me a lot. Looking for more new lessons.
this was very helpful, thanks!
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 !
Awesome, thanks Jason! :D
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.
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 think a nice addition to this comparison would be UniRx too, great content :)
Very helpful. 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
Great editing!
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
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
Awesome Video Thank #Jason it helps me a lot in my project
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 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?
Both are great I can't decide on one .. I bet I'll use them both
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.
Nice videos!! Thanks
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.
@@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.
Hello. Wery useful explanation. Thank you for that. You realy make good quality explanation video.
It help me with many thinks.
Love the Thumbnail 😁
Hi, Thanks for nice Contents :)
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 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.
Greate Thanks Jason
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
Thank you a lot :)
Thank you!
Good stuff!
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'
tnx for youre video!
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. CZcamsrs 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
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 CZcams playlists are a thing for some reason.
Still would appreciate any recommendations though, thanks all!!
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 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 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.
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 ;) )
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.
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.
Jason my dream to get comment from you, you are the best!
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.
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?
Thanks!
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'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.
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?
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
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
To be honest, I keep forgetting how to use events so that's why I'm here xD
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
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?
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.
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 👍
I learned 6:15 Ctrl+R+R awesome.
Not all heroes wear capes, but I really think you should consider wearing one Jason.
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
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 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.
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)
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 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
As someone who is comfortable with basic C#, enough so to make full games in Unity, could you recommend one book and/or reference to become more comfortable with intermediate/advanced C#?
What about sending information over events? Which one do you prefer? I could not manage to do it with UnityEvents.
Hello, will you do please some deep tutorial on multithreading in unity (c# jobs system) or multiplayer (photon unity networking)?
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).