Haunted Light 2014-02-12 STATES
|
As the first official blog post of the project I am now to describe an artifact that is complete an put into the game. I am going to describe the different states of our game engine. But first of all why do we need states to being with, why not just write the code on the blank code sheet you have in front of you? Well you can of course do that, but in the long run the program with states will be more efficient and less demanding of the system it runs on. The idea behind states is to separate different tasks of the program so that certain parts do their tasks and then passes on only the necessary information so that the next part can preform its task. A couple examples here: The menu state does not need to start the game to function and the game state does not need the menu state’s buttons to function. However Game state need to know that the [New Game]-button has been pressed. And the game state may need switch to main menu if the player so desires. But how? How can we make the different states know about the different states without putting everything in everything? Well this is where the State manager comes into play. It acts on a higher level in the state hierarchy, it will point where the current state is and whats is the next state (depending on if there is such a transition). An example of this transition is the transition between Loading state->Game state. If the player starts a new game the state manager will first check the current state (which is menu state) and the set next state as loading state, when loading state is initiated the current state will be changed from menu state to loading stat. The current state is where the game will generate the level etc… after loading state has done its tasks the next state will become game state, repeating the previous process. To make the state manager aware of the existence of the states, all the different states will have to be attached to an object of the state class when engine.cpp is initialized.
As you can see the state system is built up like a hierarchy of subsystems co-working. There are of course a lot of sub systems such as animated sprites and input, but the general idea of a state hierarchy work pretty much like this. |
