The main issue I see with this approach is the number of scriptable objects you then have to create and fill your project with, one for every single event you could need. You mention when reaching for a static class it's because you want something fast, not scalable, but I look at 100s of potential scriptable object event channels and see that is not scalable. Really surprised you went from an event bus to this, but I get the rationale, just not the solution. Good video, and great way of explaining generics. Never seen it explained that hand-holdy before, and I'm sure it helped someone stuck on the concept
do not get fooled by SOLID princibles. They are told to be "clean code" tools, but in real life, you just get confused. I don't mean it is completely useless, or harmful, but keep your eyes open, and ask questions if it is useful in you case, or rather makes things complicated.
I was really skeptical clicking on this video - I'm historically not a fan of SO let alone using them for events (as that has become popular lately to do)... but right off the bat, you talk about high coupling and you explain really well that it lowers dependencies on other scripts. Very compelling when put in those terms. I'll likely still use delegates for most of this stuff (from monolithic singletons), but honestly, you make a really strong point in this video and for that I enjoyed it greatly!
I've been using something similar - just in code without scriptable objects. But it has been really convenient for decoupled logic and avoiding logic from breaking when certain other objects don't exist in the scene
Great tutorial! I really liked that you offered both a code-driven approach and an inspector driven approach. The 2017 Unite talk is geared toward studios that have dedicated designers with an emphasis on inspector use. Your guide is very balanced, showing how the inspector setup is an optional step beyond what can already be done in code! Thanks so much 😁
I really like your tutorials. They are of the best ones out there. I want to add a wishlist to your tutorials - that you will make a tutorial about google analytics (Firebase). That is how to to setup custom events with parameters, how to test its working, etc. I've been searching for ages and still haven't found good and up-to-date tutorials about it.
Thanks! A very helpful example of using static classes. In my project individual units had to be registered with appropriate manager classes on enable and that caused a lot of headache to manage. I will try to move most of this logic into the event bus system you've explained and hopefully adding more particle and sound effects events in the future will be much easier. The TODO list keeps growing, no matter how many refactoring passes I do...
I'm trying to avoid assigning events in inspectors: these assignments are easy to loose, they also fall apart if you add more parameter to the event. They are also untrackable, and hidden from the code aspects: you cannot track doen, why that event happens. I ban UnityEvent-s from my code as much as possible, and go by System.Event. More stabile.
@@LlamAcademy Shouldn't it be quite easy to solve the problem with the messaging approach? It would only be necessary to insert a message in the base class, which is given to each event and can be read at a suitable point. I currently use the signal system from DoozyUI and it does exactly that. Each event also has a message payload. There is then the SignalConsole and the StreamsConsole in which all fired events are displayed.
I have the same approach as yours; if there's a Button component that needs to register click events, I'd create a reference to that Button and hookup from code instead. But then I am a programmer, I have the option to do that. It doesn't apply to designers who shouldn't be touching any codes.
@@halivudestevez2 I think that's the most important point. I am totally with you. C# events are definitely the better approach to keep a better overview and not lose references. But using Unity events/event management via the Inspector also allows game designers and other disciplines in larger teams to make changes without having to intervene directly in the code, which is something you absolutely want to avoid as a game programmer ^^
My problem with Event Bus is that everything can call everyone at any time. Being able to call any method through an event is super convenient and helpful for designers, however it's easy to lose track of which system should only talk to which system. If everyone can talk to anyone, there's not much incentive to keep the Enemy system only influence the enemies and not any random experience bar.
Very clear video, now, im starting to understand but I still wonder if story driven dialogues should be handled by events too? Like lets say a character which has different dialogue based on game advancement?
Can you please make a video about saving/loading player inventory, where items are ScriptableObjects. I understand that one way to go about it is - items have to be serialized by their guid or by some sort of another id, and then maybe lookup tables or something. This way there needs to be a way to scan and add SO items to lookup table in the first place... Basically I don't know which way to go about handling this whole topic, please ponder this topic in a video, thanks.
Here's my "scan for all ScriptableObjects of a type" method. public static List GetAllInstances() where T : ScriptableObject { return AssetDatabase.FindAssets($"t: {typeof(T).Name}").ToList() .Select(AssetDatabase.GUIDToAssetPath) .Select(AssetDatabase.LoadAssetAtPath) .ToList(); }
Sadly Godot doesn't have static actions or delegates, in there we use signals which are really convenient in their own right. I had made an event bus and made a event system which all signals emit a object Event which contains a type String and variant data (dynamic data). This isn't too bad but in bigger projects I am thinking this isn't good. So I was thinking of going with exposing the event bus via using Resources (Scriptable Objects) and putting a signal in that. Not sure... Regardless another neat thing is a broker pattern where you can get back the other end of this system, this allows for sending lamda's to handle logic inside of a broker which works independently of the origin or even the thing using the broker. So if I have say Attack and it's 0 at base but I equip a sword with 8 attack, the attack getter simply needs to return broker and whatever identifier the parameter is subscribed with to return 8. This stacks with all modifiers and I can even get a list of all modifiers and their sources since the broker knows all XD. I recall in Unity not enjoying the event channel workflow, it made it feel like drag n drop hell.
In a real world scenario, would you use this buses only in events that connect different systems/unrelated parts of code? I do use a lot o Actions in my code, and many of those are to bind together closely related scripts, like the Player triggering some small events that are used in other scripts of the same hierarchy. In these it seems like it'd be and overkill to create all those classes.
It depends on the complexity of your game. If what you have is working well and scales to the level you need it, you're good! If you find out some of those events need to be listened to by other scripts, you may consider refactoring those to a global event bus with one of these 3 methods.
Why do you need a MonoBehaviour for this? You do not need a GameObject nor the lifecycle methods like start/awake. 🙂 there are many ways to approach a problem. In this video I show a typical standard C# one, and two that Unity themselves have suggested in their e-book.
Well if we take either of those numbers 30-20 = 10. There are plenty of kids programming at 10. 35-20 = 15, people are taking boot camps at that age. I started programming in the late 90s with Visual Basic.
sounds great for the first glance, but in real, it's bullshit. Bus< ??? you have to find out, look thru your 1000 code finding out what to write here. While "Bus.
The main issue I see with this approach is the number of scriptable objects you then have to create and fill your project with, one for every single event you could need. You mention when reaching for a static class it's because you want something fast, not scalable, but I look at 100s of potential scriptable object event channels and see that is not scalable. Really surprised you went from an event bus to this, but I get the rationale, just not the solution.
Good video, and great way of explaining generics. Never seen it explained that hand-holdy before, and I'm sure it helped someone stuck on the concept
I'm having nightmares trying to make everything "open-close", and this video just scratch that part of my brain. thank you
do not get fooled by SOLID princibles. They are told to be "clean code" tools, but in real life, you just get confused.
I don't mean it is completely useless, or harmful, but keep your eyes open, and ask questions if it is useful in you case, or rather makes things complicated.
I was really skeptical clicking on this video - I'm historically not a fan of SO let alone using them for events (as that has become popular lately to do)... but right off the bat, you talk about high coupling and you explain really well that it lowers dependencies on other scripts. Very compelling when put in those terms.
I'll likely still use delegates for most of this stuff (from monolithic singletons), but honestly, you make a really strong point in this video and for that I enjoyed it greatly!
It's funny, your use case (monolithic singletons) is the exact reason we've gotten to the point where we need solutions like this.
I've been using something similar - just in code without scriptable objects. But it has been really convenient for decoupled logic and avoiding logic from breaking when certain other objects don't exist in the scene
Great tutorial! I really liked that you offered both a code-driven approach and an inspector driven approach.
The 2017 Unite talk is geared toward studios that have dedicated designers with an emphasis on inspector use. Your guide is very balanced, showing how the inspector setup is an optional step beyond what can already be done in code! Thanks so much 😁
Awesome video. I think the best one I've seen so far in regards to Event Bus being more designer friendly :D
I really like your tutorials. They are of the best ones out there.
I want to add a wishlist to your tutorials - that you will make a tutorial about google analytics (Firebase). That is how to to setup custom events with parameters, how to test its working, etc. I've been searching for ages and still haven't found good and up-to-date tutorials about it.
Thanks! A very helpful example of using static classes. In my project individual units had to be registered with appropriate manager classes on enable and that caused a lot of headache to manage. I will try to move most of this logic into the event bus system you've explained and hopefully adding more particle and sound effects events in the future will be much easier. The TODO list keeps growing, no matter how many refactoring passes I do...
Make sure the refactoring passes are helping you deliver value to your game. Eventually "good enough" has to be good enough and move on 🙂.
I'm trying to avoid assigning events in inspectors: these assignments are easy to loose, they also fall apart if you add more parameter to the event.
They are also untrackable, and hidden from the code aspects: you cannot track doen, why that event happens.
I ban UnityEvent-s from my code as much as possible, and go by System.Event. More stabile.
I have many criticizm about this approach, since I solodev and has negative, real-world experiences...
Yup. If it doesn’t work for you and your workflow, don’t use that approach!
@@LlamAcademy Shouldn't it be quite easy to solve the problem with the messaging approach? It would only be necessary to insert a message in the base class, which is given to each event and can be read at a suitable point. I currently use the signal system from DoozyUI and it does exactly that. Each event also has a message payload. There is then the SignalConsole and the StreamsConsole in which all fired events are displayed.
I have the same approach as yours; if there's a Button component that needs to register click events, I'd create a reference to that Button and hookup from code instead. But then I am a programmer, I have the option to do that. It doesn't apply to designers who shouldn't be touching any codes.
@@halivudestevez2 I think that's the most important point. I am totally with you. C# events are definitely the better approach to keep a better overview and not lose references. But using Unity events/event management via the Inspector also allows game designers and other disciplines in larger teams to make changes without having to intervene directly in the code, which is something you absolutely want to avoid as a game programmer ^^
great tutorial. nice and easy to understand. thanks
My problem with Event Bus is that everything can call everyone at any time.
Being able to call any method through an event is super convenient and helpful for designers, however
it's easy to lose track of which system should only talk to which system.
If everyone can talk to anyone, there's not much incentive to keep the Enemy system only influence the enemies and not any random experience bar.
Like always, a great video! Thanks :)
Glad you liked it 😁
If working in a bigger team, you must even expect team members, who refuse to touch prefabs, scriptableobjects or such at all.
Very clear video, now, im starting to understand but I still wonder if story driven dialogues should be handled by events too? Like lets say a character which has different dialogue based on game advancement?
Can you please make a video about saving/loading player inventory, where items are ScriptableObjects. I understand that one way to go about it is - items have to be serialized by their guid or by some sort of another id, and then maybe lookup tables or something. This way there needs to be a way to scan and add SO items to lookup table in the first place... Basically I don't know which way to go about handling this whole topic, please ponder this topic in a video, thanks.
Here's my "scan for all ScriptableObjects of a type" method.
public static List GetAllInstances() where T : ScriptableObject
{
return AssetDatabase.FindAssets($"t: {typeof(T).Name}").ToList()
.Select(AssetDatabase.GUIDToAssetPath)
.Select(AssetDatabase.LoadAssetAtPath)
.ToList();
}
Sadly Godot doesn't have static actions or delegates, in there we use signals which are really convenient in their own right.
I had made an event bus and made a event system which all signals emit a object Event which contains a type String and variant data (dynamic data).
This isn't too bad but in bigger projects I am thinking this isn't good.
So I was thinking of going with exposing the event bus via using Resources (Scriptable Objects) and putting a signal in that. Not sure...
Regardless another neat thing is a broker pattern where you can get back the other end of this system, this allows for sending lamda's to handle logic inside of a broker which works independently of the origin or even the thing using the broker.
So if I have say Attack and it's 0 at base but I equip a sword with 8 attack, the attack getter simply needs to return broker and whatever identifier the parameter is subscribed with to return 8. This stacks with all modifiers and I can even get a list of all modifiers and their sources since the broker knows all XD.
I recall in Unity not enjoying the event channel workflow, it made it feel like drag n drop hell.
It is not entirely clear to me what the benefit of using a events bus is over using the standard system events.
What do you mean the “standard system events”?
Cool
Thanks Liaaaaaaam
In a real world scenario, would you use this buses only in events that connect different systems/unrelated parts of code?
I do use a lot o Actions in my code, and many of those are to bind together closely related scripts, like the Player triggering some small events that are used in other scripts of the same hierarchy. In these it seems like it'd be and overkill to create all those classes.
It depends on the complexity of your game. If what you have is working well and scales to the level you need it, you're good! If you find out some of those events need to be listened to by other scripts, you may consider refactoring those to a global event bus with one of these 3 methods.
Are there any differences between Event Bus and Scriptable Object Event Channels ?
Yup that’s discussed in here
its look like zenject event system
why SciptableObject for this? I have a MonoBehaviour for eventbus, for LevelEvents.
Why do you need a MonoBehaviour for this? You do not need a GameObject nor the lifecycle methods like start/awake. 🙂 there are many ways to approach a problem. In this video I show a typical standard C# one, and two that Unity themselves have suggested in their e-book.
Bread
🍞
@@sealsharp Bread
How old are you? Maybe 30 or 35? You can't have more than 20 years of experience as a programmer.
he worked overnight, too
Well if we take either of those numbers 30-20 = 10. There are plenty of kids programming at 10. 35-20 = 15, people are taking boot camps at that age.
I started programming in the late 90s with Visual Basic.
FIRST :)))))
😎
you just overcomplicate simple things.
sounds great for the first glance, but in real, it's bullshit. Bus< ??? you have to find out, look thru your 1000 code finding out what to write here. While "Bus.