The 6 Design Patterns game devs need?
game.courses/mp/ - Multiplayer Mastery Course - Open NOW
We'll talk about which design patterns game programmers use, what design patterns are... and why you should care about them. I'll also show you how to implement each pattern in unity using some simple code and examples.
0:00 - Intro
1:11 - Beg for Likes
1:28 - Singleton Pattern
4:55 - Observer Pattern
9:52 - Command Pattern
16:32 - Component Pattern
17:41 - Flyweight Pattern
21:15 - State Pattern
22:35 - 100's of design patterns? (wrap-up and discussion)
More about patterns and courses: game.courses/intermediate/
Game Programming Patterns: gameprogrammingpatterns.com/
Game Programming Patterns Physical Book (Amazon Affiliate Link): amzn.to/2Ya0tnr
Join the Group: unity3d.group
Patreon: / unity3dcollege
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
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.
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
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.
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!
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!
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.
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!
This is a great explanation of patterns and examples of each. Thanks for sharing your knowledge Jason.
I really like that Command pattern. I need to remember that one, particularly.
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!
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).
Great video as always. Definitely cleared up a lot of misconceptions I previously had about design patterns.
Thanks, Jason. That's a super helpful introduction to design patterns! Definitely something a lot more starting game dev could use
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.
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.
This was so helpful and well explained! I can't wait to try out some of these in my next project. Thank you!
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!
This was a fantastic video. The section on Command Patterns was particularly helpful. Thank you!
This has been massively helpful, thanks Jason!
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!
God it was far easy than I thought. Thanks for connecting the dots. Showing an proper example is the best method damn.
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
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.
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!
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.
Thank you for timestamping the timeline of the video! Really useful if you already know some of the patterns.
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
Great video mate, a solid overview of the main patterns. Cheers
Thanks for demonstrating by concise examples.
This is my new best channel to watch. Great explanations, love the video !
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.
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.
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.
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 always liked how organized you are coming into your videos. Not a lot of "oops, I had something for this".
Very good video, I use these on a daily bases. It's always good to hear another dev cover the basics.
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.
Before implementing a singleton, be sure to read a few articles on how it can become an anti pattern when used in certain situations. It's one of the harder patterns to get right.
singletons are useless 90% of the time
Rule number 1 using singleton: don't use singleton. Lol kidding.
They should (and can) be avoided, but it's like talking to a wall, because all "popular" Unity KZheadr and even the official Unity tutorials promote them in their "beginner" videos, because it's easier to use a static thing instead of teaching them clean code. Which is kinda a shame, because the beginners don't understand the problem with singleton and will just use what they were teached by these videos.
Eh, they dont ALWAYS need to be avoided. For example if you are adding functionality in a big existing solution, and the executing context doesnt permit resolving dependencies. Best and easiest way is a singleton ServiceLocator.
Singletons are very easy, and I think it's fine to use as you're learning to program, but it's something you should know is an anti-pattern, and that you should try to not use them in a future project
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'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.
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
Cool. Really good review of the different patterns Jason 👍🤓
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 !!
comprehensive and really good examples!
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
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 tutorial! Tnx! I learned one pattern that I was looking for!
Very important information, working as dev 15 years now, everyone thats codes must use all designer patterns as needed. Good job!
Thanks for your efforts regarding game architecture ! Never saw this kind of discuss ion anywhere else.
Glad you liked it!
7:16 OH, that's what it does. That was the quickest, easiest explanation of that syntax, thankyou.
Amazing, I learn something new every video you upload. Tnx for the great content ☺️
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
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!
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......
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
Really filled in some gaps for me. Thanks for making this!
Glad it was helpful!
That Command Pattern is exactly what my game needed. Thank you!
Glad I could help!
NGL these patterns are game changer. Helps make the code more efficient and readable.
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!
Love the command pattern!! I am just about to implement a command execution architecture in my NodeJS ES6 project....I am definately gonna use this enqueue-dequeue pattern! :-D Thank you for sharing. Absolutely can implement a stateful system.
good to see a new video from you!
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!
I'm considering getting into game design. This channel is basically my education
Always appreciate your videos Jason- you create some of the best content for intermediate developers and it's always a great resource.
My pleasure!
"Beg for likes" 🤣 straight forward but you deserve likes
Squeak wheel; receive grease
Nice heads up Jason, and an awesome resource. I haven't any clue why but not having much luck with grasping C#. I get things moving and some functionality. However, I have to be misunderstanding some things. Read some stuff on .Net framework which helps understand some core working of C#. I refuse to start the copy paste method, even though technically code varies little from person to person, compared to from game to game. I don't mind making mistakes, or dealing with errors, but being stuck is a whole other matter. Over a single implemented variable, and started looking at structures to get an idea. This is a perfect stepping stone. Thanks again Jason, great advice and will keep watching.
This is an awesome video, thanks for that!
Thanks for the video, Jason. Really helpful. Keep up the good work !! Respect from India.
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!
Some quick comment about those patterns. Bear in mind that I'm no Unity programmer. Those are more general than specific to Unity. * Singleton: don't use it. Either make an object (can can have multiple instances) or use a static class. You can lazy-init elements of your static class if needed. It makes stuff way more clear and it's lighter to code than getting Instance() every time. * Observer: yes and no. It's cool in theory, but in reality you can easily lose track of who's subscribing and what they actually do. Makes cleaning up harder. It decouples the call from the context, especially in event-heavy systems (like winforms apps) where you have no idea when your functions get called in the update loop. * Command pattern: decouples the time of execution. It makes lots of sense for queues (spanning many frames) but if it's on the same frame it can generally be easily avoided. Commands can get really hard to debug, because you have no idea what was going on when calling the action, just that right now something is no longer valid. * Components: careful with too much granularity. Your core gameplay ingredients are better being concepts in themselves than soups of components, makes it much simpler to reason about in code. * Flyweight: this one is really hard to abuse. Probably the most overlooked pattern. Also forces you to consider what is a Data and what is an Instance. * State (Machine): Finite State Machines are cool for simple stuff. But sometimes you want state, but NOT a finite amount of states. Best example is a Synth: you have the waveform being played, the note, the volume, envelope.. You really don't want a discrete state for each possible combination here. Same for car physics. And it also applies to AI/behavior, where you could have different needs to balance all at once. A few broad states can make sense, but sometimes a simple enum is much more versatile than the usual state object with inherited childrens and virtuals. TL;DR: be aware of patterns, but don't abuse! A very good (and free!) book about them: gameprogrammingpatterns.com/ Also, since many of them deal with decoupling, be aware that decoupling is not always a good thing: www.joelonsoftware.com/2002/11/11/the-law-of-leaky-abstractions/
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).
Nice ☺ More in-depth videos like this, please!
You got it!
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. :)
4:54 god damn, I thought my eyes are shutting off or something. that transition was trippy :D.
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
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
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 😉
Thank so much for that video. Very interesting topic in game development
awesome as always, thanks man.
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 ! :)
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!
You made me develop at least 100 times more efficient, your explanation is always on point! Thanks for taking the time and effort to make us better at coding. Your are my coding role model :D
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 :)
Thank you for the information.
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.
You sir, deserve a medal, honestly. thank you.
Glad it helped
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!
Great video 👍👌👍 command queus and flyweight are definitely new to me !! Thanks!
Very welcome !:)
Very well executed tutorial!! Practical, with real examples! very nice channel +1 sub congratz
I was expecting a deeper dive in the component pattern, it's great that unity uses it, but I feel I often should break my game objects into smaller components to make better use of it. Great video anyway!
I actually LOVE to use the "Well, this ain't going to affect that much so I'll leave it here" design pattern.
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!
Amazing information with example, I really like your this video :)
I have actually been on that website his book is amazing!
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#
This is really helpful, thank you! I've heard of a few of these but it's always good to get more reinforcement and to see some clear examples of things being used in the context of project. Learning/Improving my coding ability through Unity projects. Hoping to be a game dev, but I know that's difficult to get into lol so hoping at least to get into software development. Would much rather learn by making games than by making Yet Another Calculator App(tm)
your content is absolutely great!
Good advice as usual. Thanks!!
Very welcome! Thanks for the comment :)
Great video! And Thanks for sharing a book
thanks! it's a great book! :)