🌍 Design Patterns e-book cmonkey.co/designpatternsebook 🎮 FREE Interactive Project cmonkey.co/designpatternsproject ✅ Get my C# Complete Course! cmonkey.co/csharpcourse 🔴 RELATED VIDEOS 🔴 Learn C# Intermediate FREE Tutorial Course! [2024] ruclips.net/video/I6kx-_KXNz4/видео.html How to Talk to NPCs! (or Interact with any Object, Open Doors, Push Buttons, Unity Tutorial) ruclips.net/video/LdoImzaY6M4/видео.html Why you should NOT make everything PUBLIC! ruclips.net/video/pD27YuJG3L8/видео.html "I'm not perfect" OR "many solutions to a problem" ruclips.net/video/gh9ISSLQSUc/видео.html
Glad to see the highlight here! Unity has actually been producing a ton of great resources like this that have mostly gone under the radar. This is probably by far the best one though.
Coincidentally I just started reading Clean Code, but I had trouble thinking of specific examples of how to apply what I’ve learned n game development. I think this E-book and project is exactly what I needed! Thank you for sharing this resource.
Just a warning. Clean Code was written in the 2000s for enterprise applications which dozens, sometimes hundreds of people worked on. 1) Unity (and other engines) heavily uses the composite pattern, so some of the advice for general OOP will become an antipattern in that a game engine scenario. 2) the heavy emphasis on abstraction is a waste of time if you do not have parallel teams working on replacing and changing huge parts of the system and also, Unity has a different coupling through it's components+gameobjects-architecture. 3) There's a lot of advice in that book that is basically "feelings and preferences" and how clean the result is, that is debatable. Like splitting stuff into many little methods which reduces the complexity of the individual method but increases the complexity of the whole system by reduced locality of behavior. I'd still recommend to read it, but not as gospel. Try to understand where stuff comes from and you get a better feeling which parts you can apply and which parts you can transform to apply for cases that do not exactly match the scenario they were made for.
@@sealsharp i said a similar thing in a comment a while back, so i certainly agree with you. I've been using design patterns since i first started using java about 20 years ago. I just find them to be a pain, especially as part of a small team, just obfuscating things with layers of abstraction. Games are all about real time performance, and as you say, the unity architecture is based on scripting and game objects, so isn't well suited to design patterns, anyway. Unity uses the observer pattern behind the scenes for the event model, and singletons can be useful for an audio manager, or a game manager class. Beyond those sorts of things I just think design patterns add complexity, and can affect performance, if not implemented correctly. I think it's more important for people to get their heads around the way unity works, and its single threaded nature. On forums, for example, I often see people telling others to use multi threading, instead of coroutines - just a lot of bad advice from people who are not understanding the basics of the way unity has been written.
The way I always think about Liskov Substitution is that "all dogs are animals, but not all animals are dogs." Meaning a base class can't necessarily be substituted for a child class, but a child can be substituted for a base class. So when designing behaviours, it's important to decide whether they belong on "dog" or on "animal" if they're something that everyone will share or not, and then when you call the class, is your behaviour on the base class or the child? There's also another principle that says, "Code the rule, script the exception." In other words, hard code things that are certain and deal with anomalies as they show up. So all birds fly ... except ostriches and penguins. All mammals birth live young instead of laying eggs ... except for platypus. So a bird class with Fly and a mammal class with Birth Young still makes sense even though it's not absolute as it will handle 99% of cases.
It's not that a technical debt slows down a project... it's that many devs just slap things together without a proper architecture. You SHOULD think of proper architecture, as well as, of the good performance practices from the start. If you don't - chances are, later on it'll be too late, because the good architecture can look and behave completely different. Educate yourself, know how stuff works under the hood, expand default functionality with things that make your life easier (like C# delegate event wrapper classes, they can even be dictionary mapped. Also just today I added a class that invokes event on trigger enter/exit, just so I can listen to collider triggers on another GameObject. Simple things, but help a ton)
Yeah, the only interesting DI pattern they used was this bit in the Dependency Inversion Principle sample: // Unity's serialization system does not directly support interfaces. Work around this limitation // by using a serialized reference to a MonoBehaviour that implements ISwitchable. [SerializeField] private MonoBehaviour m_ClientBehaviour; private ISwitchable m_Client => m_ClientBehaviour as ISwitchable; Pretty underwhelming, given the importance of the pattern when it comes to the SOLID principles... but also understandable, given that it is a complicated topic in and of itself (with Unity in particular).
Let's say I have a lot of different animal NPCs roaming around the map (hundreds total). Do you think there would be a significant performance increase if I segment them in some way like with a dirty pattern or something alike? In my scenario most animals have a collider, but most of their function is either being there for aesthetics or a physical obstacle, and they roam around.
I think your scenario is fine without a dirty flag, but it will make sense to turn off the colliders if the player is far away. Dirty flag is probably for something that's O(N^2) or higher time complexity that doesn't need to run every frame. I could be wrong.
Yup you should definitely avoid updating NPCs that are super far away, you can indeed test the distance and mark them as dirty if past a certain distance and if they are dirty hide visuals/colliders/logic. Then if the distance is under that threshold set it dirty again and make it all visible/enabled.
🌍 Design Patterns e-book cmonkey.co/designpatternsebook
🎮 FREE Interactive Project cmonkey.co/designpatternsproject
✅ Get my C# Complete Course! cmonkey.co/csharpcourse
🔴 RELATED VIDEOS 🔴
Learn C# Intermediate FREE Tutorial Course! [2024] ruclips.net/video/I6kx-_KXNz4/видео.html
How to Talk to NPCs! (or Interact with any Object, Open Doors, Push Buttons, Unity Tutorial) ruclips.net/video/LdoImzaY6M4/видео.html
Why you should NOT make everything PUBLIC! ruclips.net/video/pD27YuJG3L8/видео.html
"I'm not perfect" OR "many solutions to a problem" ruclips.net/video/gh9ISSLQSUc/видео.html
I'm a programmer for Rust and Javascript. Don't have much experience on game development either. This is a godsend for me.
Glad to see the highlight here!
Unity has actually been producing a ton of great resources like this that have mostly gone under the radar. This is probably by far the best one though.
Coincidentally I just started reading Clean Code, but I had trouble thinking of specific examples of how to apply what I’ve learned n game development.
I think this E-book and project is exactly what I needed! Thank you for sharing this resource.
Just a warning. Clean Code was written in the 2000s for enterprise applications which dozens, sometimes hundreds of people worked on.
1) Unity (and other engines) heavily uses the composite pattern, so some of the advice for general OOP will become an antipattern in that a game engine scenario.
2) the heavy emphasis on abstraction is a waste of time if you do not have parallel teams working on replacing and changing huge parts of the system and also, Unity has a different coupling through it's components+gameobjects-architecture.
3) There's a lot of advice in that book that is basically "feelings and preferences" and how clean the result is, that is debatable. Like splitting stuff into many little methods which reduces the complexity of the individual method but increases the complexity of the whole system by reduced locality of behavior.
I'd still recommend to read it, but not as gospel. Try to understand where stuff comes from and you get a better feeling which parts you can apply and which parts you can transform to apply for cases that do not exactly match the scenario they were made for.
@@sealsharp i said a similar thing in a comment a while back, so i certainly agree with you.
I've been using design patterns since i first started using java about 20 years ago.
I just find them to be a pain, especially as part of a small team, just obfuscating things with layers of abstraction.
Games are all about real time performance, and as you say, the unity architecture is based on scripting and game objects, so isn't well suited to design patterns, anyway.
Unity uses the observer pattern behind the scenes for the event model, and singletons can be useful for an audio manager, or a game manager class.
Beyond those sorts of things I just think design patterns add complexity, and can affect performance, if not implemented correctly.
I think it's more important for people to get their heads around the way unity works, and its single threaded nature.
On forums, for example, I often see people telling others to use multi threading, instead of coroutines - just a lot of bad advice from people who are not understanding the basics of the way unity has been written.
The way I always think about Liskov Substitution is that "all dogs are animals, but not all animals are dogs." Meaning a base class can't necessarily be substituted for a child class, but a child can be substituted for a base class. So when designing behaviours, it's important to decide whether they belong on "dog" or on "animal" if they're something that everyone will share or not, and then when you call the class, is your behaviour on the base class or the child?
There's also another principle that says, "Code the rule, script the exception." In other words, hard code things that are certain and deal with anomalies as they show up. So all birds fly ... except ostriches and penguins. All mammals birth live young instead of laying eggs ... except for platypus. So a bird class with Fly and a mammal class with Birth Young still makes sense even though it's not absolute as it will handle 99% of cases.
Finally! Some asset from Unity that helps begginers to boost their C# skills
I HAVE BEEN WAITING FOR THIS OMG!!!
For unity/C# Code Monkey is very top tier, no doubt !!
aitutorialmaker AI fixes this. Level up code with project.
Thanks that ebook is excellent as you say. Very useful indeed and should help get me out of some of my current poor design practices. So helpful!
Very, very cool stuff here ! The code technical debt is very concerning and slows down a project velocity very quicky
It's not that a technical debt slows down a project... it's that many devs just slap things together without a proper architecture. You SHOULD think of proper architecture, as well as, of the good performance practices from the start. If you don't - chances are, later on it'll be too late, because the good architecture can look and behave completely different. Educate yourself, know how stuff works under the hood, expand default functionality with things that make your life easier (like C# delegate event wrapper classes, they can even be dictionary mapped. Also just today I added a class that invokes event on trigger enter/exit, just so I can listen to collider triggers on another GameObject. Simple things, but help a ton)
Oooooo, this looks amazing! Thanks!
dude this looks really useful. thank you
It is very cool! Thank you for the information!
Thanks for showing this! I was actually learning about SOLID and all Patterns but this makes it much more easy and fun to learn!
This is excellent.
Really helpful video, thank you for this.
I need to find the time to check this out. 🤪
Awesome!
Very cool stuf i add this to my queue "thinks to make"
That's an impressive combo. I like to think they took inspiration on your idea to build an in-editor guide / tutorial ;)
It physically hurts, that Unity makes a book public with singletons without a service locator or dependency injection as good practice.
Those would be great topics to add to a future update! They've updated this e-book once so they might do it again in the future
Yeah, the only interesting DI pattern they used was this bit in the Dependency Inversion Principle sample:
// Unity's serialization system does not directly support interfaces. Work around this limitation
// by using a serialized reference to a MonoBehaviour that implements ISwitchable.
[SerializeField] private MonoBehaviour m_ClientBehaviour;
private ISwitchable m_Client => m_ClientBehaviour as ISwitchable;
Pretty underwhelming, given the importance of the pattern when it comes to the SOLID principles... but also understandable, given that it is a complicated topic in and of itself (with Unity in particular).
I just started watching your Kitchen Chaos tutorial, is there any more tutorial like this in the asset store?
given what can be learned in the project, what level of a Unity Developer a person can achieve?
Let's say I have a lot of different animal NPCs roaming around the map (hundreds total). Do you think there would be a significant performance increase if I segment them in some way like with a dirty pattern or something alike?
In my scenario most animals have a collider, but most of their function is either being there for aesthetics or a physical obstacle, and they roam around.
I think your scenario is fine without a dirty flag, but it will make sense to turn off the colliders if the player is far away.
Dirty flag is probably for something that's O(N^2) or higher time complexity that doesn't need to run every frame. I could be wrong.
Yup you should definitely avoid updating NPCs that are super far away, you can indeed test the distance and mark them as dirty if past a certain distance and if they are dirty hide visuals/colliders/logic. Then if the distance is under that threshold set it dirty again and make it all visible/enabled.
Is there something like this for DOTS? Entities, Bakers, Systems etc..
Not that I know of but that would be awesome!
I got about 30 errors on import
you can do MVVM in Unity!? What
Is interfaces just a C language thing? I use them in c++
It's a common feature in many language. C++ has no interfaces tho, only abstracts
Popular in Java / Spring as well
Many languages have something similar to interfaces, it's an extremely useful concept
👍
2nd last
Last
first