koobas.hobune.stream
Help with understanding how the gamecontroller script works
I'm trying to understand the concept of game controllers and what all they're used for in different types of games. Are they mainly to control how the game operates? For instance, if I had an RPG that had a questing system, would it be the game controller that manages that? So what all should I consider when building a game controller? Is it everything that doesn't involve user input? Can anyone explain this to me, or at least point me in the direction to find this information?
To clarify, I'm not talking about physical game controllers, I'm talking about the game manager script you add to your game attached as a game object.
It's a game by game sort of thing, but I usually use multiple to handle different types of things, so in an game like Pokemon there might be one that handles wild encounters, one that tracks player progress, and one that handles battle mechanics (I.$$anonymous$$ Fire deals 2x dmg to Grass Types), but i'm also new to game development so take what i say with a grain of salt.
I think I understand. So basically, everything that the game would manage, like respawning killed enemies or characters or resources if you have a crafting system? Things like that?
Yes but like @$$anonymous$$okV said you might want to separate them into smaller managers so that it is easier for you to manage
I would avoid something as generic as a "Game Controller" or a "Game Manager" all together. It might be tempting to have a big container which controls the flow of your entire game, I would however consider having multiple "manager-classes" that each have one job.
A GameStateManager could be tasked to raise and respond to various events all related to the current state of the game. The states could be:
Loading, Playing, Paused, Quitting
I would then consider having a separate QuestStateManager which is tasked with updating various flags based on certain events that the player (or other objects) trigger.
Depending on the size of your game, I would go so far to have separate classes for each quest, which in term implements the means to raise events which the QuestStateManager subscribe to. Each quest would keep its own internal state related to tasks and so on..
An InputManager class could be tasked with routing action messages to say the Player or the UI based on the current gamestate, etc etc.
Often when I have seen "Game Managers", they've contained everything ranging from references to player / enemy objects to keep track of health and update the UI, to generating terrain to saving and loading. The result is an unmanageable cluster of spaghetticode and all it does is contribute to headaches. The truth is, the term "Game Manager" or "Game Controller" is so incredibly vague and thus easy to abuse.
