Quote:Original post by Ruzhyo2000
It is occurring to me that, if we are only running a single state at a time, what is the point of a vector? Can we not just have a GameState* member of the GameApplication or GameEngine class that points to whatever state is to be ran? Is the vector a solution to the issue of simply holding the next state, until the current ending state can call it's final render, call uninitialize() or exit() or cleanup() (whatever we are calling it), and then have itself removed from the stack? Or is this not for handling multiple states?
Suppose when I pause the game state, I want the game to continue (in essence you do not have a true pause, you just have your menu open while the game is playing). The menu state could be added to the stack and the game state could call pause();, and the game state could handle and update and render in a manner simply inhibiting your interaction with the game state while the menu state handles the events until it is exited, and the game state resumes as normal. Is this the intended usage of the stack? If not, then from where is its necessity?
You can of course skip using a data structure like a stack or a vector, and just have a bunch of gamestates.
The thing is that then you would have to hard code all the transitions between the gamestates all around the code.
As an example:
Say you press escape while in the menu state. If you don't have a stack or vector it could look something like this:
void calledWhenPressingEscapeInMenu(){ ... currentState = GameStateRunning; // change current state}
Now, the same example using a stack:
void calledWhenPressingEscapeInMenu(){ ... stack.pop(); // remove the gamestate at the top of the stack if(stack.isEmpty()) // Quit the game if the stack becomes empty { gameOver = true; return; } currentState = stack.top(); // the next state becomes the current one}
These two examples are very different. The first one says "Always go to running state when escape is pressed in menu".
The other says "Go back to the state that was active before menu state became the active one".
Lets say that the first state pushed onto the stack when the game starts is the menu state. Now if you press escape the game quits. Neat huh?
At one time the stack could look like this:
[ GameOverState | RunningState | ScoreState | MenuState ]
MenuState is the current state, and by pressing escape you go back to the score state.
In another situation it could look like this
[ GameOverState | RunningState | MenuState ]
Pressing escape here goes back to running state.
Ok you get the idea, basically the stack will keep track of the order of the states.
There is other advantages also, like keeping the states in a stack/list will make the code cleaner and it is easier to iterate/process through the states using a loop.
Imagine the cleanup when the game ends.
Using a stack:
while(!stack.empty()){ GameState *next = stack.pop(); delete next;}
This code will always work. You never need to change it no matter how many states is left in the stack and what they are called.
Not using a stack:
delete GameOverState;delete RunningState;delete ScoreState;delete MenuState;
The code above has to be maintained if you add or remove states to the game.
