Or, you take a break from your project for 2 months, and you come back to it and realise how bad the code is. So you spend another month refactoring it..
@@dandandan01 Exactly! And after refactoring, you get frustrated because you didn't make much of a progress and take a break from the project for 2 months... The circle of code
This video should definitely be watched by anyone who´s starting out on game development, I could´ve spared so much time if only a video like this existed a couple years back. Great video! This video deserves all the likes!
It would just be confusing and intimidating to someone who’s starting out.. a lot of Unity jargon is used, and knowledge is assumed. Also, the content is interesting, but the way he delivers without a single pause makes it hard to focus.
I went to college and got a Bachelor's Degree in Computer Science, and the only pattern they talked about on this list was the Singleton pattern. I feel horribly cheated. Love your work, man!
I took a full year of CS before dropping it and switching declarations, only to come back and teach myself to code a decade later. University sure is a mixed bag.
Thanks for this! I'm a senior C# developer but most of my knowledge of patterns comes from developing Mobile/Desktop/Web apps. Knowing more about how to implement some of this patterns (some are used in my industry) helps me a lot to get my head around game dev (which is one of my childhood dreams). One small comment to keep in mind, on 8:46 the question mark is actually not related to the events. Its just an operator used to do inline null checks prior to running any method (actually called "null conditional operator"). Basically it saves you from writing something like: if(event != null) event.Invoke(); You can also use it to get values from possible null reference objects: if(nullableObject?.Property == 1) instead of if (nullableObject != null && nullableObject.Property == 1) Sorry for the nerdy post. Once again. Great video and thank you for taking the time to explain this!
when I begin to learn game dev, I can't sit down to Jason's videos, there are too many code and word I cant understand. But after lotta tutorials then I realize how Jason's videos are concise and comprehensive. thumbs up
This video randomly showed up in my feed. I'm glad it did. It's really nice to see design patterns being put to use together with Unity and explained very well. A lot of Unity resources out there teaches a lot of bad habits. Keep up the good work :-)
An issue I've had with a lot of unity resources/tutorials is they tend to get people really excited about the prospect of building a game, but don't really take the time to explain the thought process behind the design choice. It's a lot of "we need to create this, now we need to create this, write this script, and hit play. Thanks for watching!!!", where I ultimately don't feel like I've learned anything. I learned more from building my poorly designed number guessing game than any of these tutorials where the game is a lot cooler in the end.
I've refactored my current game about 5 times and I'm happy to say that I'm currently implementing all these patterns except flyweight, because it isn't as relevant in my project. Singleton and observer are definitely the most important and basic, but command really comes into its own when building complex ability systems. Great video.
I barely like videos, even more rarely comment anything, but you put so much effort and interest in you channel, that i cannot help but subscribe and like it
A couple of years ago I would have watched a video like this and thought:"Wtf is going on" but now I watched it and I know the whole thing and use most of the patterns in one way or the other in my daily rutines, not as a game developer but for developing integrations mostly and some web-dev too. Good video and easy to following along!
For anyone that wants to learn more design patterns: the Gang of 4 design patterns book is something to look at But really, the patterns this person is listing are actually pretty useful- courses tend to just cover a handful of design patterns and these were indeed some of the big ones we went over in my curriculum
Design patterns are really important, but many game devs ignore them and say that OOP for Unity is bad, that it is built to be used in more data-driven component-driven way. I appreciate videos about design patterns in Unity. I hope you will make another one in the future. It's really important for the Unity community and I thank you so much. I want to mention 1 more incredibly useful design pattern: Decorator. It's amazing for creating different "children" without inheritance and it helps you to follow the Single Responsibility and Open-Closed principles from SOLID. I can give a short example: you have a weapon decorator, then you want to have different types of weapon - you use the decorator to create concrete decorated weapon classes. For example you can share the same method Attack but you can modify the behavior of the Attack in every concrete decorated variant, or you can have entirely different methods and behaviors (but you can still share whole methods/behaviors between classes). It kinda makes your life harder with the Liskov's rule from SOLID, but you can still group "categories" of weapons via interfaces like IMeleeWeapon, IRangedWeapon and you can still have methods with parameter of type interface so you can pass different concrete decorated implementations in the same method (parameter). So it's really good pattern. Very useful for game dev. Especially if you already have a good Sword class (which is a concrete implementation of the WeaponDecorator) and it's perfectly working (and tested if you do Unit Tests), and you don't want to mess around this perfectly working class - you can decorate the decorated class again so you "extend it" with more logic, which could be not so perfect and tested logic, but it won't mess up with the base sword class. This is the Open-Closed rule - you must extend classes, instead of modifying them. This is really useful in game dev because we as devs have a crapton of ideas in our heads and we sometimes fuck up really good classes with extra gameplay and logic and then we can't "rollback" the class to its older version, because we don't want to lose the new logic. With Decorator you can "fix" your new logic without losing the old logic (while using the old logic). You can also make easier patches/updates to your game this way. For example your game is perfectly working, you want to add more gameplay. It's safer to add the new gameplay in decorated implementations, because the game will be perfectly fine while using the old logic. This way you can implement the new behavior only for your DLC for example. It's like an really old website and you start updating it to version 2.0. You decorate the old classes and slowly replace the old stuff with new stuff. If you directly change the old logic, you will not be able to return the website in a good working condition with the new features.
i would love to get finally to start at some company, but every company rejects me and i never really experience the need of patterns. so to this day i dont see any need for patterns or oop, because i could effortless programm everything i needed without performance breaks or something
@@artjom5617 Do the gamedev as you wish and use whatever you want to use. It's a personal preference. I don't work in a company, but I always use OOP, SOLID and Design Patterns in my solo playgrounds. I find OOP useful and native, and very straightforward because I have used OOP my whole life (last 19 years) - school, university, work with c# (both startup and enterprise-level projects). I can give an example of my last solo project for a startup company in my enterprise-level company (complicated, right?). I had to create 108 c# classes architecture of wrappers like Repository Pattern, Unit of Work. I had 8 domain models (classes like Product, User) and more than 170 other "useless" classes, mockups, 108 of which were the layers of architecture. Seems heavy. Seems useless for sure. You don't have to overcomplicate simple projects. If you have 8 domain classes, you don't need more than 20 architecture/utility classes, but still using the raw data without design patterns is not future-proved.
@@Abken. im not that far into that, i didnt really understand what all that means. i learned c# just buy googling in theards for solutions and never someone talked about oop or patterns... well, maybe in some years i will find someone using it next to me
@@artjom5617 Oh, OOP is not something scary and hard. The pillars of OOP are encapsulation (make variables and methods to be inaccessible from other classes), inheritance, polymorphism. Read about these 3. Start simple. You probably have 80%+ of the required skills. OOP is more of an idea, concept, than coding. The idea is that you make your code safe, unified, readable for outsiders, and readable for yourself. It's much easier to read nicely structured code. Especially after 6 months you will have no idea which script is where and how it works, if the code is not following any rules, concepts, structure. So OOP helps you in the long run. You write a little more code (most of the times 10 lines files), but it saves you much more time in the future (readability, extensibility, reusability).
As a mobile and web developer who enter the game dev about a year ago, it's really nice to see content like this. I was used to these architectures and design patterns before and until now, Unity community seemed kinda messier with this topic. I even wrote some patterns to help me out in this transition. Definitely gonna read and test some of those!
Thankful to have found this video. Event emitters and listeners have been sort of intimidating for me, but your section around 6:50 was a really great introduction to them. Even just using them on the level shown here will save me tons of time. No need to reference objects in my script, and it'll keep my classes by having them call their own functions, instead of having a function being called from a separate class and not knowing where its coming from. Quickly tested it out by having the space bar invoke an event, and cubes would toggle on/off if they were listening to that event. It all worked. In Jason, I trust.
seemed like the most appropriate description of that segment :) the chapters are a new YT feature btw, just have to include a 0:00 marker to make it work
There are definitely over 100 design pattterns when you start looking at patterns from other types of development paradigms. I looked into this very question of how many design patterns there are and I was shocked at how many there are. Your explanations are clear and that book you pointed out is a great starting place for dp's.
Still come back to this. I'm a "self taught" dev, I've struggled to get the knowledge I have and I'm far from experienced but I can code. Videos like this fine tune what I've learned and give me more solutions. So I appreciate all your work, man. Thank you.
These are the best Unity videos on the web. Thank you so much for your hard work. The explanations are concise with great examples, but not in-depth enough that the viewer doesn't have to do their own work to understand the concepts more deeply (which is a good thing).
I've used these patterns when making digital card games. I found the Command pattern particularly useful for queuing up animations! The command pattern also works very well for queuing card effects which require the player's input, like asking the player to select multiple targets one after another or do a series of actions.
Card games are a great use for the command pattern. Most teams i know building them use some variation of it. Replays and undos become almost free to add :)
THIS IS GOOD! it's nice to see proper coding in game dev! I'm still new to Unity but I've been coding in C# since 2000. I've been watching a lot of videos and sometimes I'm shocked at some of the spaghetti that's being taught
What's the pattern that you should invest into if you want to make simple indie games (developed by a very small team) in your opinion? And which one is the most seekd after by employers? Thank you!
As a veteran game developer with over 6 years of experience in unity i would like to say that this is a very informative and on point tutorial for all new beginners! A must read for everyone trying transiting to game development or trying to learn! Very well done.
I just implemented the command patern in my game to create a cinematic camera motion effect on demand. Coupled it with an event system for easier calling and avoiding having anything on update and I must say, it works great. Also swapped out Queue for List for easier manipulation (inserting preset commands when and where i need them). Thanx for the informative video Jason. Keep up the good work.
I really love your videos, and I'm especially grateful for topics like this where you take an almost academic approach to game dev as it relates to core dev principals. Design patterns are a bit of a blessing and a curse for me. I love having this array of simple, well-tested, and generalized solutions to common problems from which to draw from. My main problem with design patterns is in recognizing when I'm faced with a problem for which there is already a pattern. Maybe run this past your other subscribers, cause I'm sure I'm not the only one, but I'd really love it if you did deep dives of as many use cases for each pattern as possible.
Hi Jason! I have an exam in a few weeks regarding some of the patterns you just showed. Really appriciate that you have taken your time and explained them in a very easy way. Great video!
Very interesting video. I've unknowingly used the first 2 patterns in my amateur game development endeavors. I'm definitely looking to learn to design games better and get more comfortable with game development in general.
Wow, you just made my mind expand with command pattern (since we are making turn based game where player moves on the grid). I made a complex state machine that doesn't extend mono behavior and I came to a problem with movement after mouse click (list was created but movement was done in a really wonky way since I didn't know any other way except coroutines).... I erased all the movement and just created a command pattern where after the click on the desired location it will queue the pathfound nodes (in reverse order, so last one is first, second to last is second, etc.) and go trough the queue in reverse order and just remove the last command from the stack (so that it doesn't have to shift the whole queue to the left, just because I like it that way more and I think it's more performance friendly).
Fricken thank you so very much!!! online classes have been killing me since I couldn't directly ask my classmates or teachers like i usuall do... and this video saved my ass this time.. I can't thank you enought
Is it common to use multiple design patterns for different aspects of your game? For example an RTS that uses: - Singleton Design Pattern for Score & Health - State Design Pattern for AI Behaviour - Command Design Pattern for Processing Building
I bought the book to support the channel from the affiliate link ^^^. Sure, I can get all these patterns for free elsewhere on the net but if it helps our man here who is making great video game content, then why not. Now onto the next game dev video. May the code be with you!
perfect video for me right now. I like your teaching and explaining style. You go more into details than other ppl and also add real life examples from your own experience and it makes complete picture.
I haven’t watched the video just yet but since I’m here so early I would just like to thank you so much for all of your content. It has helped me with my own projects IMMENSELY! Cheers
Singletons are fine in vanilla C# if implemented properly, but singleton MonoBehaviours are a massive *anti-pattern* where so much can go wrong thanks to the lack of constructors. Relying on Awake() will fail when another script that is earlier in the execution order references the singleton in it's Awake(), and if the singleton's MonoBehaviour is disabled, its Awake() isn't called at all. This is very unsafe. I can't think of any scenario where it isn't better to use a static class, or static methods on a MonoBehaviour, or just have a single class that you can easily keep track of that gets initialised before *anything* and is set up to contain static references to all of your otherwise singleton MonoBehaviours. Eg. instead of Single.Instance, Gatekeeper.Single.
This video hit me in the nick of time since I'm in the middle of rewriting a messy game to be made "colleague friendly" One pattern I find really useful for people who really want to implement the "S" in the SOLID principles is the Model-View-Controller pattern Not sure if you've talked about it already
im doing a pokemon style game with javascript and canvas, I'm a new developer with 1 yoe as a full stack web developer but wanted to add something complex to my portfolio, I've made a lot of progress but realised the project was getting hard to work with, I'm unfamiliar with patterns but just implemented the factory pattern for object creation, think I'll need to use the state and observer patterns, singleton too if I need to create an object in the game loop which currently I don't, really glad I've done this I'm learning a lot despite the headaches along the way
The better alternative to singletons (imo) is dependency injection. If your class needs access to some functionality, just make sure its passed down to it with a constructor or init method. Use an interface for that functionality and you should be golden.
Good vid. Being able to put a proper label to a technique is very handy when working with others, so thanks for going over these! Even better that you showed examples.
I use the "dont try to write prototypes cleanly" pattern. EG: first try to solve a problem in a prototype, and only afterwards rewrite it in a cleaner form to implement it in the main project. (much can likely be copies over) Overengineering a prototype could lead to a lot of wasted time, and less iterations on the prototype to improve its output.
Dear Jason! Im just getting in to the game dev thingy, and I really enjoy your content! Thanks for the great videos! Dont you ever thoguth about going podcast format as well? I'd really love to listen to them!
state pattern is just greate. It helped me a lot to improv my self. Just by using state pattern I got rid of singletons and other stuff. I recommend everyone to learn state pattern. For me it is the best pattern for small to mid size games
Nice to find that one of the solutions i've used in my game is actually a pattern that had a name and a clear definition that managed to fit almost perfectly to it.
13:45 - I believe it is considered a bad practice to do "if (something == false)". For boolean logic, boolean operations should be used - this case should look like "if (!something)". Correct me please, if there's a reason for writing it your way
Its definitely longer, but ive seen people miss the ! too many times to use it in tutorial videos. Its only a matter of readability though, there's no technical difference in that case.
This was a really good video. I think it's worth noting that these patterns are useful across every domain of software engineering, not just game development. I work on SaaS for a major tech company, and we use these patterns all the time in various forms. Ultimately, learning design patterns is pretty easy and I encourage everyone to familiarize themselves. The tricky part is learning when to use them in your code. The people who have mastered this skill tend to have the word "Senior" somewhere in their title 😉
Thanks for the video Jason. Although I use patterns on a regular basis, it's always uplifting to watch one of your videos before I start developing. I am also curious about the Builder Pattern for testing but couldn't find a short tutorial about it. Some other guys have released videos but another favourite of mine uses external packages so it's somewhat hard to follow. I would really like to see you doing one.
Almost in my all project I use these technique. But now i got it these are called patterns. Thanks a lot :) Please make more & more videos to clean up code......
Great video! The explanations were well thought out and clear to understand. Hope to have more programming videos since you're really good at teaching them. Thanks a bunch!
As a really new beginner who's gone through the 'Brackeys' phase the next logical step is the Jason Weimann phase haha. More advanced, but much better for long term progress.
Hey Jason awesome video. I'm looking at your unity game dev mastery course and considering enrolling. The amounts a bit steep so I just want to get a better understanding of what I can expect before committing. I have a little under 2 years of experience with unity and c#
Thank you so much. I promise this information will be directly and accurately funneled into the right minds. This just connected some dots for me that nothing else was able to do before. You should just know that you made a difference here.
Jason, it is the best explanation of Command pattern and Flyweigh pattern which I have ever seen🔥🔥🔥🔥 But propery block is not a pattern, it's more like a feature, which you should know) I think you forgot to add Pull Object pattern to this list of Design Patterns Thank you so much!
Hey, I just wanted to say thank you for making these kinds of videos and helping new people enter the game development industry. I am motivated since I was about 9 years old to become a game dev programmer. And since then I am still motivated and disciplined enough to do all I kan to become a full-time game dev. And I want to say thank you for making these videos because whenever I am wavering because I am not sure if I will succeed to do my dream job. You place online a video and it gives me hope that one day I can work as a game dev and make 1 game to make someone happy in this world that had a bad day. Thank you
new unsafe protected volatile internal static readonly byte ONE = 1; god - i love keywords PS: "unsafe protected" - kinda want to go all out philosophical on that
@@kressckerl my favorite is readonly instance field, readonly structs(as a type) and the System.ComponentModel.ReadOnly(true) attribute on properties prior to C#8. Always feels like the compiler uses that information well, in addition to encapsulation during development of course.
This is great! Many tutorials just give you code without explaining it. As an experienced programmer I'm more interested in software design patterns in game design!
Patterns missed in this video: the Strategy pattern comes to mind, mostly because it is highly copacetic with the Observer, Command, Component, & State patterns already mentioned... and has some obvious implications for any game with big lists of stuff with different in game effects. Arbitrary example: cards in Slay the Spire (& it's ever increasing number of clones :p). All the cards have different in-game effects, but they are also all describable in general terms: casting cost, effect once casted, & conditions which can prevent them from being casted. The latter 2 properties could utilize a strategy pattern, potentially reducing the number of distinct types you need to have as well as duplicated logic. Eg. all the attacks in slay the spire which require them to be the only attack in hand to use: single 'isOnlyAttack' strategy plugin. Or all the simple block cards would use the same game-effect strategy, but with a different 'block-value' param
I'm really digging the command pattern, currently making a single player card game where a queue would be really useful. Thinking of using it together with the gameplay ability system in Unreal.
In 2020, Singleton has already been recognized as an anti-pattern for ages. Please let it vanish for good. There's a very good reason we have SOLID, and singletons bust it big time. Use an instance manager, e.g. a Factory (also a pattern that comes handy), to control how your stuff can or cannot be instantiated. There are other solutions to avoid the Singleton, but this is perhaps the most straightforward one. For Observer, I'd advise you to keep in mind that any failure to unsubscribe when due will lead to various issues you'd probably rather not face, e.g. memory leaks or use-after-free madness. The Abstract Factory, when used in a certain way, can be of tremendous utility. Long story short, you can inject factories or providers into your system components so that things can be instantiated without directly depending on them or your component having to deal with the details of how the thing is pieced together. A pattern somewhat similar to Command is the Strategy pattern, which among other uses, is very good in many (although not all) decision making cases and thus also excels at getting rid of switch-case statements, the employment of which should anyways have provoked capital punishment for at least 20 years now. Instead of the horror of unmaintainable, hard-and-ill-coded switch ladders (or equivalent if-ladders, which are almost as bad), you can introduce neat and clean decision tables using dictionaries and pick your strategy using your condition variable as the key. Oh, and such solutions are also very dynamic in nature. You can e.g. alter your decision table on the fly if you want. Languages with reflection capabilities even allow you to load decision tables from config files with ease. It can also be of help when implementing a certains cases of the State pattern. Then there's the Mediator. Loose coupling can be pretty handy if you don't want to end up pulling your hair out over some spaghetti that keeps breaking or at best restricting you to sub-par solutions. If implemented correctly, it is very effective in keeping parts of your system completely oblivious, hence independent, from each other. And, of course, Dependency Injection wherever applicable. If possible, via constructors, so that you have precise and foolproof control over what is mandatory at init time. Object, not necessarily system init time that is. And if all else fails, there's the "f*ck this, I'm out for a beer" pattern.
Don't forget the Refractory pattern: you watch a video on patterns and you go refactor all your code.
@Ed Cole indeed, that's the most widely used pattern! 😂
Or, you take a break from your project for 2 months, and you come back to it and realise how bad the code is. So you spend another month refactoring it..
@Ed Cole, I feel you man. 😪😂😂
lol i cant count how many times ive done this.
@@dandandan01 Exactly! And after refactoring, you get frustrated because you didn't make much of a progress and take a break from the project for 2 months...
The circle of code
This video should definitely be watched by anyone who´s starting out on game development, I could´ve spared so much time if only a video like this existed a couple years back. Great video! This video deserves all the likes!
Glad I could help!
It would just be confusing and intimidating to someone who’s starting out.. a lot of Unity jargon is used, and knowledge is assumed. Also, the content is interesting, but the way he delivers without a single pause makes it hard to focus.
What's your favourite pattern? Which one is the most demanded by employers in your opinion?
@@TheSaintsVEVO Can confirm lol
I went to college and got a Bachelor's Degree in Computer Science, and the only pattern they talked about on this list was the Singleton pattern.
I feel horribly cheated.
Love your work, man!
I got a CS degree too. Learned singletons, and nothing else. Took me too long to realize I wanted a degree in software engineering, not cs
I took a full year of CS before dropping it and switching declarations, only to come back and teach myself to code a decade later.
University sure is a mixed bag.
Wow! Now I feel lucky that I got to study 15 different patterns in uni
Studying Game Programming I learned all of these to some extend even if some having a dedicated lecture or lesson
Universities are lagging behind very hard. IT develops faster than universities adapt.
Thanks for this! I'm a senior C# developer but most of my knowledge of patterns comes from developing Mobile/Desktop/Web apps.
Knowing more about how to implement some of this patterns (some are used in my industry) helps me a lot to get my head around game dev (which is one of my childhood dreams).
One small comment to keep in mind, on 8:46 the question mark is actually not related to the events. Its just an operator used to do inline null checks prior to running any method (actually called "null conditional operator").
Basically it saves you from writing something like:
if(event != null)
event.Invoke();
You can also use it to get values from possible null reference objects:
if(nullableObject?.Property == 1)
instead of
if (nullableObject != null && nullableObject.Property == 1)
Sorry for the nerdy post.
Once again. Great video and thank you for taking the time to explain this!
We are all nerds and geeks here my freind, it only promotes your status.
when I begin to learn game dev, I can't sit down to Jason's videos, there are too many code and word I cant understand. But after lotta tutorials then I realize how Jason's videos are concise and comprehensive. thumbs up
This video randomly showed up in my feed. I'm glad it did. It's really nice to see design patterns being put to use together with Unity and explained very well. A lot of Unity resources out there teaches a lot of bad habits. Keep up the good work :-)
Glad it was helpful!
An issue I've had with a lot of unity resources/tutorials is they tend to get people really excited about the prospect of building a game, but don't really take the time to explain the thought process behind the design choice. It's a lot of "we need to create this, now we need to create this, write this script, and hit play. Thanks for watching!!!", where I ultimately don't feel like I've learned anything. I learned more from building my poorly designed number guessing game than any of these tutorials where the game is a lot cooler in the end.
NGL these patterns are game changer. Helps make the code more efficient and readable.
I've refactored my current game about 5 times and I'm happy to say that I'm currently implementing all these patterns except flyweight, because it isn't as relevant in my project. Singleton and observer are definitely the most important and basic, but command really comes into its own when building complex ability systems. Great video.
God it was far easy than I thought. Thanks for connecting the dots. Showing an proper example is the best method damn.
I barely like videos, even more rarely comment anything, but you put so much effort and interest in you channel, that i cannot help but subscribe and like it
A couple of years ago I would have watched a video like this and thought:"Wtf is going on" but now I watched it and I know the whole thing and use most of the patterns in one way or the other in my daily rutines, not as a game developer but for developing integrations mostly and some web-dev too. Good video and easy to following along!
For anyone that wants to learn more design patterns: the Gang of 4 design patterns book is something to look at
But really, the patterns this person is listing are actually pretty useful- courses tend to just cover a handful of design patterns and these were indeed some of the big ones we went over in my curriculum
Design patterns are really important, but many game devs ignore them and say that OOP for Unity is bad, that it is built to be used in more data-driven component-driven way. I appreciate videos about design patterns in Unity. I hope you will make another one in the future. It's really important for the Unity community and I thank you so much.
I want to mention 1 more incredibly useful design pattern: Decorator. It's amazing for creating different "children" without inheritance and it helps you to follow the Single Responsibility and Open-Closed principles from SOLID. I can give a short example: you have a weapon decorator, then you want to have different types of weapon - you use the decorator to create concrete decorated weapon classes. For example you can share the same method Attack but you can modify the behavior of the Attack in every concrete decorated variant, or you can have entirely different methods and behaviors (but you can still share whole methods/behaviors between classes). It kinda makes your life harder with the Liskov's rule from SOLID, but you can still group "categories" of weapons via interfaces like IMeleeWeapon, IRangedWeapon and you can still have methods with parameter of type interface so you can pass different concrete decorated implementations in the same method (parameter).
So it's really good pattern. Very useful for game dev. Especially if you already have a good Sword class (which is a concrete implementation of the WeaponDecorator) and it's perfectly working (and tested if you do Unit Tests), and you don't want to mess around this perfectly working class - you can decorate the decorated class again so you "extend it" with more logic, which could be not so perfect and tested logic, but it won't mess up with the base sword class. This is the Open-Closed rule - you must extend classes, instead of modifying them. This is really useful in game dev because we as devs have a crapton of ideas in our heads and we sometimes fuck up really good classes with extra gameplay and logic and then we can't "rollback" the class to its older version, because we don't want to lose the new logic. With Decorator you can "fix" your new logic without losing the old logic (while using the old logic).
You can also make easier patches/updates to your game this way. For example your game is perfectly working, you want to add more gameplay. It's safer to add the new gameplay in decorated implementations, because the game will be perfectly fine while using the old logic. This way you can implement the new behavior only for your DLC for example. It's like an really old website and you start updating it to version 2.0. You decorate the old classes and slowly replace the old stuff with new stuff. If you directly change the old logic, you will not be able to return the website in a good working condition with the new features.
yes, very important pattern!
i would love to get finally to start at some company, but every company rejects me and i never really experience the need of patterns. so to this day i dont see any need for patterns or oop, because i could effortless programm everything i needed without performance breaks or something
@@artjom5617 Do the gamedev as you wish and use whatever you want to use. It's a personal preference. I don't work in a company, but I always use OOP, SOLID and Design Patterns in my solo playgrounds. I find OOP useful and native, and very straightforward because I have used OOP my whole life (last 19 years) - school, university, work with c# (both startup and enterprise-level projects). I can give an example of my last solo project for a startup company in my enterprise-level company (complicated, right?). I had to create 108 c# classes architecture of wrappers like Repository Pattern, Unit of Work. I had 8 domain models (classes like Product, User) and more than 170 other "useless" classes, mockups, 108 of which were the layers of architecture. Seems heavy. Seems useless for sure. You don't have to overcomplicate simple projects. If you have 8 domain classes, you don't need more than 20 architecture/utility classes, but still using the raw data without design patterns is not future-proved.
@@Abken. im not that far into that, i didnt really understand what all that means.
i learned c# just buy googling in theards for solutions and never someone talked about oop or patterns... well, maybe in some years i will find someone using it next to me
@@artjom5617 Oh, OOP is not something scary and hard. The pillars of OOP are encapsulation (make variables and methods to be inaccessible from other classes), inheritance, polymorphism. Read about these 3. Start simple. You probably have 80%+ of the required skills. OOP is more of an idea, concept, than coding. The idea is that you make your code safe, unified, readable for outsiders, and readable for yourself. It's much easier to read nicely structured code. Especially after 6 months you will have no idea which script is where and how it works, if the code is not following any rules, concepts, structure. So OOP helps you in the long run. You write a little more code (most of the times 10 lines files), but it saves you much more time in the future (readability, extensibility, reusability).
Never woulda thought the dewd who made the games i loved, shared the same name as me and would also got on to teach me about game development.
Truly a lucky age to be born into.
As a mobile and web developer who enter the game dev about a year ago, it's really nice to see content like this.
I was used to these architectures and design patterns before and until now, Unity community seemed kinda messier with this topic. I even wrote some patterns to help me out in this transition. Definitely gonna read and test some of those!
Thankful to have found this video. Event emitters and listeners have been sort of intimidating for me, but your section around 6:50 was a really great introduction to them. Even just using them on the level shown here will save me tons of time. No need to reference objects in my script, and it'll keep my classes by having them call their own functions, instead of having a function being called from a separate class and not knowing where its coming from. Quickly tested it out by having the space bar invoke an event, and cubes would toggle on/off if they were listening to that event. It all worked. In Jason, I trust.
I never seen anyone upload a video with labeled markers... one of which in this case is 'Beg for Like" . Awesome. Thumbs up.
seemed like the most appropriate description of that segment :)
the chapters are a new YT feature btw, just have to include a 0:00 marker to make it work
There are definitely over 100 design pattterns when you start looking at patterns from other types of development paradigms. I looked into this very question of how many design patterns there are and I was shocked at how many there are. Your explanations are clear and that book you pointed out is a great starting place for dp's.
Still come back to this. I'm a "self taught" dev, I've struggled to get the knowledge I have and I'm far from experienced but I can code.
Videos like this fine tune what I've learned and give me more solutions. So I appreciate all your work, man. Thank you.
Very important information, working as dev 15 years now, everyone thats codes must use all designer patterns as needed. Good job!
I watched this about 3 months ago, and now use almost every single one of these patterns in the game I'm working on right now, thanks for making this!
These are the best Unity videos on the web. Thank you so much for your hard work. The explanations are concise with great examples, but not in-depth enough that the viewer doesn't have to do their own work to understand the concepts more deeply (which is a good thing).
Wow, thanks!
I've used these patterns when making digital card games. I found the Command pattern particularly useful for queuing up animations! The command pattern also works very well for queuing card effects which require the player's input, like asking the player to select multiple targets one after another or do a series of actions.
Card games are a great use for the command pattern. Most teams i know building them use some variation of it. Replays and undos become almost free to add :)
What other patterns did you use and for what game genre? Thank you!
THIS IS GOOD! it's nice to see proper coding in game dev! I'm still new to Unity but I've been coding in C# since 2000. I've been watching a lot of videos and sometimes I'm shocked at some of the spaghetti that's being taught
What's the pattern that you should invest into if you want to make simple indie games (developed by a very small team) in your opinion? And which one is the most seekd after by employers? Thank you!
As a veteran game developer with over 6 years of experience in unity i would like to say that this is a very informative and on point tutorial for all new beginners!
A must read for everyone trying transiting to game development or trying to learn!
Very well done.
Veteran eh? Mind sharing any of your published work?
I just implemented the command patern in my game to create a cinematic camera motion effect on demand. Coupled it with an event system for easier calling and avoiding having anything on update and I must say, it works great. Also swapped out Queue for List for easier manipulation (inserting preset commands when and where i need them).
Thanx for the informative video Jason. Keep up the good work.
I'm considering getting into game design. This channel is basically my education
You can use the built-in features of C# for these two patterns:
observer pattern = event & delegate
command pattern = lambda functions
I would be interested as well in the lambda expression thing ! :)
That Command Pattern is exactly what my game needed. Thank you!
Glad I could help!
7:16 OH, that's what it does. That was the quickest, easiest explanation of that syntax, thankyou.
Hey Jason, dropping by to say it's good to see a new video from you! Hope you and your family are well.
Thanks! You too!
I really love your videos, and I'm especially grateful for topics like this where you take an almost academic approach to game dev as it relates to core dev principals.
Design patterns are a bit of a blessing and a curse for me. I love having this array of simple, well-tested, and generalized solutions to common problems from which to draw from. My main problem with design patterns is in recognizing when I'm faced with a problem for which there is already a pattern. Maybe run this past your other subscribers, cause I'm sure I'm not the only one, but I'd really love it if you did deep dives of as many use cases for each pattern as possible.
Hi Jason! I have an exam in a few weeks regarding some of the patterns you just showed. Really appriciate that you have taken your time and explained them in a very easy way. Great video!
Very interesting video. I've unknowingly used the first 2 patterns in my amateur game development endeavors. I'm definitely looking to learn to design games better and get more comfortable with game development in general.
This has been massively helpful, thanks Jason!
Wow, you just made my mind expand with command pattern (since we are making turn based game where player moves on the grid). I made a complex state machine that doesn't extend mono behavior and I came to a problem with movement after mouse click (list was created but movement was done in a really wonky way since I didn't know any other way except coroutines)....
I erased all the movement and just created a command pattern where after the click on the desired location it will queue the pathfound nodes (in reverse order, so last one is first, second to last is second, etc.) and go trough the queue in reverse order and just remove the last command from the stack (so that it doesn't have to shift the whole queue to the left, just because I like it that way more and I think it's more performance friendly).
Fricken thank you so very much!!! online classes have been killing me since I couldn't directly ask my classmates or teachers like i usuall do... and this video saved my ass this time.. I can't thank you enought
Wow! This would have saved me hundreds of if else statements and object references if I knew these earlier. Thanks so much!
You're very welcome!
I really like that Command pattern. I need to remember that one, particularly.
I've always liked how organized you are coming into your videos. Not a lot of "oops, I had something for this".
Is it common to use multiple design patterns for different aspects of your game?
For example an RTS that uses:
- Singleton Design Pattern for Score & Health
- State Design Pattern for AI Behaviour
- Command Design Pattern for Processing Building
Thank you for timestamping the timeline of the video! Really useful if you already know some of the patterns.
I bought the book to support the channel from the affiliate link ^^^. Sure, I can get all these patterns for free elsewhere on the net but if it helps our man here who is making great video game content, then why not. Now onto the next game dev video. May the code be with you!
Thanks for the video, Jason. Really helpful. Keep up the good work !! Respect from India.
the copy/paste pattern is by far my favorite. Saves time, and time is money.
The fact that you have a Tupac Shakur book on your shelf😂 🔥
Oh, wonderful, actually I was just about to search some good tutorial about design patterns. Thanks for the always excellent videos! :)
Szia Bálint
@@iGhostr Dr Penny de Byn has 12 hour course on udemy
This has been a super helpful video, both for my hobby as a game developer and for my job as a software developer! Thank you for making these videos!
perfect video for me right now. I like your teaching and explaining style. You go more into details than other ppl and also add real life examples from your own experience and it makes complete picture.
I haven’t watched the video just yet but since I’m here so early I would just like to thank you so much for all of your content. It has helped me with my own projects IMMENSELY! Cheers
Ahh thx!
it helped me also so much
Jason is one of the best resources for game development out there, and has definitely influenced my projects quite a bit too !!
Singletons are fine in vanilla C# if implemented properly, but singleton MonoBehaviours are a massive *anti-pattern* where so much can go wrong thanks to the lack of constructors. Relying on Awake() will fail when another script that is earlier in the execution order references the singleton in it's Awake(), and if the singleton's MonoBehaviour is disabled, its Awake() isn't called at all. This is very unsafe. I can't think of any scenario where it isn't better to use a static class, or static methods on a MonoBehaviour, or just have a single class that you can easily keep track of that gets initialised before *anything* and is set up to contain static references to all of your otherwise singleton MonoBehaviours. Eg. instead of Single.Instance, Gatekeeper.Single.
This video hit me in the nick of time since I'm in the middle of rewriting a messy game to be made "colleague friendly"
One pattern I find really useful for people who really want to implement the "S" in the SOLID principles is the Model-View-Controller pattern
Not sure if you've talked about it already
im doing a pokemon style game with javascript and canvas, I'm a new developer with 1 yoe as a full stack web developer but wanted to add something complex to my portfolio, I've made a lot of progress but realised the project was getting hard to work with, I'm unfamiliar with patterns but just implemented the factory pattern for object creation, think I'll need to use the state and observer patterns, singleton too if I need to create an object in the game loop which currently I don't, really glad I've done this I'm learning a lot despite the headaches along the way
This is a great explanation of patterns and examples of each. Thanks for sharing your knowledge Jason.
The better alternative to singletons (imo) is dependency injection. If your class needs access to some functionality, just make sure its passed down to it with a constructor or init method. Use an interface for that functionality and you should be golden.
Good vid. Being able to put a proper label to a technique is very handy when working with others, so thanks for going over these! Even better that you showed examples.
Glad it was helpful!
I use the "dont try to write prototypes cleanly" pattern. EG: first try to solve a problem in a prototype, and only afterwards rewrite it in a cleaner form to implement it in the main project. (much can likely be copies over)
Overengineering a prototype could lead to a lot of wasted time, and less iterations on the prototype to improve its output.
Awesome video, took notes and I will go watch the state machine bot video and also try out the command pattern in one of my games, thanks Jason.
You sir, deserve a medal, honestly. thank you.
Glad it helped
Thanks for your efforts regarding game architecture ! Never saw this kind of discuss ion anywhere else.
Glad you liked it!
Dear Jason! Im just getting in to the game dev thingy, and I really enjoy your content! Thanks for the great videos!
Dont you ever thoguth about going podcast format as well? I'd really love to listen to them!
Its an idea I've considered.. maybe sometime :)
state pattern is just greate. It helped me a lot to improv my self. Just by using state pattern I got rid of singletons and other stuff. I recommend everyone to learn state pattern. For me it is the best pattern for small to mid size games
"Beg for likes" 🤣 straight forward but you deserve likes
Squeak wheel; receive grease
Thanks for demonstrating by concise examples.
Very good video, I use these on a daily bases. It's always good to hear another dev cover the basics.
Nice to find that one of the solutions i've used in my game is actually a pattern that had a name and a clear definition that managed to fit almost perfectly to it.
Great video mate, a solid overview of the main patterns. Cheers
Cool. Really good review of the different patterns Jason 👍🤓
13:45 - I believe it is considered a bad practice to do "if (something == false)". For boolean logic, boolean operations should be used - this case should look like "if (!something)". Correct me please, if there's a reason for writing it your way
Its definitely longer, but ive seen people miss the ! too many times to use it in tutorial videos.
Its only a matter of readability though, there's no technical difference in that case.
This was a really good video. I think it's worth noting that these patterns are useful across every domain of software engineering, not just game development. I work on SaaS for a major tech company, and we use these patterns all the time in various forms.
Ultimately, learning design patterns is pretty easy and I encourage everyone to familiarize themselves. The tricky part is learning when to use them in your code. The people who have mastered this skill tend to have the word "Senior" somewhere in their title 😉
Always appreciate your videos Jason- you create some of the best content for intermediate developers and it's always a great resource.
My pleasure!
I actually LOVE to use the "Well, this ain't going to affect that much so I'll leave it here" design pattern.
Really filled in some gaps for me. Thanks for making this!
Glad it was helpful!
This is my new best channel to watch. Great explanations, love the video !
Thanks for the video Jason. Although I use patterns on a regular basis, it's always uplifting to watch one of your videos before I start developing. I am also curious about the Builder Pattern for testing but couldn't find a short tutorial about it. Some other guys have released videos but another favourite of mine uses external packages so it's somewhat hard to follow. I would really like to see you doing one.
Almost in my all project I use these technique. But now i got it these are called patterns.
Thanks a lot :)
Please make more & more videos to clean up code......
good to see a new video from you!
Great video! The explanations were well thought out and clear to understand. Hope to have more programming videos since you're really good at teaching them. Thanks a bunch!
Nice ☺
More in-depth videos like this, please!
You got it!
As a really new beginner who's gone through the 'Brackeys' phase the next logical step is the Jason Weimann phase haha. More advanced, but much better for long term progress.
This should now be referred to as the Newby Gamedev Pattern
This was a fantastic video. The section on Command Patterns was particularly helpful. Thank you!
14:39 Minor thing to point,since the abstract class Command doesnt have any implementation,an Interface may have been another choice.
Great video as always. Definitely cleared up a lot of misconceptions I previously had about design patterns.
You don't have to beg for likes. That button is meant for people like you. Thank you Guru.
Hey Jason awesome video. I'm looking at your unity game dev mastery course and considering enrolling. The amounts a bit steep so I just want to get a better understanding of what I can expect before committing. I have a little under 2 years of experience with unity and c#
Yes sir please make video series on c# please
Yes yes pls do consider making a series on c# 😇
checkout GameDevHq channel for c# unity
Thank you so much. I promise this information will be directly and accurately funneled into the right minds. This just connected some dots for me that nothing else was able to do before.
You should just know that you made a difference here.
Got a job in game dev thanks to you so much thanks always.
Jason, it is the best explanation of Command pattern and Flyweigh pattern which I have ever seen🔥🔥🔥🔥
But propery block is not a pattern, it's more like a feature, which you should know)
I think you forgot to add Pull Object pattern to this list of Design Patterns
Thank you so much!
Hey, I just wanted to say thank you for making these kinds of videos and helping new people enter the game development industry. I am motivated since I was about 9 years old to become a game dev programmer. And since then I am still motivated and disciplined enough to do all I kan to become a full-time game dev. And I want to say thank you for making these videos because whenever I am wavering because I am not sure if I will succeed to do my dream job. You place online a video and it gives me hope that one day I can work as a game dev and make 1 game to make someone happy in this world that had a bad day. Thank you
new unsafe protected volatile internal static readonly byte ONE = 1;
god - i love keywords
PS: "unsafe protected" - kinda want to go all out philosophical on that
Same. I use sealed whenever possible
@@kressckerl my favorite is readonly instance field, readonly structs(as a type) and the System.ComponentModel.ReadOnly(true) attribute on properties prior to C#8.
Always feels like the compiler uses that information well, in addition to encapsulation during development of course.
Singletons pattern can be used to create manager classes like SoundManager or AdManager or any thing you would to handle from one place.
Thanks, Jason. That's a super helpful introduction to design patterns! Definitely something a lot more starting game dev could use
This is great! Many tutorials just give you code without explaining it. As an experienced programmer I'm more interested in software design patterns in game design!
Patterns missed in this video: the Strategy pattern comes to mind, mostly because it is highly copacetic with the Observer, Command, Component, & State patterns already mentioned... and has some obvious implications for any game with big lists of stuff with different in game effects.
Arbitrary example: cards in Slay the Spire (& it's ever increasing number of clones :p). All the cards have different in-game effects, but they are also all describable in general terms: casting cost, effect once casted, & conditions which can prevent them from being casted. The latter 2 properties could utilize a strategy pattern, potentially reducing the number of distinct types you need to have as well as duplicated logic.
Eg. all the attacks in slay the spire which require them to be the only attack in hand to use: single 'isOnlyAttack' strategy plugin. Or all the simple block cards would use the same game-effect strategy, but with a different 'block-value' param
Best channel you can find in youtube. !! thanks for your work !
Thank you too!
I'm really digging the command pattern, currently making a single player card game where a queue would be really useful. Thinking of using it together with the gameplay ability system in Unreal.
It works great for card games!
This was so helpful and well explained! I can't wait to try out some of these in my next project. Thank you!
Thanks, this video is very helpful for self taught students like me. It would be nice if you make a 2nd part in the future. :)
In 2020, Singleton has already been recognized as an anti-pattern for ages. Please let it vanish for good. There's a very good reason we have SOLID, and singletons bust it big time. Use an instance manager, e.g. a Factory (also a pattern that comes handy), to control how your stuff can or cannot be instantiated. There are other solutions to avoid the Singleton, but this is perhaps the most straightforward one.
For Observer, I'd advise you to keep in mind that any failure to unsubscribe when due will lead to various issues you'd probably rather not face, e.g. memory leaks or use-after-free madness.
The Abstract Factory, when used in a certain way, can be of tremendous utility. Long story short, you can inject factories or providers into your system components so that things can be instantiated without directly depending on them or your component having to deal with the details of how the thing is pieced together.
A pattern somewhat similar to Command is the Strategy pattern, which among other uses, is very good in many (although not all) decision making cases and thus also excels at getting rid of switch-case statements, the employment of which should anyways have provoked capital punishment for at least 20 years now.
Instead of the horror of unmaintainable, hard-and-ill-coded switch ladders (or equivalent if-ladders, which are almost as bad), you can introduce neat and clean decision tables using dictionaries and pick your strategy using your condition variable as the key. Oh, and such solutions are also very dynamic in nature. You can e.g. alter your decision table on the fly if you want. Languages with reflection capabilities even allow you to load decision tables from config files with ease.
It can also be of help when implementing a certains cases of the State pattern.
Then there's the Mediator. Loose coupling can be pretty handy if you don't want to end up pulling your hair out over some spaghetti that keeps breaking or at best restricting you to sub-par solutions. If implemented correctly, it is very effective in keeping parts of your system completely oblivious, hence independent, from each other.
And, of course, Dependency Injection wherever applicable. If possible, via constructors, so that you have precise and foolproof control over what is mandatory at init time. Object, not necessarily system init time that is.
And if all else fails, there's the "f*ck this, I'm out for a beer" pattern.