I went over a lot of my written code over the last couple of months to rework them into more modular systems, basically building my own toolbox. I can recommend doing this, even though I am a hobby solo developer. I realized I had a lot of systems at my hand I could throw together to see if a game emerges :D Things like an inventory system, a crafting system, helpers, extensions,... Brushing the dusty files off and updating them along the way to my current level of knowledge felt good, too. Working with packages sounds interesting, I'll look into it next =)
MonoBehavior is modular by design. Every MonoBehavior covers a single behaviour. Want a game obiect to move? Create a movement mono, want inputs to trigger movement? Create an InputMovement to hit up the InputSystem, and expose a series of callbacks. This then exposes itself so you can drag the moment script to it and hook up the various methods available to feed the movement. Another can be created that creates random input, or Ai based pathfinding input. Using similar approaches you can create an equipment behaviour, an inventory behavior, a combat behavior and break things down as necessary. The tricky portion is connecting it all together. Unity allows us to both find game objects (not advised), pass them in through the inspector (preferred) or encounter them as physics and collisions take place (as needed). Moving away from Unity you can always rely on good old plain c# and pass things in directly, use static references and other well known pattern extensions.
@@benvella1728 Yeah I understand your point but not because something is called Monobehaviour means that it's behaviour is mono :D. Lot of people dump ton of code into the same monobehaviour and I'm just pointing that there aren't videos on this subject except for really basic stuff
I can recommend to seperate the events from the logic classes. For instance, write a class named GameEvents and a property like public UnityAction PlayerDied; if you use DI than just inject the class or create maybe a singleton or make the event static. than when the player dies, he just has to call event from the GameEvents like => GameEvents.PlayerDied?.Invoke();. And another logic class can register easily. when u want to reuse any logic class only the event classes will be included to exporter file. And thanks to this u can remove any logic from the game if needed. if u remove the player than no one calls the event, if u remove the registered class than just no one ise registered and will not break anything. I only use events in logic classes if it has to connect to and child or parent class/object
I love the modular approach. But it won't be a 100% modular. Sure an interface makes it so that you no longer need to reference a specific made implementation for it. But you'll still need to drag that interface around. Character3 cannot compile if you don't have the IAudioService interface. It won't run either if you don't have an implementation for it. Not to mention that Unity can't serialize a reference to an interface. So if Character3 were to be a component inheriting from MonoBehaviour, you'd either need a GameObject field so you can use a GetComponent on. Or do some custom serialization / deserialization handling which is more effort to build. I don't know why Unity still hasn't made this kind of functionality. They did make the [SerializeReference] attribute, but you can't drag drop another component that inherits from a certain interface onto an interface field. One other way that I like, is to use a UnityEvent instead of an event Action. You can serialize the event in the inspector. But once you do that, things can become complicated because logic is now partly embedded in the scene. That can become extremely hard to follow.
It's exactly what I do since a couple of years now. and it's greate. I was tired to copy / paste script or piece of code from a project to another project, then rewrite the pasted code to make it work with the new project specificities. Now I have my own packages, or "systems" hosted on git. systems communicate with the rest of the code with an Event system as an intermediate (it's some scriptable objects GameEvents and variables, cf Unit talk 2016). System A ---> scriptableObject variable PlayerHealth SO
@@mohamedal-qadeery6530 Something that facilitates communication between multiple services or bits of code. If you want to use this pattern, you should look into Unity Atoms
Lot's of words for little information, would've wanted more architecture examples
2 года назад+1
I use submodules for packages that are under development and need a lot of changes. Once they mature I make them into UPM packages. UPM packages are a bit quicker to setup in a new project but they take a bit more work to update, so there's a tradeoff there IMO.
ECS also screams a lot of overhead if you don't have a game which specifically needs highly optimized cache. Using it just to enforce modular code is wrong approach to solving this problem imo.
The problem is that it is missing a 3D visualization tool for inspecting and looking at the code spaghetti in a fast visual way, for example, an island with a tree with a net where each leaf is a component or a C# class.
Great video and advice, I use most of the things you said already :) Can you please tell us how can you encapsulate a namespace without brackets ? We have to upgrade to a new Unity ? My code does not compile if I write like you did namespace Game.Character; It forces me to make it namespace Game.Character { }
@@bezoro-personal There is some stuff coming for QOL. You have to remember most VFX systems require compute shader supported and not all devices support that. So some platforms such as WebGl, some mobile devices, and so forth don't work at all with VFX so they can't just fully abandon the particle system just yet, but they are working on it.
@@i486dx2 They encourage soft and ambiguous boundaries between systems. They split the responsibility of declaring dependencies between "packages" in to two: once in the .gitmodules and once in the project manifest. They muddy your project structure. If you keep your CI/test/setup files for that project/repo in the submodule, then they get imported into the main project. I see some folks try and mitigate this by having a container project for the submodule, so now you need a repo to hold the submodule in a "generic" context. Depending on your specific project, there are other issues I'd categorize anywhere from nuisance to major PITA.
I've tried to tell this to the Unity Visual Scripting team for _years_ so they could fix their product -- and then Unity drops Visual Scripting entirely for the upcoming year. Maybe this is a good sign. Maybe not. I fear it is not.
Contains some useful information, but the video are so dry, sorry :( For me it becomes hard to listen to you when you keep the same "bored monotone voice level" throughout the presentation.
I went over a lot of my written code over the last couple of months to rework them into more modular systems, basically building my own toolbox. I can recommend doing this, even though I am a hobby solo developer. I realized I had a lot of systems at my hand I could throw together to see if a game emerges :D Things like an inventory system, a crafting system, helpers, extensions,... Brushing the dusty files off and updating them along the way to my current level of knowledge felt good, too. Working with packages sounds interesting, I'll look into it next =)
I'd love a talk that go more into modular code examples, they always do basic examples unfortunately.
MonoBehavior is modular by design. Every MonoBehavior covers a single behaviour. Want a game obiect to move? Create a movement mono, want inputs to trigger movement? Create an InputMovement to hit up the InputSystem, and expose a series of callbacks. This then exposes itself so you can drag the moment script to it and hook up the various methods available to feed the movement.
Another can be created that creates random input, or Ai based pathfinding input.
Using similar approaches you can create an equipment behaviour, an inventory behavior, a combat behavior and break things down as necessary.
The tricky portion is connecting it all together. Unity allows us to both find game objects (not advised), pass them in through the inspector (preferred) or encounter them as physics and collisions take place (as needed).
Moving away from Unity you can always rely on good old plain c# and pass things in directly, use static references and other well known pattern extensions.
@@benvella1728 Yeah I understand your point but not because something is called Monobehaviour means that it's behaviour is mono :D. Lot of people dump ton of code into the same monobehaviour and I'm just pointing that there aren't videos on this subject except for really basic stuff
I've never used Git before but the submodule structure makes it very appealing; I think it's time to check it out.
I can recommend to seperate the events from the logic classes. For instance, write a class named GameEvents and a property like public UnityAction PlayerDied; if you use DI than just inject the class or create maybe a singleton or make the event static. than when the player dies, he just has to call event from the GameEvents like => GameEvents.PlayerDied?.Invoke();. And another logic class can register easily. when u want to reuse any logic class only the event classes will be included to exporter file. And thanks to this u can remove any logic from the game if needed. if u remove the player than no one calls the event, if u remove the registered class than just no one ise registered and will not break anything. I only use events in logic classes if it has to connect to and child or parent class/object
Great talk, Robin, thanks!
I love the modular approach. But it won't be a 100% modular. Sure an interface makes it so that you no longer need to reference a specific made implementation for it.
But you'll still need to drag that interface around. Character3 cannot compile if you don't have the IAudioService interface. It won't run either if you don't have an implementation for it.
Not to mention that Unity can't serialize a reference to an interface. So if Character3 were to be a component inheriting from MonoBehaviour, you'd either need a GameObject field so you can use a GetComponent on. Or do some custom serialization / deserialization handling which is more effort to build.
I don't know why Unity still hasn't made this kind of functionality. They did make the [SerializeReference] attribute, but you can't drag drop another component that inherits from a certain interface onto an interface field.
One other way that I like, is to use a UnityEvent instead of an event Action. You can serialize the event in the inspector.
But once you do that, things can become complicated because logic is now partly embedded in the scene. That can become extremely hard to follow.
Unity event performs bad than normal events right
negligible. If you do it every frame you might as well use an update loop instead.
infrequent, it doesn't matter at all
Благодарю за труд! Очень полезная информация, особенно про Assembly Definitions.
It's exactly what I do since a couple of years now. and it's greate.
I was tired to copy / paste script or piece of code from a project to another project, then rewrite the pasted code to make it work with the new project specificities.
Now I have my own packages, or "systems" hosted on git.
systems communicate with the rest of the code with an Event system as an intermediate (it's some scriptable objects GameEvents and variables, cf Unit talk 2016).
System A ---> scriptableObject variable PlayerHealth SO
I think a scriptable object acting as an event source can be a good option for the "mediation layer" mentioned around 10:53.
Thats done in the Unity Project, that approach is "ok" but not always suitable :)
i couldn't understand what did he mean with meditation layer for events is there an example for it ?
@@mohamedal-qadeery6530 Something that facilitates communication between multiple services or bits of code. If you want to use this pattern, you should look into Unity Atoms
Great video but , i couldn't understand what did he mean with meditation layer for events is there an example for it ?
Lot's of words for little information, would've wanted more architecture examples
I use submodules for packages that are under development and need a lot of changes. Once they mature I make them into UPM packages. UPM packages are a bit quicker to setup in a new project but they take a bit more work to update, so there's a tradeoff there IMO.
ECS needed more than simply a sentence in this talk -- It practically _screams_ modular code!
ECS also screams a lot of overhead if you don't have a game which specifically needs highly optimized cache. Using it just to enforce modular code is wrong approach to solving this problem imo.
Very practical mate
We can obtain the same with abstract class right so why interface except having a multiple inheritance is the advantage or am i wrong
The problem is that it is missing a 3D visualization tool for inspecting and looking at the code spaghetti in a fast visual way, for example, an island with a tree with a net where each leaf is a component or a C# class.
Great video and advice, I use most of the things you said already :) Can you please tell us how can you encapsulate a namespace without brackets ? We have to upgrade to a new Unity ? My code does not compile if I write like you did namespace Game.Character; It forces me to make it namespace Game.Character { }
Какие у этого парня эпичные зубы!) Спасибо за видео
Tq ☺️
Hey unity is there gonna be any updates on the particle system
No
@@bezoro-personal There is some stuff coming for QOL.
You have to remember most VFX systems require compute shader supported and not all devices support that.
So some platforms such as WebGl, some mobile devices, and so forth don't work at all with VFX so they can't just fully abandon the particle system just yet, but they are working on it.
Not much useful information for me sadly, those things are lack of examples and well-known by most of the programmer I guess.
Hi guys I have a build error on my android game
This error pops up:
Win32Exception Native error= The system cannot find the file specified
PLS help me
Bruder ich hör deinen deutschen Akzent so raus😂😂
Submodules are a very very very bad practice at scale. Especially now that Unity has UPM.
Why are sub-modules a bad practice? Can you elaborate on that?
@@i486dx2 They encourage soft and ambiguous boundaries between systems.
They split the responsibility of declaring dependencies between "packages" in to two: once in the .gitmodules and once in the project manifest.
They muddy your project structure. If you keep your CI/test/setup files for that project/repo in the submodule, then they get imported into the main project. I see some folks try and mitigate this by having a container project for the submodule, so now you need a repo to hold the submodule in a "generic" context.
Depending on your specific project, there are other issues I'd categorize anywhere from nuisance to major PITA.
I've tried to tell this to the Unity Visual Scripting team for _years_ so they could fix their product -- and then Unity drops Visual Scripting entirely for the upcoming year.
Maybe this is a good sign. Maybe not.
I fear it is not.
Contains some useful information, but the video are so dry, sorry :(
For me it becomes hard to listen to you when you keep the same "bored monotone voice level" throughout the presentation.
Interfaces break the dry principle
Only if all implementations are the same, in which case you should be using inheritance anyway
no they dont. theyre made specifically to allow for different implementations of the same contract based on different needs.