Taro, I just wanted to say thank you for making these tutorials, which are very valuable, are worth a lot to us, and I know take a lot of planning and effort on your part! Also, I wanted to tell you that you did an excellent job of explaining what you are thinking, and helping us to understand what you're doing in the code. I actually sat in front of the code at around 3:45, and I noticed that I understand the stuff you're writing a lot better than I think I understood tutorial code in other tutorials I have watched. So thank you! I hope you are very successful, and that the things in your life turn out to be much better than you thought they would. Thanks Taro,
I also want to say thank you, I enjoyed watching demo game, your explanation and also quality of your code. It was an enjoyable video from start to finish.
how would you implement an "initiative" stat for each player and enemy? so instead of always repeating 1) the player then 2) the enemy, you would have the player and enemy "roll" a die and the highest roll would go first for that round.
I've come to this video for no less than 4x already, trying to fully comprehend your video (even downloaded it to free myself from the limits of my interenet connectivity). It looks really really easy, maybe because you have explained it well. Great video!
Man I love you! I cannot thank you enough, I had my turn based game using if statements in the update method and using bools to check if the players took their turn and overcomplicating the code. Using states simplified things for me a lot, and my code runs only when the state changes instead of all the time checking if something changed.
Got into a jam (just knowing py(REALLY BAD IDEA)), all my team knows and use unity, so here i am almost 3 am learning C#, somehow after 3-4hrs accomplish to understand almost everything, also ur video is one of the best videos i have seen about this topic, congrats :)
"This is not the best way to do it..", "that is not good design.." ... ".. but for the sake of the tutorial".. The idea is clear already after the first event handling, it would be great to see how every part of the code in the gameManager you write is THE GOOD WAY to do
I would really like to see more tuts about managers and controllers and their corellation, since i'm going trough a C# cookbook for Unity and it is helping me to grasp about game architecture and Unity and C# in general. Btw, thanks, this stuff is awsome.
Why did you call functions like color select outside the manager using OnGameStateChanged, but then calling functions like HandleEnemyTurn() within the manager? I mean, the HandleColorSelection function is empty but its logic handled in another class?
Ohhh I have always avoided naming it "GameManager" cause I thought that unity put the cog there cause unity already has some script named "GameManager" and I was about to override it.
The video generates more questions than answers. The overall presentation is nothing to complain about and quite good except for the banging sound on your keyboard.
Hey man, this was hugely beneficial for me, thank you. If you don't mind me asking, do you recommend any additional resources (books, videos, etc) on the fundamentals of game development? I've been diving into learning Unity, but this made me realize I'm probably suffering from some serious blindspots in terms of the absolute basics of game design.
I unfortunately cannot recommend anything. I've always been an in-the-moment learner. By that, I mean looking things up as I need them, as opposed to any kind of structured learning experience. It's not for everybody, though... Most people learn better with a bit of structure.
Great video! I've recently stumbled upon your content while on my Scripting Unity journey. Quickly I'm becoming obsessed with Architecture and managing the flow of the Game and Logic. This and many of your videos are great reference!
Could you explain your thinking behind naming your events? I don't quite understand the conventions. I kind of get the OnGameStateChanged name but what's the reasoning behind GameManagerOnOnGameStateChanged?
at 5:50 what is the difference in using OnEnable and On Disable methods to subscribe and unsubscribe the event? this only way ive done it and ive not used OnDestroy?
The main difference is that onawake/ondestroy is for the object lifecycle, vs onenable/disable can be called if the behaviour is enabled/disabled. Both will be done when object is started/destroyed. This explains it docs.unity3d.com/Manual/ExecutionOrder.html
Thanks for awesome tutorial. I personally found having final state machine to change game states easier to manage. All change conditions are in one place. Of course avoiding singleton is not easy but I found it worth in long run. The fact that you do not have access to trigger game level events from any place you wish, forces you to use controlers' events to get informed and then change states. Which in turn decouples the code. But I am still searching for even better way to do it...
Could you be more precise about what you expect ScriptableObject to do in "this sort of thing"? I do understand that you can plug SO in a state machine, but I'm not sure why you'd want that here, except maybe to subdivide your code, but you don't exactly need SO for that. Only way I can see this is create an abstract SO to inherit from and override "StateEntry", "StateRun", "StateExit" functions. Use some static variable that most of your states need to regularly inspect (reference to stat controllers, player controller, or something). Other than that, have state dependant variables public that you wanna set in the inspector, which is the only reason I see SO used in "this sort of thing", or maybe for difficulty settings then you'd swap "CombatState_Normal" with "CombatState_Easy" or "CombatState_Hard". In the GameManager, have UpdateGameState(newState) call on current state StateExit and new state StateEntry. If current and new state are same, call StateRun.
@@Kalahee Thanks for the reply. I was just starting to dig into ScriptableObjects and it just seemed like something they'd be suitable for. But honestly, it was so long ago I can't remember specifically why I asked that :)
Question: Aren't we supposed to avoid using singletons? According to others, you can go without using them, and there are better options, but I don't know which ones. I don't know what to avoid using singletons for, either. What do?
People love to hate singletons. It's the cool thing to do in the unity world. You can ask those people for a personal example they have come across where singletons were bad, but they won't be able to give you one. The main concern is that it can become messy in a large project, but I've created large projects and they are entirely manageable. I also use SO-Architecture, which is generally what people replace singletons with. I love it, but would say it gets equally messy on large projects. Singletons are 100% fine and are the quickest way to implement game-wide code access. Until you come across a major problem with them personally, don't listen to the deniers.
@@Tarodev i see, I've been trying to learn this today and it takes a while to fully understand how it all works and how to implement it the best way. But I'm glad you responded, and I'm glad i found your channel, it's great for learning about stuff i never find anywhere else. Thank you darling 💞
Thank you so much for this video!:) I was able to follow until 5:30 than I got Error CS0246:The type or namespace name 'GameState' could not be found (are you missing a using directive or an assembly reference?) from Unity. Do you have any tip for me how to tell the MenuManager what a GameState is?
I still don't get how gameobjects can speak to other object codes. There are built in methods like oncollision and stuff that wait for events and return data, but i dont get how i can communicate between game objects and share information.
It’s better to have states as individual objects of a state class. This is so you can have the state objects handle logic that’s only relevant to them, meaning your code is much easier to expand, bug fix and read. If you don’t know what I’m talking about or mean, google search OOP C#.
You are talking about the State pattern. He said in another video that handling states with a switch is good for 90% of indie games. But state pattern is not harder then this version in my opinion. I wish Unity had some native built in tools for making states.
Just so when referencing the enum outside of the Game Manager class we don't have to do GameManager.GameState.State, we can just do GameState.State. No other reason 😊
This method means when the scene is transitioned away from, this game manager will remain idle, in memory. Once a new game scene is spawned, a new game manager will override the last one. This means we don't need to write any reset logic 😊
I noticed you used Awake() and OnDestroy() to subscribe and unsubscribe events. Most other tutorials I've seen on the subject use OnEnable() and OnDisable() for this. Is this just a matter of preference, or is there a reason to use one function over another?
Unless your object is being enabled and disabled dynamically it doesn't matter in the slightest as it'll do the same thing. If you don't have enable/disable logic I'd say use Awake/Destroy as they're the first very and last lifecycle events to be called.
It looks like ChangeState is being called recursively so that the OnGameStateChanged?.Invoke() commands will run in the opposite order. Wouldn't this cause some issues?
When you subscribe/unsubscribe to the event would it be better to use onEnable/onDisble? Saw it in some other video, and was wondering if which of the methods would be best practice?
Hello nice tutorial. I have a question though. I want to make: when I press the button the attack function will be executed the turn after the button has been pressed. So if I press button on turn 1, the function will be called on turn 2. Is it possible? Hpw can we store the turn integer? with an enum?
Forgive a possibly stupid question, but in a turn based game across different devices, are the states framed purely within the perspective of the device of the player in question (e.g. Your Turn, Wait, Your Turn, Wait, Win/Lose) or would it consider both players (e.g. Your Turn, their Turn, Your Turn, Their Turn, Win/Loss). My assumption is the first based simply on the fact that one device would see a Win screen and the other a Loss screen, so for this along they'd be "blind" to each other, other than updating the gameboard status after the other player has made their move.
If you work with a team including designers, look into decoupled architecture. If you're working solo or with one other, singletons will simplify your code and speed your development. Don't listen to people who say they're bad 100% of the time. Everything has its place
How would I check the current state during the update method? I understand that the GameManagerOnGameStateChanged function only triggers when the state is changed, there are other functions I'd like to trigger during update only if the state is the correct one.
Excellent tutorial, thankyou. Can I get the source to the Unit.cs mentioned which uses Factions? Is it available via your Tarobro membership? I'd also appreciate a tutorial on Unity Factions.
This is a design decision I've gone either way with. In most cases I'd say no. It comes down to a lot of things like if you're setting your time scale to 0, if it's going to be difficult to re-trigger the unpaused state without causing double up, etc.
how would you implement an "initiative" stat for each player and enemy? so instead of always repeating 1) the player then 2) the enemy, you would have the player and enemy "roll" a die and the highest roll would go first for that round.
(Sorry ahead of time for the long comment and lots of questions, I segmented them out with numbers highlighting key areas) I'm learning about GameManagers right now and this seems like a really useful tutorial, thanks! But, just out of curiosity, (1) what would the implications be to handle all of these features yourself, using things like variables/properties inside of a GameManager proxy script? For example, setting a public property or field string as the state name, inside of your GameManager proxy script, to "BetweenRounds", then your game objects/scripts check whether or not the state of that public property/field is "BetweenRounds" before doing the performing that code? The reason I ask is I'm much more familiar with that sort of workflow, and if that's something I can do, and it's not unreasonably impactful on the performance, then, (2) is that an acceptable solution? If it's not, and there does happen to be a downfall or disadvantage, then I would have to put my laziness aside and do it properly. Another reason I ask is, the concept of a GameManager seems like a no-brainer when handling multiple elements, but when I looked into it online, I find all sorts of conflicting information, some regarding why Singletons are bad to use in Unity, some how Singletons are good to use in Unity; And one specifically, a Unity help article from 2017 stating how the GameManager workflow is "Incredibly out-of-date", linking to another article that seems to suggest you should use a preload scene instead, somehow. Although, admittedly I didn't read through it in entirety yet, I've attached it below if you're curious: answers.unity.com/questions/1124691/creating-a-proper-game-manager.html ((3) It would be nice to hear what your opinion is on that, because if I try to implement an out-of-date workflow then I might end up running into incompatibilities with future features, or dropped support of that workflow)
I read the post you linked regarding a prescene and I think you may be a bit confused, probably due to naming. So when he's talking about game manager, he's more referring to a full system wide management solution, including sound, scenes etc etc. This video is a manager to control the flow of the actual game and has no overlap to his guide. You would absolutely not want to put this on an object which persists through every scene including menus and the like, you'd want a brand new instance of it each new game. Singletons are very handy and are used widely not just in unity but across all of c# development. Even though his post has no overlap with my video, I'd still like to put my two cents in: Firstly, I hated how he wrote it in such a factual way when it is in fact subjective. Saying that, a single DontDestroyOnLoad created in a _prescene could be beneficial for readability, but honestly doesn't make too much of an impact. The fact he didn't actually make static instances of the systems classes but instead expected the dev to find them by searching the scenes and then setting individual references in every class which needed them shows me somebody told him statics/singletons are bad so he's just avoided them for the sake of doing so. In the end programming has many conventions, but as long as an implementation isn't detrimental to performance or readability, you should follow the design pattern you or your team enjoys.
@@Tarodev Thank you very much for your response! I just found you tonight looking for information on game managers, and I also asked a few devs in a discord group, so I got some more advice, it's all helpful. And, I'm glad I found your channel, severely underrated, you have a ton of content that I can already tell is going to be useful in my process, keep up the great work!
They can both exist at the same time just that with the event system you can avoid having static game manager at all since you could just not access it directly but still you'd have a place for your game state
Great tutorial! It connected many concepts I’ve seen in the past and made it clearer. Question about the implementation of the enemy turn. You use task.delay saying it is not great implementation. Could you explain more? Would you use Coroutines instead in a real world context? Thanks again
By game loop do you mean void Update? If so, no at all. If by game loop you mean a place to manage the flow of the game, for example initial setup, player turn, enemy turn, deciding if the game is won/lost, than yes. Think of GameManager as an orchestrator. It's the only place to further the game to the next step. (by game I mean actual gameplay, not main menu, splash screen etc).
Can we subscribe lambda function to the event and then unsubscribe that lambda. SomeEvent += () => print("Something"); SomeEvent -= () => print("Something"); is this possible?
I was interested in this (had heard about this approach, but never implemented it myself), but when you made the UnitManager change the state of the game, it gave me pause. Is there a relatively simple way to avoid this? I'm think events or something like that. So the actual state changing happens inside the GameManager, and it just listens things happening in the game before changing. It starts getting really close to a state machine by then, but still. Opinions?
Just depends how decoupled you'd like to make it. Don't just decouple for the sake of it, do it when you feel it's needed. For example if you think the project will chop and change a lot, or if you think you'll ever need each individual part by itself (for testing, or different scenes). Decoupling has many benefits, but it also makes it harder to keep track of what's happening. My main rule: keep it simple unless required otherwise.
Hey Tarodev, I wanted to thank you for this video! I’m using this to write out the skeleton for an online turn-based combat game I’m building with PlayFab and Photon. I was curious, what UI asset are you using? I love the colors and the font style! So good for prototyping!
I agree, for large projects. But a small one? Use the quickest tool for the job which is undoubtably singletons and enum based game managers. Saying that, I have used both of those things in decently sized projects (albeit, as a solo dev) and they've been fine
@@Tarodev For the sake of the tutorial it might be the case but I did not expect to see a static GameManager in the video called "Game Manager - Controlling the flow of your game [Unity Tutorial]" since it is definitely not the best practice. Long story short, it destroys OOP concepts completely, GameManager stops being an "entry point" and it is hard to control on a larger scale since everybody calls it from everywhere. Besides that in our production we avoid using UnityEvents. I understand it was made for the sake of simplicity as well (just drag and drop) and it might be useful if designers tweak them (which never happened to me in real projects). In any case, I love your channel and there is a lot I have learned from you.
in ruclips.net/video/4I0vonyqMi8/видео.html there is apparently a shortcut to implement a new function, when you write it, and its not existing yet, can you tell me how you did it?
Hey, I've been watching a lot of your tutorials these last few days and I find your content entertaining and to the point. I do have some questions concerning this video. You say you keep the complexity low and easy to adapt, yet you need to enter and edit each leaf node in your game flow to change the way the logic plays out. Also, each leaf node needs to know about the existence and implementation of the game manager. Is this something only suitable for prototyping or how would you scale this up? How would you handle your UnitManager and your team color select screen when more options become available or required? Seeing this system handle change (as you demonstrated with the decide state) can really sell its benefits or show its downsides. I would really appreciate your input on these matters as it is something I spend lots of time thinking about myself.
Although people tell you left and right that coupling your components is bad, it really isn't. Yes, maybe on a AAA game with lots of people working on it, but as a very small team working on a small to medium sized game it's not a big deal. If you do want to decouple a but more and organise your states with a bit more control, look into a statemanager. I personally avoid them unless absolutely nessersary. It really comes down to personal preference, but I tend to use the easiest and quickest option if there are no major reasons not to.
@@Tarodev Thanks a ton for your reply. I always get the shivers when I have to tightly couple things. I have a junior coder that I do not want to influence in a bad wat. It might just be specific to my company's way of working, with customers and project leads changing their minds a lot all the while I'm trying to maintain a certain consistency within the several applications we are working on and maintaining. I appreciate the added nuance of your reply, it makes it easier to frame the video within its correct context.
@Sander Decleer Do yourself a favour and forget everything youve seen in this video. If you have a gamemanager that keeps track of game state then you need an event system to communicate between objects. So thats A LOT more code than just calling methods on classes. The information you pass between the objects must either be stored in each object until the next Update call (so every object that needs to know some information needs to store its own internal copy of it instead of just calling a method on the class and requesting the information) OR you need to store all information passed between objects in the gamemanager as part of the game state. So now you effectively have one giant class containing all these GLOBAL variables.
@@RealisiticEdgeMod I'm assuming you over-engineer everything. For small to medium games, this pattern is just fine. In fact most shipped games would be using this pattern. To say ignore it entirely just because there is a more complex and scalable solution is silly. Use the quickest and most efficient tool for the job at hand.
@@RealisiticEdgeMod Thanks for your reply. I see the advantage of totally decoupling everything and using a message system once you application grows larger. For a smaller system or subsystem I believe readability and ease of seeing all moving parts in a sequential fashion has its merits. So there direct message calls could be an option. The thing I disagreed most with in this video would be that the state change is controlled by the simpler classes, thus making them dependent on the implementation of the gamemanager. The core application logic should be contained there, and other objects should only expose events or another way for the game manager to determine what happened and act accordingly. Event systems are one option for that. Excuse the rant, I appreciate your time and insight.
Sad - seems to be such a usefull tutorial.. Also for Begginers like me .. !!! But its an example on a "prefixed Game" that never showed how it works - so that makes it MUCH more complicated for me to understand :( Although Thanx for the Tutorial
I see what you're saying and I could have done a little more to simplify it. But the video was not about the game (what you see in the video is the whole game, I made it for this video). Every time I make a tutorial I have to decide if I want to make it visually pleasing and fun to watch or drop-dead boring with no context. I'll keep this in mind though and try to simplify it for new devs. :)
I'd love to try this out, but I need the code. I mentioned this before and I thought you were going to give us a link. Can you do that please, because this is the best tutorial on this subject.
Nice tutorial. But i would strongly not recommend making any managers or controllers - they completely break single responsoblitiy principle. The better approach would be to create a state machine not from enums, but with states being classes. This way you encapsulate logic and make clean, resusable code.
State machines (I do use them) also come with a bunch of problems. For example unless your states are monobehaviours, your 'Jump' state can't even hold your jump particles, audio, jump height, coyote time, etc etc. You need to store it all on the state manager, along with every other states references. It's like solving one problem, but only half the way... For any small project, I'll use a simple enum game manager as it quick and easy. Making code reusable and easily maintained only matters when it will in fact be maintained. Even then, spending 10 hours making code maintainable to save you 5 minutes updating something in the future is a bad use of time. This is VITALLY true for game devs as we tend to make 20 prototypes before settling on a game to complete.
Game managers are a vital part of any game. If you enjoyed the video, let me know so I can continue making helpful content :)
Taro, I just wanted to say thank you for making these tutorials, which are very valuable, are worth a lot to us, and I know take a lot of planning and effort on your part! Also, I wanted to tell you that you did an excellent job of explaining what you are thinking, and helping us to understand what you're doing in the code.
I actually sat in front of the code at around 3:45, and I noticed that I understand the stuff you're writing a lot better than I think I understood tutorial code in other tutorials I have watched.
So thank you!
I hope you are very successful, and that the things in your life turn out to be much better than you thought they would.
Thanks Taro,
@@matthewmathis62 lovely words. Thank you so much Matt
This is what I'm looking for, this stuff is hard to find. Where else can I learn to implement this. This is not intuitive and need sets and reps...
I also want to say thank you, I enjoyed watching demo game, your explanation and also quality of your code. It was an enjoyable video from start to finish.
how would you implement an "initiative" stat for each player and enemy? so instead of always repeating 1) the player then 2) the enemy, you would have the player and enemy "roll" a die and the highest roll would go first for that round.
you have the best looking scenes i've ever seen out of all unity tutorial tubers
Thanks Lemmy 😳
I've come to this video for no less than 4x already, trying to fully comprehend your video (even downloaded it to free myself from the limits of my interenet connectivity). It looks really really easy, maybe because you have explained it well. Great video!
Free GameManager in 10 mins. You earned a like and subscribe. No questions ask.
Welcome aboard
Man I love you! I cannot thank you enough, I had my turn based game using if statements in the update method and using bools to check if the players took their turn and overcomplicating the code. Using states simplified things for me a lot, and my code runs only when the state changes instead of all the time checking if something changed.
Got into a jam (just knowing py(REALLY BAD IDEA)), all my team knows and use unity, so here i am almost 3 am learning C#, somehow after 3-4hrs accomplish to understand almost everything, also ur video is one of the best videos i have seen about this topic, congrats :)
Thats the spirit!!
How did it go?
@@SuperchargedW12 actually really well, we have one of the best games in the Jam, and was a really fun experience
Best piece of advice for making a Game Manager I've seen so far. Thank you
not 5 minutes in and already learned a ton, thanks for everyting.
"This is not the best way to do it..", "that is not good design.." ... ".. but for the sake of the tutorial".. The idea is clear already after the first event handling, it would be great to see how every part of the code in the gameManager you write is THE GOOD WAY to do
I would really like to see more tuts about managers and controllers and their corellation, since i'm going trough a C# cookbook for Unity and it is helping me to grasp about game architecture and Unity and C# in general. Btw, thanks, this stuff is awsome.
12:05 Just a note it wasn't mentioned in the video, Added UpdateGameState(GameState.Decide); at the end of the HandleEnemyTurn ()
Why did you call functions like color select outside the manager using OnGameStateChanged, but then calling functions like HandleEnemyTurn() within the manager? I mean, the HandleColorSelection function is empty but its logic handled in another class?
Ohhh I have always avoided naming it "GameManager" cause I thought that unity put the cog there cause unity already has some script named "GameManager" and I was about to override it.
Same
Yuuup
Same!
MyGameManager
@@_sIash yeah any prefix or suffix can work but somehow putting “My” in front of names feels wrong. Just dirty.
Awesome tutorial. Very clear, and I've implemented something along these lines. Keep up the great vids
The video generates more questions than answers. The overall presentation is nothing to complain about and quite good except for the banging sound on your keyboard.
Thanks for these Tutorials, I just found them the other day and am using them to finally develop my game. I joined your discord as well.
Hey man, first of all thanks a lot for this! As im working on my game I just run into this thingy. You explained it very clearly.
Hey man, this was hugely beneficial for me, thank you. If you don't mind me asking, do you recommend any additional resources (books, videos, etc) on the fundamentals of game development?
I've been diving into learning Unity, but this made me realize I'm probably suffering from some serious blindspots in terms of the absolute basics of game design.
I unfortunately cannot recommend anything. I've always been an in-the-moment learner. By that, I mean looking things up as I need them, as opposed to any kind of structured learning experience. It's not for everybody, though... Most people learn better with a bit of structure.
Great video!
I've recently stumbled upon your content while on my Scripting Unity journey.
Quickly I'm becoming obsessed with Architecture and managing the flow of the Game and Logic.
This and many of your videos are great reference!
Not gonna lie I come back to this video basically every time I start a new Unity project
I'll always be here for you :)
Thanks for this tutorial! I am learning how to make my own games now, and this helps!
greatest tutorials on youtube i would say
Sent here from Create a Grid pt 2, nice connection of tutorials!
I don't link my tutorials very often, I should do it more!
absolutely love your content. love the technical perspective as this is always what i was lacking. so glad i stumbled upon your channel!!
Perfect just what I was looking just implementing it. Also great to learn a few other things on the way :).
learned a lot from this video thank you!
extremely useful content!! thanks for the detailed explanations
Could you explain your thinking behind naming your events? I don't quite understand the conventions. I kind of get the OnGameStateChanged name but what's the reasoning behind GameManagerOnOnGameStateChanged?
at 5:50 what is the difference in using OnEnable and On Disable methods to subscribe and unsubscribe the event? this only way ive done it and ive not used OnDestroy?
The main difference is that onawake/ondestroy is for the object lifecycle, vs onenable/disable can be called if the behaviour is enabled/disabled.
Both will be done when object is started/destroyed.
This explains it docs.unity3d.com/Manual/ExecutionOrder.html
Amazing video! Just wondering how you were able to create the alt + Enter to generate the switch statements at 3:03? Would love to know!
That was my bad. I was using an extension called ReSharper. Provides a bunch of quality of life improvements. Rider does the same
Thanks that’s a convenient extension to know 👍
This was great, I wish I had seen this video when you made it ... oh well I'm right the track. :)
Thank you, very intuitive & clear !
Brilliant tutorial. Thanks for your work!
Awesome tutorial! Thanks!
Really helpful, Thanks man
Thanks for awesome tutorial. I personally found having final state machine to change game states easier to manage. All change conditions are in one place. Of course avoiding singleton is not easy but I found it worth in long run. The fact that you do not have access to trigger game level events from any place you wish, forces you to use controlers' events to get informed and then change states. Which in turn decouples the code. But I am still searching for even better way to do it...
Nice tutorial. I’d like to see some videos demonstrating using scriptable objects for this sort of thing.
Could you be more precise about what you expect ScriptableObject to do in "this sort of thing"? I do understand that you can plug SO in a state machine, but I'm not sure why you'd want that here, except maybe to subdivide your code, but you don't exactly need SO for that.
Only way I can see this is create an abstract SO to inherit from and override "StateEntry", "StateRun", "StateExit" functions. Use some static variable that most of your states need to regularly inspect (reference to stat controllers, player controller, or something). Other than that, have state dependant variables public that you wanna set in the inspector, which is the only reason I see SO used in "this sort of thing", or maybe for difficulty settings then you'd swap "CombatState_Normal" with "CombatState_Easy" or "CombatState_Hard".
In the GameManager, have UpdateGameState(newState) call on current state StateExit and new state StateEntry. If current and new state are same, call StateRun.
@@Kalahee Thanks for the reply. I was just starting to dig into ScriptableObjects and it just seemed like something they'd be suitable for. But honestly, it was so long ago I can't remember specifically why I asked that :)
Great tutorial, many thanks good sir!
love your stuff, thanks so much!!
Question: Aren't we supposed to avoid using singletons? According to others, you can go without using them, and there are better options, but I don't know which ones. I don't know what to avoid using singletons for, either. What do?
People love to hate singletons. It's the cool thing to do in the unity world.
You can ask those people for a personal example they have come across where singletons were bad, but they won't be able to give you one. The main concern is that it can become messy in a large project, but I've created large projects and they are entirely manageable.
I also use SO-Architecture, which is generally what people replace singletons with. I love it, but would say it gets equally messy on large projects.
Singletons are 100% fine and are the quickest way to implement game-wide code access. Until you come across a major problem with them personally, don't listen to the deniers.
@@Tarodev i see, I've been trying to learn this today and it takes a while to fully understand how it all works and how to implement it the best way. But I'm glad you responded, and I'm glad i found your channel, it's great for learning about stuff i never find anywhere else. Thank you darling 💞
@@miwwie1504 enjoy your learning adventures
@@Tarodev thank you!
Thank you so much for this video!:) I was able to follow until 5:30 than I got Error CS0246:The type or namespace name 'GameState' could not be found (are you missing a using directive or an assembly reference?) from Unity. Do you have any tip for me how to tell the MenuManager what a GameState is?
Is GameState public?
because he declares it outside the class
I still don't get how gameobjects can speak to other object codes. There are built in methods like oncollision and stuff that wait for events and return data, but i dont get how i can communicate between game objects and share information.
I just recently made a video on all the ways objects can communicate. Here it is: ruclips.net/video/dtv7mjj_iog/видео.html
awesome tutorial! i learned a lot. thank you♥
It’s better to have states as individual objects of a state class. This is so you can have the state objects handle logic that’s only relevant to them, meaning your code is much easier to expand, bug fix and read.
If you don’t know what I’m talking about or mean, google search OOP C#.
You are talking about the State pattern. He said in another video that handling states with a switch is good for 90% of indie games. But state pattern is not harder then this version in my opinion. I wish Unity had some native built in tools for making states.
Hi, can you explain why you used static event instead, what happens if you don't use static events here?
Apologies if it's already been asked, but why is the GameState enum declared outside of the GameManager class?
Just so when referencing the enum outside of the Game Manager class we don't have to do GameManager.GameState.State, we can just do GameState.State. No other reason 😊
@@Tarodev Makes sense, thank you! Great tutorial!
Hey Tarodev, Why are you not using a Singleton here? Can you explain the difference between a singleton and this method?
This method means when the scene is transitioned away from, this game manager will remain idle, in memory. Once a new game scene is spawned, a new game manager will override the last one.
This means we don't need to write any reset logic 😊
That shortcut at 3:00 to auto-generate the switch container just blew my mind. Huge time saver.
Any idea why it would not work here? Windows + latest editors... Some settings need to be activated somewhere?
@@antoinemaes There is also other way to do it: you can type switch and then press Tab twice. Then write the enum.
thx man i rlly needed this
I noticed you used Awake() and OnDestroy() to subscribe and unsubscribe events. Most other tutorials I've seen on the subject use OnEnable() and OnDisable() for this. Is this just a matter of preference, or is there a reason to use one function over another?
Unless your object is being enabled and disabled dynamically it doesn't matter in the slightest as it'll do the same thing. If you don't have enable/disable logic I'd say use Awake/Destroy as they're the first very and last lifecycle events to be called.
@@Tarodev Cool, thanks.
How to make those slick buttons? So pretty!! I want those!
epic tutorial! thanks :)
Amazing video, love your content
It looks like ChangeState is being called recursively so that the OnGameStateChanged?.Invoke() commands will run in the opposite order. Wouldn't this cause some issues?
Also, how would you change this to not use the aync?
It is causing problems, any solution to this? (When changing to a new state inside the funciton called by the switch)
When you subscribe/unsubscribe to the event would it be better to use onEnable/onDisble?
Saw it in some other video, and was wondering if which of the methods would be best practice?
It's contextual. In this case it would serve the exact same purpose.
If I HAD to choose one or the other, I'd choose enable/disable.
@@Tarodev Thank you so much for the quick reply! (and also your video was great help) 👍
Another great one, thanks!
Really good tutorial :)
Hello nice tutorial. I have a question though.
I want to make: when I press the button the attack function will be executed the turn after the button has been pressed. So if I press button on turn 1, the function will be called on turn 2. Is it possible? Hpw can we store the turn integer? with an enum?
Sounds like the button should execute the change state and in the state change event you should execute your attack
@@Tarodev Thanks that was inspiring
Forgive a possibly stupid question, but in a turn based game across different devices, are the states framed purely within the perspective of the device of the player in question (e.g. Your Turn, Wait, Your Turn, Wait, Win/Lose) or would it consider both players (e.g. Your Turn, their Turn, Your Turn, Their Turn, Win/Loss).
My assumption is the first based simply on the fact that one device would see a Win screen and the other a Loss screen, so for this along they'd be "blind" to each other, other than updating the gameboard status after the other player has made their move.
Learning Unity feels like I'm learning React again.
Bruh this is not about unity. It's a design principle
So, is it okay to use gamemanager as singelton?
If you work with a team including designers, look into decoupled architecture. If you're working solo or with one other, singletons will simplify your code and speed your development.
Don't listen to people who say they're bad 100% of the time. Everything has its place
simple video, i like!
I used the gamemanager exactly the same way like here in the past
How would I check the current state during the update method? I understand that the GameManagerOnGameStateChanged function only triggers when the state is changed, there are other functions I'd like to trigger during update only if the state is the correct one.
Solved: if(GameManager.Instance.State == GameState.StateName){}
@@AlexjW3 you got it 😉
Excellent tutorial, thankyou. Can I get the source to the Unit.cs mentioned which uses Factions? Is it available via your Tarobro membership? I'd also appreciate a tutorial on Unity Factions.
Hey mate, I actually don't have the source for this video. But if you pop into discord I can help you with whatever you need :)
Hello Tarodev, I have a pause/unpause function, should we add them to the game state manager?
This is a design decision I've gone either way with. In most cases I'd say no. It comes down to a lot of things like if you're setting your time scale to 0, if it's going to be difficult to re-trigger the unpaused state without causing double up, etc.
@@Tarodev thank you, just as you said.
how would you implement an "initiative" stat for each player and enemy? so instead of always repeating 1) the player then 2) the enemy, you would have the player and enemy "roll" a die and the highest roll would go first for that round.
(Sorry ahead of time for the long comment and lots of questions, I segmented them out with numbers highlighting key areas)
I'm learning about GameManagers right now and this seems like a really useful tutorial, thanks!
But, just out of curiosity, (1) what would the implications be to handle all of these features yourself, using things like variables/properties inside of a GameManager proxy script?
For example, setting a public property or field string as the state name, inside of your GameManager proxy script, to "BetweenRounds", then your game objects/scripts check whether or not the state of that public property/field is "BetweenRounds" before doing the performing that code?
The reason I ask is I'm much more familiar with that sort of workflow, and if that's something I can do, and it's not unreasonably impactful on the performance, then, (2) is that an acceptable solution? If it's not, and there does happen to be a downfall or disadvantage, then I would have to put my laziness aside and do it properly.
Another reason I ask is, the concept of a GameManager seems like a no-brainer when handling multiple elements, but when I looked into it online, I find all sorts of conflicting information, some regarding why Singletons are bad to use in Unity, some how Singletons are good to use in Unity;
And one specifically, a Unity help article from 2017 stating how the GameManager workflow is "Incredibly out-of-date", linking to another article that seems to suggest you should use a preload scene instead, somehow. Although, admittedly I didn't read through it in entirety yet, I've attached it below if you're curious:
answers.unity.com/questions/1124691/creating-a-proper-game-manager.html
((3) It would be nice to hear what your opinion is on that, because if I try to implement an out-of-date workflow then I might end up running into incompatibilities with future features, or dropped support of that workflow)
I read the post you linked regarding a prescene and I think you may be a bit confused, probably due to naming. So when he's talking about game manager, he's more referring to a full system wide management solution, including sound, scenes etc etc. This video is a manager to control the flow of the actual game and has no overlap to his guide. You would absolutely not want to put this on an object which persists through every scene including menus and the like, you'd want a brand new instance of it each new game.
Singletons are very handy and are used widely not just in unity but across all of c# development. Even though his post has no overlap with my video, I'd still like to put my two cents in:
Firstly, I hated how he wrote it in such a factual way when it is in fact subjective. Saying that, a single DontDestroyOnLoad created in a _prescene could be beneficial for readability, but honestly doesn't make too much of an impact. The fact he didn't actually make static instances of the systems classes but instead expected the dev to find them by searching the scenes and then setting individual references in every class which needed them shows me somebody told him statics/singletons are bad so he's just avoided them for the sake of doing so.
In the end programming has many conventions, but as long as an implementation isn't detrimental to performance or readability, you should follow the design pattern you or your team enjoys.
@@Tarodev Thank you very much for your response! I just found you tonight looking for information on game managers, and I also asked a few devs in a discord group, so I got some more advice, it's all helpful.
And, I'm glad I found your channel, severely underrated, you have a ton of content that I can already tell is going to be useful in my process, keep up the great work!
@@tylergillette7050 Glad to have you on board.
Taro, in MenuManager you added a serialized button for _attackButton. What would you do in case of multiple buttons? For example more than 8 buttons.
I would guess make an array/list of buttons!
How closely tied is the GameManager to the EventSystem? Does one take the place of the other? Or do they fulfill separate roles?
They can both exist at the same time
just that with the event system you can avoid having static game manager at all
since you could just not access it directly but still you'd have a place for your game state
Thanks!
Which extension do you use that has a hammer icon? the icon next to numbers that refer to which line you are?
This is probably ReSharper.
@@Zicore47 thank you
What is the benefit of marking the Action as an event?
It's more of a limitation. It prevents external classes from assigning it, they can now only subscribe to it.
Great tutorial! It connected many concepts I’ve seen in the past and made it clearer.
Question about the implementation of the enemy turn. You use task.delay saying it is not great implementation.
Could you explain more? Would you use Coroutines instead in a real world context?
Thanks again
So does a game manager replace a game loop?
By game loop do you mean void Update? If so, no at all. If by game loop you mean a place to manage the flow of the game, for example initial setup, player turn, enemy turn, deciding if the game is won/lost, than yes. Think of GameManager as an orchestrator. It's the only place to further the game to the next step. (by game I mean actual gameplay, not main menu, splash screen etc).
Can we subscribe lambda function to the event and then unsubscribe that lambda.
SomeEvent += () => print("Something");
SomeEvent -= () => print("Something");
is this possible?
I guess it's too late but for lambda expressions you can only subscribe (because as there's no reference you can't unsubscribe it).
What do I have to enable to get that alt+enter key command? Does it work in VSCode?
Great video as always. Any idea why I'm not able to call the UpdateGameState(); function from a UI Button OnClick() event?
I dont understand that there is logic inside the switch statements, and additionally in other scripts in the game
I was interested in this (had heard about this approach, but never implemented it myself), but when you made the UnitManager change the state of the game, it gave me pause.
Is there a relatively simple way to avoid this?
I'm think events or something like that. So the actual state changing happens inside the GameManager, and it just listens things happening in the game before changing. It starts getting really close to a state machine by then, but still.
Opinions?
Just depends how decoupled you'd like to make it. Don't just decouple for the sake of it, do it when you feel it's needed. For example if you think the project will chop and change a lot, or if you think you'll ever need each individual part by itself (for testing, or different scenes).
Decoupling has many benefits, but it also makes it harder to keep track of what's happening.
My main rule: keep it simple unless required otherwise.
Hi Taro, love your videos. Could you tell me what programs/resources you frequently use for your visual design? I really like the look.
I'm trying to figure out how to create persistent based game that runs in the background
Thank you.
Hey Tarodev, I wanted to thank you for this video! I’m using this to write out the skeleton for an online turn-based combat game I’m building with PlayFab and Photon. I was curious, what UI asset are you using? I love the colors and the font style! So good for prototyping!
Can you tell how you made your shader
what is that shader on your materials?
Alt Enter not working to auto fill the switch statement for me...
bro, i want an app to speed up the game but i don't know how to do it
Making a GameManager and events static is an architecture killer, this is no doubt. Other than that good tutorial, keep it up!
I agree, for large projects. But a small one? Use the quickest tool for the job which is undoubtably singletons and enum based game managers.
Saying that, I have used both of those things in decently sized projects (albeit, as a solo dev) and they've been fine
@@Tarodev For the sake of the tutorial it might be the case but I did not expect to see a static GameManager in the video called "Game Manager - Controlling the flow of your game [Unity Tutorial]" since it is definitely not the best practice. Long story short, it destroys OOP concepts completely, GameManager stops being an "entry point" and it is hard to control on a larger scale since everybody calls it from everywhere.
Besides that in our production we avoid using UnityEvents. I understand it was made for the sake of simplicity as well (just drag and drop) and it might be useful if designers tweak them (which never happened to me in real projects).
In any case, I love your channel and there is a lot I have learned from you.
@@Tarodev What will be the problem of using this static GameManager in a large project and is there a better solution?
in ruclips.net/video/4I0vonyqMi8/видео.html there is apparently a shortcut to implement a new function, when you write it, and its not existing yet, can you tell me how you did it?
Hey, I've been watching a lot of your tutorials these last few days and I find your content entertaining and to the point.
I do have some questions concerning this video. You say you keep the complexity low and easy to adapt, yet you need to enter and edit each leaf node in your game flow to change the way the logic plays out. Also, each leaf node needs to know about the existence and implementation of the game manager.
Is this something only suitable for prototyping or how would you scale this up? How would you handle your UnitManager and your team color select screen when more options become available or required? Seeing this system handle change (as you demonstrated with the decide state) can really sell its benefits or show its downsides.
I would really appreciate your input on these matters as it is something I spend lots of time thinking about myself.
Although people tell you left and right that coupling your components is bad, it really isn't. Yes, maybe on a AAA game with lots of people working on it, but as a very small team working on a small to medium sized game it's not a big deal.
If you do want to decouple a but more and organise your states with a bit more control, look into a statemanager. I personally avoid them unless absolutely nessersary.
It really comes down to personal preference, but I tend to use the easiest and quickest option if there are no major reasons not to.
@@Tarodev Thanks a ton for your reply. I always get the shivers when I have to tightly couple things. I have a junior coder that I do not want to influence in a bad wat. It might just be specific to my company's way of working, with customers and project leads changing their minds a lot all the while I'm trying to maintain a certain consistency within the several applications we are working on and maintaining.
I appreciate the added nuance of your reply, it makes it easier to frame the video within its correct context.
@Sander Decleer Do yourself a favour and forget everything youve seen in this video. If you have a gamemanager that keeps track of game state then you need an event system to communicate between objects. So thats A LOT more code than just calling methods on classes. The information you pass between the objects must either be stored in each object until the next Update call (so every object that needs to know some information needs to store its own internal copy of it instead of just calling a method on the class and requesting the information) OR you need to store all information passed between objects in the gamemanager as part of the game state. So now you effectively have one giant class containing all these GLOBAL variables.
@@RealisiticEdgeMod I'm assuming you over-engineer everything. For small to medium games, this pattern is just fine. In fact most shipped games would be using this pattern.
To say ignore it entirely just because there is a more complex and scalable solution is silly. Use the quickest and most efficient tool for the job at hand.
@@RealisiticEdgeMod Thanks for your reply. I see the advantage of totally decoupling everything and using a message system once you application grows larger. For a smaller system or subsystem I believe readability and ease of seeing all moving parts in a sequential fashion has its merits. So there direct message calls could be an option. The thing I disagreed most with in this video would be that the state change is controlled by the simpler classes, thus making them dependent on the implementation of the gamemanager. The core application logic should be contained there, and other objects should only expose events or another way for the game manager to determine what happened and act accordingly. Event systems are one option for that.
Excuse the rant, I appreciate your time and insight.
I am inspirated.
Could you explain alternatives to avoid hard coding?
Create a publisher subscriber system - an eventbus that manages the subscribing to and publishing of events.
Why don't you do a tutorial that builds the scene with the firing etc.
Sad - seems to be such a usefull tutorial.. Also for Begginers like me .. !!!
But its an example on a "prefixed Game" that never showed how it works - so that makes it MUCH more complicated for me to understand :(
Although Thanx for the Tutorial
I see what you're saying and I could have done a little more to simplify it. But the video was not about the game (what you see in the video is the whole game, I made it for this video).
Every time I make a tutorial I have to decide if I want to make it visually pleasing and fun to watch or drop-dead boring with no context. I'll keep this in mind though and try to simplify it for new devs. :)
Спасибо
Hi, Tarodev, that's a great tutorial. I learned a lot from it. I was wondering if you have the code available in downloadable format.
Ahhh, I didn't realise I hadn't added it to the description. I'm away right now but I'll try remember to put it in. Sorry about that mate!
@@Tarodev Much appreciated.
I'd love to try this out, but I need the code. I mentioned this before and I thought you were going to give us a link. Can you do that please, because this is the best tutorial on this subject.
I learnt absolutely nothing from this video! this was because i wasn't paying attention. *_*note to self. rewind video and pay attention*_*
Got me in the first half bro...
@@Tarodev sorry lol. I keep getting distracted. Good for your view count though!
tks u
Nice tutorial. But i would strongly not recommend making any managers or controllers - they completely break single responsoblitiy principle. The better approach would be to create a state machine not from enums, but with states being classes. This way you encapsulate logic and make clean, resusable code.
State machines (I do use them) also come with a bunch of problems. For example unless your states are monobehaviours, your 'Jump' state can't even hold your jump particles, audio, jump height, coyote time, etc etc. You need to store it all on the state manager, along with every other states references. It's like solving one problem, but only half the way...
For any small project, I'll use a simple enum game manager as it quick and easy. Making code reusable and easily maintained only matters when it will in fact be maintained. Even then, spending 10 hours making code maintainable to save you 5 minutes updating something in the future is a bad use of time. This is VITALLY true for game devs as we tend to make 20 prototypes before settling on a game to complete.