Great video, but there seems to be a mistake in StaticInstance class On the Singleton class, there should be a return method inside the if (Instance != null) statement. Otherwise, the base.awake method is still being called, and the previously created static instance ref is overriden by the StaticInstance class's Awake method. But still, the structure is amazing. Keep it up!
@@Tarodev You should pin this comment! I definitely spent some time confused because there was no return statement and thought I was misunderstanding something. Great video though
I think one of the most important tips I received in this video was during your intro, "as you learn as a developer it will adapt and evolve to your style" I had been confusing myself trying to force other developers' styles of architecture into my projects, what I *should* be focusing on is taking advice from other devs to evolve a style that's suitable for the way that *I* think. Really enjoyed this video, learned a handful of other helpful things as well!
@@Tarodev Trust the person that spots their own errors, tells you about them, and moves to correct them. That is the person that you don't need to follow up on or worry about. That is integrity and it is far too rare and so very priceless. You're personal/UA-cam checklist is problaby much larger. Your example is a legacy that others will look up to in awe. Well done. Happy New Year to you!!
I find that SOLID principles applies to game dev so good. Some might dislike it and start thro shades at it in other industries, but in game dev its definitely needed. It just makes everything clean and helpful especially if you are working with a team. Also easier documentations for modification and balance changes as we know its popular in video games.
Great Video, I follow a very similar structure. The only real standout differences is that those "separator" style gameobjects with dashes etc, if you put them on the editor only layer they will be auto stripped from the project which cleans up the build hierarchy, and the other one is that I personally try to avoid "resource loading" style code at runtime if possible. In the case of populating a repository of units etc, if they are not going to be loaded from a remote source I have all the info I need at edit time to populate the arrays myself. So I usually write a little helper function that uses the search syntax in unity to find, load and populate an array with matching content. so for example, a context menu button that has _array = ResourceLoader.Load("t:prefab l:unit boss") which would then find all prefabs with a unit label with boss in the name, get their resource guids, resource load them and pop them into the array for me. Oh, and instead of using the _ on the scripts folder I make a generic "_project" folder that I treat as the "real" root. so it has its own data folder for scriptables, its own prefab folder etc. That being said, I subscribe to the belief that the unity project view is NOT a folder structure but an asset database and so I don't try too hard to wrangle the folder structure, but empower myself to be able to use it through targeted naming and use of labels and other search utilities. Again, great video. It's always a joy to see other people orbit some of the same patterns and practices, it means we are all coming to similar conclusions so their must be a kernel of value in them.
What great insight, Jason. I love your videos by the way! Your editing is so clean and satisfying 🤩 It is nice seeing us all reach similar conclusions. I'll be interested in what you think about my slightly off-market state machine video coming out soon.
11:06 You are violating programming principles 101. Composition should be used instead of inheritance. This has been the standard practice for 27 years. ( the gang of four book was published in 1994).
@@RealisiticEdgeMod Wholeheartedly disagree, and this is also coming from somebody who uses composition over inheritance 90% of the time. In addition, overusing composition simply to avoid inheritance is even worse than not using it at all, in my opinion. As this is a unit base and I know EVERY unit will take damage, it makes sense as a function, derived from inheritance. Over-engineering is the death of many projects, especially for new devs, which is who this video is for.
Few spoken mistakes in this video with corrected annotations. Needed to rush it out before "Merry Christmas" became too irrelevant heh. Love you guys! Enjoy.
Or you could have just erased the part where you say Merry Christmas? The only thing would be the bush stuck on your head but I think it'll be taken as modern art...
This was something I seriously needed as a self-thought developer, and there are few (maybe no other) examples of architecture out there that's in my league... Thank you very much and you've got a sub.
This is the exact tutorial I've needed. I find it so easy to come up with ideas for games and visualize what that game will end up looking like, and impossible to understand any of the structure I need to build. Every tutorial has their own structure that they follow without explaining, or they stick to very basic stuff without ever teaching you how to implement a structure. I now know what I'm missing, what I need to learn about and what I can figure out through trial and error. So instead of searching "how do I actually make the games I design", I know that I can at the very least build a structure with this in mind, tweak the structure to suit the game better if need be, and start actually making the games. It's like being a painter and never being taught how to use a canvas or a brush - sure you can throw the paint at a sheet of paper and call it art, but if you want to paint something in particular, you need to know what frame you are working within.
I've been hopping around between different Unity tutorial channels and I think I finally found my home. This video has been incredibly helpful for me, thank you.
That's probably the single most helpful video on unity I've seen. This is the things you struggle with building from blank slate and step by step. Normally you just start with something, then at some point realise you need some kind of system to do X, than try to build that , conceptualize , look up specific tutorials , fail miserably because there are just tutorials about smaller problems saying 'Oh yes at this point we will do this just like this, but it's not proper, so mind that', look up forum questions, can't read beacause $$anonymous$$ , and finally be able to do what you wanted to after working through debugging sessions. Later you will realise you need some other system and refactor because you get this unorganized abomination. This video avoids so much pain, acting like something where to look up on how to implement X base concept and organize your smaller problems. Amazing. Could be just me since I have experience with software development, just not game development. I am not overwhelmed by the code snippets themselves, I can imagine you don't really worry about these things when you don't come from software engineering. However still kind of sad to see the use of this Don't Destroy and kill new versions pattern. My dev senses are all tingly with implementing that. Doesn't seem proper at all. Was looking forward to see a solution that avoids those.
First of all, thank you, my friend! Second, for every one that is starting coding right now, or trying to, and don't know what to do, is like completly lost into what things to study and where to start, I humbly invite you to read about my short journey into software development world. Even if it's still short (about 2 years) I think this may help you. Time ago I tried to do unity games a couple times, and I did it till a certain point, then my code starts getting unreadable and I can never advance... Now I code rest api in java and live from this. There is an achitecture, of course. Every language has a lot of technics. Clean code, solid, ddd, clean architecture in general. And i didn't know this when I start coding. Even now, I'm not able to code something expandable without this. (Honestly, I think no one can) And that's something that we do not realise until we got experience and most times someone have to give you a little push and open your eyes. I was looking for something to start doing this right that time in unity. I just needed a little help, but I could not find this for free in the internet, until a couple weeks ago, with your video... And dude, works like a charm! That's exacly what I needed and I can assure all of you that THIS is the most important thing withing all languages. Even more important than code at all. Boy, no matter what you do, you need achitecture or you will get lost. Your code will break and you'r gonna have to call an alchemist, or even an exorcist to fix it for you. Of course it may vary within each language, but the *way of thinking* is the most important thing when talk about coding clean and architecture. And that is simply the best tutorial I found. For real! Generally i have to read a bit from some place, then a bit more from another and another, watch some videos and read huge books till i learn the content. But its all here, perfeclty separated for topics. I just felt compelled to set aside a little time and come here to thank you. Hope this can reach millions of people and you can keep spreading your knowloge out. I wanted to use youtube feature to give you a "Thanks", but its not available... You will get farther and farther, keep going, we jrs need you 😂❤ My best regards, Manolo Dias.
Been using Unity for about 2 weeks now and this is what i needed! Watching the video and reading through the code/assets set off so many light-bulbs in my head, I finally have a high level overview of how a simple game would flow. Thank you so much!
I'm new to Unity and making games but work in data & analytics professionally. This video has helped FAR MORE than any tutorial. I really need to understand a good workflow and architecture before diving into learning Unity itself and C#, from this video I feel I have a good base to start on a game when coupled along with a detailed game plan of what I want the end product to look like and have. Thanks so much!
Can you make a video on decision making? Like good questions to ask yourself and how to resolve them. Example: should this class be a monobehavior, a scriptable object or OG c#? Flowed by some indicators you can look for and an example / fixing a bad example
@JonontoastTo: depend on your project: yes and no the answers most definitely depend on your project however there is some good questions that overlap and guide you in the right direction. To: questions about questions, I recently had a sw project (not gamedef) myself, where I was asking myself how do I optimize this and how do I handle this being in a bad state. Which in itself where bad questions, cause by trying to resolve problems that could exist I created problems that actually existed. And I feel like this is decision making. I hope you at least partially get my point now? And thx for the detailed response ^^
The way I like to organize my folder structure is the same way it's organized in the hierarchy and prefabs. So all assets associated with player go into the player folder (scripts, graphics, audio). All assets associated with enemies go into the enemy folder. Basically, the way assets are organized in the hierarchy across all my prefabs, that's how they should be organized in the project panel in the folders. And if a script is reusable and shared, it goes into the reusable folders. The advantage of this is that in Unity you typically work on one prefab at a time. And when you work on player prefab, you want to find player related assets as fast as possible - ideally all in one place.
This is exactly what I didn't know I needed. Going into Unity without any knowledge of how game objects are organised, or how state and instatiation is managed, or how different scripts communicate with each other was a nightmare.
Happy Holidays! Pretty cool content Taro. a few things that might also help to keep in mind: 1. Not that i condone the use of singletons, but there is a better way of making your abstract Singleton class. I know Unity recommends 'Singleton : MonoBehaviour where T : MonoBehaviour', but in this case you can actually put any MonoBeaviour in place of T. Given that some coders might actually try to do this. its better to put an extra constraint do the following: 'Singleton : MonoBehaviour where T : Singleton', now you can only put T's that inherit from Singleton. 2. Instead of having that Dictionary, did you know that you can actually use ScriptableObjects as Enums, big benefits: They're Drag and Drop-able, no need to recompile if anyone wants to add another "Enum", designers can do it, no need to modify code, and you can use a generic to get the Reference too. Instead of using 'GetExampleHero(ExampleHeroType t)' you can do this 'GetExampleHero()' if you went the inheritance way, but if you are a bit more ninja, you can go the composition way, which will probably disregard the use of this system XS. 3. Try to avoid using or putting too many things in the Resources folder, everything that is in the resources folder will get loaded into memory every time you load a scene, even if those assets are never used (slow scene loading times, and big ram usage). You're already using ScriptableObjects, no need to have them there. you can make a ScriptableObject Holder that holds the references to all ScriptableObjects (a bit more work, but totally worth it). Another thing you could do is simply use Addressables, a much better way of accessing objects and assets with the benefit of not saturating your memory necessarily, and wit the big benefit that it can also work somewhat like streaming assets, if you have an update, no need to make another build, simply make a new AssetBundle and done, yes they can be downloaded/updated at runtime, they're pretty cool! Hope this helps X)
I like that you put the commment at 15:18. I recently switched to using that approach and i really like it. It makes it much easier to find the stuff you need when working on a feature, especially since the different file types all have their own icons, so if youre in a hero folder, its very easy to locate all the sounds for that hero for example
I think I would worry where to put files that could belong to more than 1 feature, but idk, never tried that way, but you can always mix and match both paradigms
After leaving a game behind for a good while, and then going back to it, I started to question my logic on the game flow big time. This video just happened to show on my recommended watch videos shortly after. Thank you for the video. You have given me some insight on ways to look at the mess of code in games.
I've been learning Unity by tutorials, and I've found it frustrating that the tutorials are so focused in getting across specifics on how to do particular things in Unity that they only pay minimal attention to architectural concerns. I get that this is not to intimidate or discourage those who aren't from a programming background, but as a programmer it makes Unity feel like it's disordered by design. This has given me ideas for how I could impose a sense of order once I break away from the tutorials and into my own projects. Thank you!
Just Finished my Game (with clean code) had been Digging into Code structure for a month now.. Finally have a good understanding.. Now you show up with THIS. ALL THOSE I LEARNED ARE IN THIS VIDEO 😓😳
IMPORTANT note for the Singleton class. It says if(Instance !=null) Destroy (gameObject); base.Awake(); this DOES NOT work as intended. Destroy does not stop code execution, the object gets destroyed at the end of the frame. Which means base.Awake(); still gets called and your instance becomes null even if you don’t want it to. Instead do if(Instance !=null){ Destroy(gameObject); return; } base.Awake(); hope this helps
This is very helpful. I'll be honest, I never thought about putting all of my managers for a scene into another object, just to make it easier to organize and manage an entire scene.
Nice, there were a few things I've been doing but some of them went completely over my head. I've heard more and more about scriptables so inevitably I'll need to dive into them. Thanks for the rundown
This is great content man. There's so much out there for the beginner it's really refreshing to see well made tutorials that cover this intermediate kind of content.
This is the video I was waiting for for long long time. I will be watching it several time in upcoming days to understand each part. Please consider making more videos like this in future. In each video you can deep dive into Managers, Setup, Enviroment, Canvases and System. I know you have videos on most of these topics already. But most of them are oriented for turn based games. Again Thanks for this video. It helped me overcome my initial barrier of game development journey.
I just got into this and I was actually wondering about this kind of thing, didn't even care to search because I thought no one would care to post. Subscribing was the right choice haha Thanks.
Nice video! Love it. One thing I'd add for the next time (Maybe?) is to create a folder for your project to avoid mixing folder with any asset store importing you have. For example, myProject folder contains all my scripts, materials, etc. While at the same level of myProject folder I can contain any imported folder from the asset store. This helps me clean a bit and organized better, since sometimes you can mix imported things with yours and that could end in a headache
tamara adviced me to watch this video and it was really answering all my questions thanks a lot sir for your efforts to simplify the game dev work by highlighting thos principale step
SO appreciate this video. Just starting out architecture and structure is hard to get started. Going to rewatch this a couple times and go through the project until it all makes sense.
Big thanks for this. Not a lot of hierarchy/file/folder structure insight videos out there. How to manage all your files and crap seems to be one of those things nobody really spotlights. I suppose because, as you yourself mention, it's a highly subjective thing. But even so, as someone new and still learning, the value of seeing how more experienced devs manage their game structure should not be underestimated.
I like to see different approaches to game architecture! Thanks for a video! One thing that I would like to make different here is to make UnitBase (or any _Base class) abstract itself so it will work more as interface but also usable in unity inspector.
This is nice. I want to see more overview of relationships and how communication happen between managers and game flow. Because of the explanation for scriptable objects being easier to pull than needing to do a long route of making the object be present first was easy to understand and gave me a good push to try learning more about SOs. An overview on UI and scalable with different display sizes and how to manage them would be nice. I only have a vague grasp on the differences between controller scripts and the possible or common managers that are in a game. Singletons are useful for communication between scripts but I've read that it can also be bad or have some drawbacks (maybe if there are a lot of them) but I don't know the reasons. Good situations or type of systems when to use a private variable would be helpful (I'm only limited to info that they are useful for debugging because private means only that script can access it so pinpointing where the weird behavior or error is easy). Also which category would object pooling fall into? (I'm referring to script since there's a built-in one now iirc).
As mentioned these types of systems can cover %90 of the gameplay, great structure sample. Also maybe you can make another video for state machine samples and addressables(instead of resources I feel like it's more convenient). Great video as usual, oh oh also I'm going to become a Tarobro now!
Great tutorial. However, this folder structure works better for small projects. As your project grows, finding your stuff becomes harder. A more scalable solution would be feature-based folder structure. For instance, a Player folder for player's stuff including texture and 3D models.
Many new developers don't pay attention to project structures or good practices and they don't realize it until it is too late and until their project is so big and gets overwhelming and hard to debug or hard to add new things or change something because everything is spread everywhere. I see some developers uses Game Manager to do almost everything game related such as handling timer, rewards, UI things .... and this lead such to a messy code at the end, it may not effect small projects but for medium games it is very important
I remember having that in my suggestions in one of the comment sections from the last videos. Thanks for making this and awesome to see a video on your project setup so quicky! Edit: There are a couple of things I do differently. Like the mentioned lazy initialization of Singletons (glad that got some coverage) which is nice because you don't have to explicitly set up objects in a first scene. Something I wanted to mention is the Units base class and an alternative way of doing it using composition. The base class approach makes unit specific logic easier to manage, provides common methods and data for inheriting units and in your game, the stats might only make sense when they are associated to an unit. Here is an alternative idea to do that uses composition: - Have an "Damageable" component or even an "IDamageable" interface that has different implementations. Damage can be dealt to any entity that has a component of this interface. - There can be a "UnitStats" component that holds the stats (if the stats are copied from the template by a manager) or a reference to the scriptable object template for the stats. - An "UnitDamageable" component implements IDamageable and accesses the UnitStats component to calculate damage. - To identify a set of objects under one type, there can be a method that gets all components of the first type, then checks if they also have the second, third etc.. But that's inefficient. If you need this identification, how about a tag component? Say there is a "TypeOfUnit" component with a RequireComponent attribute for "UnitStats" and "UnitDamageable". This would make sure that an object with that tag component also has the required components. I'm not really a fan of regular tags, since you can only have one per object and they are not type safe, since it's just a string. There are ways to make a better regular tag system though. Like having a custom component is optional but can hold multiple tags - with a custom inspector that allows only a dropdown of existing tags in the project. On tag comparison, make a regular tag comparison and if an object has that component, also check the tags stored in it. One problem remains: When the user changes the tag in the project settings mid project, which should probably be avoided. For handling tags in code I'd usually setup a static class that has pubic constants for each tag, so there is a layer of abstraction above just having inline string tags in your code.
I agree, composition is better most of the time and it's what I use in my day to day. Although I wouldn't recommend it as a beginner pattern as it involves a few extra steps and this video was primarily about getting new devs up and running with as little steps as possible. Good writeup mate!
Your work here is very valuable. Because its such a subjective topic, most forums or threads on the internet are too scared to go in-depth on their own structure (so they dismiss your request for help by saying something stupid like "its different for everyone" then not giving their solution). This works as a great baseline for hobby developers like myself but also serves as an example to experienced devs for refining their own structure.
Thank you Tarodev for the Unity Architecture for Noobs - Game Structure video, extremely helpful on my aspiration journey to game and film rendering development.
I know I'm late to the game, but I figured I'd comment anyway. Excellent video with very informative content. I really enjoyed it. One thing though... In your HeroUnitBase class, I find your inheritance troublesome, in particular for the method ExecuteMove. Considering the code in the base is extremely important for the flow of the game to continue, I would transform this method a bit. First, I would remove the virtual to make sure nobody ever overrides it. You want that code to run. However, in that method, I would call a protected abstract method, let's call it ExecuteUnitMove(). So, by making that simple change, you make sure _canMove is always set to false AFTER the actual move and all classes inheriting from HeroUnitBase MUST implement ExecuteUnitMove. And now, no need to call the base class because the base class takes care of itself. You can also apply that approach for the OnMouseDown method and, by using a state or any other logic, call Move, Attack or Dance. ;) Again, great content. My suggestion could be a bit advanced for "Noobs", but I think it provides a better approach to the given problem (the game flow) without making it overly complicated.
as a programmer its nice to see this sort of content. Ive seen loads of unity tutorials that amount to clicking a few items in a menu, this leaves me asking the question where is the code to wire it all together?
I like to keep my systems inside a static scriptable object singleton so we don't need them to not destroy on load it's just handy to keep things loaded but not in the heirchy pointlessly
Small request / consideration - This would be amazing if the code was posted to github or some easily viewable place. This would make this amazing tutorial a tad more accessible
I see there are a few people who enjoys things to be as tidy as I do. All though, I will admit I name things a bit differently and use a bit of a different hierarchy to add support for even more abstraction. This is because I enjoy writing parts of the framework into plugins which can be reused and interfaced for other projects. I feel like this might vary quite a bit also depending on the type of game genre one is making actually.
Nice video. Thanks! I believe you can actually use methods from ScriptableObjects in classes and MonoBehaviours. You just need a base ScriptableObject class with some abstract base method which will be overwritten by deriving ScriptableObject classes. That way, you can make modular systems like handling movement of units either by player control or UI, etc.
Great video. The one thing I'm not a fan is you advocating for the use of singletons for state management. At first glance it seems easy to implement and use, but as the project grows, it becomes a nightmare. I made the choice some years ago to restrict my use of singleton to the following: - I really need to get engine callbacks (start, update, etc) - I don't manage state in them (like a Gesture Daemon, it gets inputs, other objects can "listen" but not modify) Most of the time, I'm good with scriptable objects or regular C# singletons (or just static classes for that matter). I never looked back and never encountered that "ho, I need to add 15 singletons game objects to this scene if I want to test it without launching the whole game" again.
You'll notice I only use one singleton in this video, for my persistent system root. What I do use a lot are just static instances (I named it wrong originally, but I added a code annotation where I renamed it 'staticinstance'.
I love you sir, the content you have made is extremely helpful. I hope you are doing good as I do not see you posting anything new. Aa heartfelt thank you to you for your amazing contribution.
very helpful Video, I have like 30 projects that I completely abondoned becouse of how messy they became(not only in unity), over these years I developed some helpful habbits that I try to obey but still didnt find the one ideal architecture to rule them all :DD
I love your videos! This video is just what i was looking for to have a quick understanding of how to structure my games. Keep up the videos i know you are making someones life a lot easier!
I agree that putting the stats on the SO is cleaner, but you actually could get the stats from the prefab without spawning it, because you can access the prefab GO components directly just like with a spawned GO, just be careful to not modify them, otherwise you will change all objects that are later spawned with the modified prefab ;)
This gives me PTSD from my early unity days where I would change prefabs in code unintentionally (because I was a noob). I stay clear of reading data from prefab references nowdays.
Great video, but there seems to be a mistake in StaticInstance class On the Singleton class, there should be a return method inside the if (Instance != null) statement. Otherwise, the base.awake method is still being called, and the previously created static instance ref is overriden by the StaticInstance class's Awake method. But still, the structure is amazing. Keep it up!
Yup, you're 100% right. At the time I must have thought Destroy would effectively act as a return (how crazy of me).
Thanks for picking that up!
@@Tarodev You should pin this comment! I definitely spent some time confused because there was no return statement and thought I was misunderstanding something. Great video though
@@nathalieraffray306 you're right. Done!
@@Tarodev or anybody else can write the correct code please? Not sure where to put what.
thank you for mentioning this. I ran into an issue with the missing return and wasn't 100% sure where to fix it
I think one of the most important tips I received in this video was during your intro, "as you learn as a developer it will adapt and evolve to your style"
I had been confusing myself trying to force other developers' styles of architecture into my projects, what I *should* be focusing on is taking advice from other devs to evolve a style that's suitable for the way that *I* think.
Really enjoyed this video, learned a handful of other helpful things as well!
That really is the most important takeaway from the video so I'm glad that part stuck.
It's quite rare too see a tutorial on architecture, so thanks a lot for this!
Happy holidays mate!
Thank you! I upgraded my "Projects' Architecture" almost instantly from "v.0.2a to v.2.0" ;) after watching this video. Great job!
Happy to assist 🙏
Informative video - Check
Entertaining host - Check
Clearifying annotations - Check
Showing clicks & folders - Check
Just enough detail - Check
Bookmarked chapters - Check
Sample Unity package - Check
Tarodev videos - THIS IS THE WAY.
Damn! I checked all the boxes on this one.
Although:
Zoomed in code for mobile screens: Unchecked
@@Tarodev Trust the person that spots their own errors, tells you about them, and moves to correct them. That is the person that you don't need to follow up on or worry about. That is integrity and it is far too rare and so very priceless. You're personal/UA-cam checklist is problaby much larger. Your example is a legacy that others will look up to in awe. Well done. Happy New Year to you!!
@@TaAnderson-Google You're making me blush :D Have an amazing 2022 my guy! By the way, I'm premiering a video, starts in 4 mins!
I find that SOLID principles applies to game dev so good. Some might dislike it and start thro shades at it in other industries, but in game dev its definitely needed. It just makes everything clean and helpful especially if you are working with a team. Also easier documentations for modification and balance changes as we know its popular in video games.
Great Video, I follow a very similar structure. The only real standout differences is that those "separator" style gameobjects with dashes etc, if you put them on the editor only layer they will be auto stripped from the project which cleans up the build hierarchy, and the other one is that I personally try to avoid "resource loading" style code at runtime if possible. In the case of populating a repository of units etc, if they are not going to be loaded from a remote source I have all the info I need at edit time to populate the arrays myself. So I usually write a little helper function that uses the search syntax in unity to find, load and populate an array with matching content. so for example, a context menu button that has _array = ResourceLoader.Load("t:prefab l:unit boss") which would then find all prefabs with a unit label with boss in the name, get their resource guids, resource load them and pop them into the array for me.
Oh, and instead of using the _ on the scripts folder I make a generic "_project" folder that I treat as the "real" root. so it has its own data folder for scriptables, its own prefab folder etc. That being said, I subscribe to the belief that the unity project view is NOT a folder structure but an asset database and so I don't try too hard to wrangle the folder structure, but empower myself to be able to use it through targeted naming and use of labels and other search utilities.
Again, great video. It's always a joy to see other people orbit some of the same patterns and practices, it means we are all coming to similar conclusions so their must be a kernel of value in them.
What great insight, Jason. I love your videos by the way! Your editing is so clean and satisfying 🤩
It is nice seeing us all reach similar conclusions. I'll be interested in what you think about my slightly off-market state machine video coming out soon.
Jason Storey you are an inspiration!
11:06 You are violating programming principles 101. Composition should be used instead of inheritance. This has been the standard practice for 27 years. ( the gang of four book was published in 1994).
@@RealisiticEdgeMod Wholeheartedly disagree, and this is also coming from somebody who uses composition over inheritance 90% of the time. In addition, overusing composition simply to avoid inheritance is even worse than not using it at all, in my opinion. As this is a unit base and I know EVERY unit will take damage, it makes sense as a function, derived from inheritance.
Over-engineering is the death of many projects, especially for new devs, which is who this video is for.
@@Tarodev I agree that sometimes inheritance is better but in this particular instance you really should use composition.
Few spoken mistakes in this video with corrected annotations. Needed to rush it out before "Merry Christmas" became too irrelevant heh.
Love you guys! Enjoy.
Or you could have just erased the part where you say Merry Christmas? The only thing would be the bush stuck on your head but I think it'll be taken as modern art...
This was something I seriously needed as a self-thought developer, and there are few (maybe no other) examples of architecture out there that's in my league... Thank you very much and you've got a sub.
This is the exact tutorial I've needed. I find it so easy to come up with ideas for games and visualize what that game will end up looking like, and impossible to understand any of the structure I need to build. Every tutorial has their own structure that they follow without explaining, or they stick to very basic stuff without ever teaching you how to implement a structure.
I now know what I'm missing, what I need to learn about and what I can figure out through trial and error. So instead of searching "how do I actually make the games I design", I know that I can at the very least build a structure with this in mind, tweak the structure to suit the game better if need be, and start actually making the games.
It's like being a painter and never being taught how to use a canvas or a brush - sure you can throw the paint at a sheet of paper and call it art, but if you want to paint something in particular, you need to know what frame you are working within.
I've been hopping around between different Unity tutorial channels and I think I finally found my home. This video has been incredibly helpful for me, thank you.
Welcome home Greg
we need more of this kind of tutorials. great work
That's probably the single most helpful video on unity I've seen. This is the things you struggle with building from blank slate and step by step. Normally you just start with something, then at some point realise you need some kind of system to do X, than try to build that , conceptualize , look up specific tutorials , fail miserably because there are just tutorials about smaller problems saying 'Oh yes at this point we will do this just like this, but it's not proper, so mind that', look up forum questions, can't read beacause $$anonymous$$ , and finally be able to do what you wanted to after working through debugging sessions. Later you will realise you need some other system and refactor because you get this unorganized abomination. This video avoids so much pain, acting like something where to look up on how to implement X base concept and organize your smaller problems. Amazing.
Could be just me since I have experience with software development, just not game development. I am not overwhelmed by the code snippets themselves, I can imagine you don't really worry about these things when you don't come from software engineering.
However still kind of sad to see the use of this Don't Destroy and kill new versions pattern. My dev senses are all tingly with implementing that. Doesn't seem proper at all. Was looking forward to see a solution that avoids those.
First of all, thank you, my friend!
Second, for every one that is starting coding right now, or trying to, and don't know what to do, is like completly lost into what things to study and where to start, I humbly invite you to read about my short journey into software development world. Even if it's still short (about 2 years) I think this may help you.
Time ago I tried to do unity games a couple times, and I did it till a certain point, then my code starts getting unreadable and I can never advance...
Now I code rest api in java and live from this. There is an achitecture, of course. Every language has a lot of technics. Clean code, solid, ddd, clean architecture in general. And i didn't know this when I start coding.
Even now, I'm not able to code something expandable without this. (Honestly, I think no one can) And that's something that we do not realise until we got experience and most times someone have to give you a little push and open your eyes.
I was looking for something to start doing this right that time in unity. I just needed a little help, but I could not find this for free in the internet, until a couple weeks ago, with your video... And dude, works like a charm! That's exacly what I needed and I can assure all of you that THIS is the most important thing withing all languages. Even more important than code at all.
Boy, no matter what you do, you need achitecture or you will get lost. Your code will break and you'r gonna have to call an alchemist, or even an exorcist to fix it for you. Of course it may vary within each language, but the *way of thinking* is the most important thing when talk about coding clean and architecture. And that is simply the best tutorial I found. For real!
Generally i have to read a bit from some place, then a bit more from another and another, watch some videos and read huge books till i learn the content. But its all here, perfeclty separated for topics.
I just felt compelled to set aside a little time and come here to thank you. Hope this can reach millions of people and you can keep spreading your knowloge out.
I wanted to use youtube feature to give you a "Thanks", but its not available... You will get farther and farther, keep going, we jrs need you 😂❤
My best regards,
Manolo Dias.
I will need to repeat it several times, and slow it down. Very valuable info included! Worth to watch it and learn, think it over.
wow, found this on christmas of the next year, still is a great gift given im also splitting my head on my keyboard over unity confusion
Always happy to see a Unity video promoting some proper programming patterns
taro is the ultimate game dev,i hope my channel grows just a big!
Been using Unity for about 2 weeks now and this is what i needed! Watching the video and reading through the code/assets set off so many light-bulbs in my head, I finally have a high level overview of how a simple game would flow. Thank you so much!
You're welcome mate!
I'm new to Unity and making games but work in data & analytics professionally. This video has helped FAR MORE than any tutorial. I really need to understand a good workflow and architecture before diving into learning Unity itself and C#, from this video I feel I have a good base to start on a game when coupled along with a detailed game plan of what I want the end product to look like and have. Thanks so much!
Can you make a video on decision making? Like good questions to ask yourself and how to resolve them. Example: should this class be a monobehavior, a scriptable object or OG c#? Flowed by some indicators you can look for and an example / fixing a bad example
I'd really like this cause I feel like i know a lot of concepts but use them in the wrong situation :)
Another good question: should I even ask this question on this project? Indicators: size, complexity
Yes! I really need this too! Roughly understand what everything does but still really hard to grasp the what the purpose of each one is.
@JonontoastTo: depend on your project: yes and no the answers most definitely depend on your project however there is some good questions that overlap and guide you in the right direction. To: questions about questions, I recently had a sw project (not gamedef) myself, where I was asking myself how do I optimize this and how do I handle this being in a bad state. Which in itself where bad questions, cause by trying to resolve problems that could exist I created problems that actually existed. And I feel like this is decision making. I hope you at least partially get my point now?
And thx for the detailed response ^^
Use scriptable object whenever possible. it makes your project easy to manage, debug and test.
The way I like to organize my folder structure is the same way it's organized in the hierarchy and prefabs. So all assets associated with player go into the player folder (scripts, graphics, audio). All assets associated with enemies go into the enemy folder. Basically, the way assets are organized in the hierarchy across all my prefabs, that's how they should be organized in the project panel in the folders. And if a script is reusable and shared, it goes into the reusable folders.
The advantage of this is that in Unity you typically work on one prefab at a time. And when you work on player prefab, you want to find player related assets as fast as possible - ideally all in one place.
Your the first content creator, teacher who responds and adjusts to your communities comments. :D Thanks friend!
This is exactly what I didn't know I needed. Going into Unity without any knowledge of how game objects are organised, or how state and instatiation is managed, or how different scripts communicate with each other was a nightmare.
Happy Holidays! Pretty cool content Taro. a few things that might also help to keep in mind:
1. Not that i condone the use of singletons, but there is a better way of making your abstract Singleton class.
I know Unity recommends 'Singleton : MonoBehaviour where T : MonoBehaviour', but in this case you can actually put any MonoBeaviour in place of T. Given that some coders might actually try to do this. its better to put an extra constraint do the following: 'Singleton : MonoBehaviour where T : Singleton', now you can only put T's that inherit from Singleton.
2. Instead of having that Dictionary, did you know that you can actually use ScriptableObjects as Enums, big benefits: They're Drag and Drop-able, no need to recompile if anyone wants to add another "Enum", designers can do it, no need to modify code, and you can use a generic to get the Reference too.
Instead of using 'GetExampleHero(ExampleHeroType t)' you can do this 'GetExampleHero()' if you went the inheritance way, but if you are a bit more ninja, you can go the composition way, which will probably disregard the use of this system XS.
3. Try to avoid using or putting too many things in the Resources folder, everything that is in the resources folder will get loaded into memory every time you load a scene, even if those assets are never used (slow scene loading times, and big ram usage).
You're already using ScriptableObjects, no need to have them there. you can make a ScriptableObject Holder that holds the references to all ScriptableObjects (a bit more work, but totally worth it).
Another thing you could do is simply use Addressables, a much better way of accessing objects and assets with the benefit of not saturating your memory necessarily, and wit the big benefit that it can also work somewhat like streaming assets, if you have an update, no need to make another build, simply make a new AssetBundle and done, yes they can be downloaded/updated at runtime, they're pretty cool!
Hope this helps X)
Great writeup, Willy :)
I like that you put the commment at 15:18. I recently switched to using that approach and i really like it. It makes it much easier to find the stuff you need when working on a feature, especially since the different file types all have their own icons, so if youre in a hero folder, its very easy to locate all the sounds for that hero for example
I think I would worry where to put files that could belong to more than 1 feature, but idk, never tried that way, but you can always mix and match both paradigms
After leaving a game behind for a good while, and then going back to it, I started to question my logic on the game flow big time. This video just happened to show on my recommended watch videos shortly after. Thank you for the video. You have given me some insight on ways to look at the mess of code in games.
Wow. Busts out ALL the awesome tricks it took years for me to learn and a few new ones! Amazing, mate.
I've been learning Unity by tutorials, and I've found it frustrating that the tutorials are so focused in getting across specifics on how to do particular things in Unity that they only pay minimal attention to architectural concerns. I get that this is not to intimidate or discourage those who aren't from a programming background, but as a programmer it makes Unity feel like it's disordered by design. This has given me ideas for how I could impose a sense of order once I break away from the tutorials and into my own projects. Thank you!
Just Finished my Game (with clean code) had been Digging into Code structure for a month now.. Finally have a good understanding.. Now you show up with THIS. ALL THOSE I LEARNED ARE IN THIS VIDEO 😓😳
Ah... I wish I could have released this earlier for you 😜
IMPORTANT note for the Singleton class. It says if(Instance !=null) Destroy (gameObject); base.Awake(); this DOES NOT work as intended. Destroy does not stop code execution, the object gets destroyed at the end of the frame. Which means base.Awake(); still gets called and your instance becomes null even if you don’t want it to. Instead do if(Instance !=null){ Destroy(gameObject); return; } base.Awake(); hope this helps
This is very helpful. I'll be honest, I never thought about putting all of my managers for a scene into another object, just to make it easier to organize and manage an entire scene.
It's the little things 😉
Your Unity tutorials are excellent. As a DotNet developer trying to learn Unity I really appreciate how you explain things
Nice, there were a few things I've been doing but some of them went completely over my head. I've heard more and more about scriptables so inevitably I'll need to dive into them. Thanks for the rundown
This is great content man. There's so much out there for the beginner it's really refreshing to see well made tutorials that cover this intermediate kind of content.
Thanks mate! I'll have some more intermediate to advanced stuff coming shortly!
really felt when he said 5:19
heart touching
This is the video I was waiting for for long long time. I will be watching it several time in upcoming days to understand each part.
Please consider making more videos like this in future. In each video you can deep dive into Managers, Setup, Enviroment, Canvases and System.
I know you have videos on most of these topics already. But most of them are oriented for turn based games.
Again Thanks for this video. It helped me overcome my initial barrier of game development journey.
Wow, really good video. Most of the videos on UA-cam doesn't care about those details you mentioned. Subscribed.
Man you make me want to start my whole base project all over again and be neater this way. Its efficient
Big decision. A re-write always feels nice
I just got into this and I was actually wondering about this kind of thing, didn't even care to search because I thought no one would care to post.
Subscribing was the right choice haha
Thanks.
Great video thank you so much. This is gonna solve a lot of issues i have with my games.
Nice video! Love it.
One thing I'd add for the next time (Maybe?) is to create a folder for your project to avoid mixing folder with any asset store importing you have.
For example, myProject folder contains all my scripts, materials, etc. While at the same level of myProject folder I can contain any imported folder from the asset store.
This helps me clean a bit and organized better, since sometimes you can mix imported things with yours and that could end in a headache
Plus, doing this allows you to easily add assembly references!
Found you a couple of days ago. The educational content is very much appreciated, Ser!
Brilliant idea putting all our DontDestroyOnLoad objects under one parent object!
tamara adviced me to watch this video and it was really answering all my questions thanks a lot sir for your efforts to simplify the game dev work by highlighting thos principale step
SO appreciate this video. Just starting out architecture and structure is hard to get started. Going to rewatch this a couple times and go through the project until it all makes sense.
Glad it could help you on your way :)
Big thanks for this. Not a lot of hierarchy/file/folder structure insight videos out there. How to manage all your files and crap seems to be one of those things nobody really spotlights. I suppose because, as you yourself mention, it's a highly subjective thing. But even so, as someone new and still learning, the value of seeing how more experienced devs manage their game structure should not be underestimated.
Glad you found it helpful Sean :)
I like to see different approaches to game architecture! Thanks for a video! One thing that I would like to make different here is to make UnitBase (or any _Base class) abstract itself so it will work more as interface but also usable in unity inspector.
Loved the video, these types of videos are very rare, as an experienced programmer, this was very helpful for me.
This is nice. I want to see more overview of relationships and how communication happen between managers and game flow. Because of the explanation for scriptable objects being easier to pull than needing to do a long route of making the object be present first was easy to understand and gave me a good push to try learning more about SOs. An overview on UI and scalable with different display sizes and how to manage them would be nice. I only have a vague grasp on the differences between controller scripts and the possible or common managers that are in a game. Singletons are useful for communication between scripts but I've read that it can also be bad or have some drawbacks (maybe if there are a lot of them) but I don't know the reasons. Good situations or type of systems when to use a private variable would be helpful (I'm only limited to info that they are useful for debugging because private means only that script can access it so pinpointing where the weird behavior or error is easy). Also which category would object pooling fall into? (I'm referring to script since there's a built-in one now iirc).
As mentioned these types of systems can cover %90 of the gameplay, great structure sample. Also maybe you can make another video for state machine samples and addressables(instead of resources I feel like it's more convenient). Great video as usual, oh oh also I'm going to become a Tarobro now!
Thank you so much for your support man!
Exactly what I was looking for for weeks! Thank you!
Great tutorial. However, this folder structure works better for small projects. As your project grows, finding your stuff becomes harder. A more scalable solution would be feature-based folder structure. For instance, a Player folder for player's stuff including texture and 3D models.
I had an annotation at the end describing this folder structure :)
Many new developers don't pay attention to project structures or good practices and they don't realize it until it is too late and until their project is so big and gets overwhelming and hard to debug or hard to add new things or change something because everything is spread everywhere. I see some developers uses Game Manager to do almost everything game related such as handling timer, rewards, UI things .... and this lead such to a messy code at the end, it may not effect small projects but for medium games it is very important
This channel is really a gold mine for anyone learning Unity. It answer many questions on the back of my mind when learning this Engine :o
I remember having that in my suggestions in one of the comment sections from the last videos. Thanks for making this and awesome to see a video on your project setup so quicky!
Edit: There are a couple of things I do differently. Like the mentioned lazy initialization of Singletons (glad that got some coverage) which is nice because you don't have to explicitly set up objects in a first scene.
Something I wanted to mention is the Units base class and an alternative way of doing it using composition. The base class approach makes unit specific logic easier to manage, provides common methods and data for inheriting units and in your game, the stats might only make sense when they are associated to an unit.
Here is an alternative idea to do that uses composition:
- Have an "Damageable" component or even an "IDamageable" interface that has different implementations. Damage can be dealt to any entity that has a component of this interface.
- There can be a "UnitStats" component that holds the stats (if the stats are copied from the template by a manager) or a reference to the scriptable object template for the stats.
- An "UnitDamageable" component implements IDamageable and accesses the UnitStats component to calculate damage.
- To identify a set of objects under one type, there can be a method that gets all components of the first type, then checks if they also have the second, third etc.. But that's inefficient.
If you need this identification, how about a tag component? Say there is a "TypeOfUnit" component with a RequireComponent attribute for "UnitStats" and "UnitDamageable". This would make sure that an object with that tag component also has the required components.
I'm not really a fan of regular tags, since you can only have one per object and they are not type safe, since it's just a string.
There are ways to make a better regular tag system though. Like having a custom component is optional but can hold multiple tags - with a custom inspector that allows only a dropdown of existing tags in the project. On tag comparison, make a regular tag comparison and if an object has that component, also check the tags stored in it.
One problem remains: When the user changes the tag in the project settings mid project, which should probably be avoided.
For handling tags in code I'd usually setup a static class that has pubic constants for each tag, so there is a layer of abstraction above just having inline string tags in your code.
I agree, composition is better most of the time and it's what I use in my day to day. Although I wouldn't recommend it as a beginner pattern as it involves a few extra steps and this video was primarily about getting new devs up and running with as little steps as possible.
Good writeup mate!
@@Tarodev Thank you! Yeah, for conveying the ideas you shown, this is not really necessary of course.
Your work here is very valuable. Because its such a subjective topic, most forums or threads on the internet are too scared to go in-depth on their own structure (so they dismiss your request for help by saying something stupid like "its different for everyone" then not giving their solution). This works as a great baseline for hobby developers like myself but also serves as an example to experienced devs for refining their own structure.
Thanks for great video! I go back and forth to it for a few days while learning how to organize game better!
Thank you Tarodev for the Unity Architecture for Noobs - Game Structure video, extremely helpful on my aspiration journey to game and film rendering development.
I know I'm late to the game, but I figured I'd comment anyway. Excellent video with very informative content. I really enjoyed it.
One thing though... In your HeroUnitBase class, I find your inheritance troublesome, in particular for the method ExecuteMove. Considering the code in the base is extremely important for the flow of the game to continue, I would transform this method a bit. First, I would remove the virtual to make sure nobody ever overrides it. You want that code to run. However, in that method, I would call a protected abstract method, let's call it ExecuteUnitMove(). So, by making that simple change, you make sure _canMove is always set to false AFTER the actual move and all classes inheriting from HeroUnitBase MUST implement ExecuteUnitMove. And now, no need to call the base class because the base class takes care of itself. You can also apply that approach for the OnMouseDown method and, by using a state or any other logic, call Move, Attack or Dance. ;)
Again, great content. My suggestion could be a bit advanced for "Noobs", but I think it provides a better approach to the given problem (the game flow) without making it overly complicated.
I put numbers to the Project Folder names, this way I can make a sorting order for those folders.
Great tip!
0:00 ""Merry Christmas"
A simple spell but quite unbreakable
Ever been wished merry Christmas so aggressively before?
@@Tarodev First time for me lol! Merry Christmas to you to0 and thanks for the dope video!
Very informative, learned some very interesting techniques. Thank you!
I love everything about this video. Subbed for the head tree and intro statement alone 😉👍🏽
Welcome aboard ❤️ 🎄
Just what i'm looking for, omg thank god i have you 😍😍😍
I learn something with every video, even with the beginner stuff, thank you!
If I had a wish for a new year, that would be a tutorial like this one. Thanks.
Now you can choose a new wish 😉
@@Tarodev it would be awesome if you did a video on assemblies
@@SystemOfATool Good idea. Also, awesome name
@@Tarodev Thanks bro, i love your channel. Please continue making videos on advanced unity/c# stuff
This is good advice for new game devs, can recommend 👍
Looking festive af bro! Thanks for the Architecture advice. The neater it is, the sweeter it is
Wow. This is exactly what I wanted. Thank you for this. 🎄🍾🎉
as a programmer its nice to see this sort of content. Ive seen loads of unity tutorials that amount to clicking a few items in a menu, this leaves me asking the question where is the code to wire it all together?
Here it is baby
I like to keep my systems inside a static scriptable object singleton
so we don't need them to not destroy on load
it's just handy to keep things loaded but not in the heirchy pointlessly
6 minutes to the video I finally noticed that funny christmas decoration
heh 😂
Good timing, I'm going to restructure my current project in January, so some input was very welcome 😊👍
Good luck with that! It's always a big task restructuring mid way through 🙏
@@Tarodev yeah, that's why I'm not already on it and have to finish the MVP beforehand -_-
Excellence! Can’t wait to try this out.
Would be great to see the best method to integrate the new input controller system with this
Great video as always and posted right when I needed it the most :) Taro is like Gandalf for Unity.
I should install more cameras
Small request / consideration - This would be amazing if the code was posted to github or some easily viewable place.
This would make this amazing tutorial a tad more accessible
Rather than putting your system prefab in every scene, you can use a single additive scene (in some cases).
This is a great resource - I've made so many notes on my to-do list to try these out. Especially the dictionary of scriptable objects - good stuff!
Glad I could help. Also, thanks for the support!
I see there are a few people who enjoys things to be as tidy as I do.
All though, I will admit I name things a bit differently and use a bit of a different hierarchy to add support for even more abstraction.
This is because I enjoy writing parts of the framework into plugins which can be reused and interfaced for other projects.
I feel like this might vary quite a bit also depending on the type of game genre one is making actually.
This is so interesting and good to know! Thank you for this!
Thankyou so much I've really been looking for something like this :)
You're welcome 😊
Very interesting. Thank you for sharing your structure.
Great video. I found this really useful as a beginner to unity. Thanks Tarodev :)
Wow thanks. Been looking for a vid like this for years
Nice video. Thanks!
I believe you can actually use methods from ScriptableObjects in classes and MonoBehaviours. You just need a base ScriptableObject class with some abstract base method which will be overwritten by deriving ScriptableObject classes. That way, you can make modular systems like handling movement of units either by player control or UI, etc.
More of this Great video! I saved it in my playlist for later! have a good holiday!
This was great, thank you. Would love to see a deeper dive into configuring that generic singleton class.
Cool! Thank you and Happy New Year!
Thanks for sharing this tips. Really helpful to me.
Great video. The one thing I'm not a fan is you advocating for the use of singletons for state management. At first glance it seems easy to implement and use, but as the project grows, it becomes a nightmare. I made the choice some years ago to restrict my use of singleton to the following:
- I really need to get engine callbacks (start, update, etc)
- I don't manage state in them (like a Gesture Daemon, it gets inputs, other objects can "listen" but not modify)
Most of the time, I'm good with scriptable objects or regular C# singletons (or just static classes for that matter). I never looked back and never encountered that "ho, I need to add 15 singletons game objects to this scene if I want to test it without launching the whole game" again.
You'll notice I only use one singleton in this video, for my persistent system root.
What I do use a lot are just static instances (I named it wrong originally, but I added a code annotation where I renamed it 'staticinstance'.
I love you sir, the content you have made is extremely helpful. I hope you are doing good as I do not see you posting anything new. Aa heartfelt thank you to you for your amazing contribution.
@@bishalshrestha722 glad I could help you ❤️
very helpful Video, I have like 30 projects that I completely abondoned becouse of how messy they became(not only in unity), over these years I developed some helpful habbits that I try to obey but still didnt find the one ideal architecture to rule them all :DD
Such great suggestions, thank you :)!
I love your videos! This video is just what i was looking for to have a quick understanding of how to structure my games. Keep up the videos i know you are making someones life a lot easier!
I agree that putting the stats on the SO is cleaner, but you actually could get the stats from the prefab without spawning it, because you can access the prefab GO components directly just like with a spawned GO, just be careful to not modify them, otherwise you will change all objects that are later spawned with the modified prefab ;)
This gives me PTSD from my early unity days where I would change prefabs in code unintentionally (because I was a noob). I stay clear of reading data from prefab references nowdays.
This was amazing ! thanks so much
Love this, thank you very much!!
You have the best Xmas hat i've even seen