Managing Game States

[desocupado]

So, let's say you're making your game and stuffies, and you make a "main menu" game state with a splash screen, new game button, load game button, quit button. You also have your "game screen" game state, with the map, the ui, etc.

What is the best way to make the change from the "main menu" game state to the "game screen" game state?

I mean, I can setup so that clicking the new game button would free the memory from the buttons and splash screen and call the "game screen" state, but that still would be from within the "main menu" state. That doesn't seem like a good/elegant solution.

I've seen a tutorial suggest that I keep my game states in a stack, inside a vector, first in, last out. I would need a game state manager class, which is not a problem, but how is the ideal solution to make the "main menu" state tell the game state manager class "Hey, I'm done, put a game screen inside the stack and start() it, I'll sleep until he's done"?

I hope I'm not being confusing. I want to know how to call the next game state after destroying the current game state, the information on which game state to call being inside the destroyed game state. What is the more efficient/elegant way of passing this information to the game state manager class?

 

[potatojohn]

Here's how I did it: I had a UI class that contained (pointers to) widgets. The global game state had a pointer to the current UI

The main loop called update(), draw(), etc on the current UI pointer

When I want to switch to a different UI I just change the pointer, no need to create or destroy anything.

https://github.com/dvolk/project_x/blob/master/src/ui.h
https://github.com/dvolk/project_x/blob/master/src/main.cpp#L190
https://github.com/dvolk/project_x/blob/master/src/main.cpp#L11747
https://github.com/dvolk/project_x/blob/master/src/main.cpp#L9798

 

[28.8bps Modem]

A stack is usually the right way to go. I'd suggest treating it explicitly like a program stack, where your game states are "functions" each taking a parameter and returning a value.

For example, the main menu can launch a game a number of ways, it can start a new game, continue an explicit save game, or resume from the last saved game. You'd still push the same state on to the stack, but they'd be parametrised differently. Similarly, with a map transition, the map that you just left would return down the stack to the loader state with parameter information on the next map to load and other variables that aren't loaded from saved game state like where the player character/party should be spawned on the next map, etc. The loader would then throw up a loading screen, do the map load, push the map state on to the stack and pass the parameters to it.

 

[flabbyjack]

game.state = 'main menu'
game.state = 'loading'

<fin>

 

[Alex]

Deso, I am not sure why you want to keep track of the game state manually. Assuming you have a graphical library capable of handing events, that is pretty much all you need. For instance, suppose you are on the main screen and the user clicks "new game". The code associated with the new game button will create a new gameworld, associate a new game screen to it, decouple the window from the main game screen, delete the objects there and finally associate the new game screen with the window. This code isn't part of the new game screen. It exists outside of it, though it is referenced from it.

I think keeping your screens on a stack would only make sense if you want to be able to move quickly (without loading) from one to another.

 

[desocupado]

Deso, I am not sure why you want to keep track of the game state manually. Assuming you have a graphical library capable of handing events, that is pretty much all you need. For instance, suppose you are on the main screen and the user clicks "new game". The code associated with the new game button will create a new gameworld, associate a new game screen to it, decouple the window from the main game screen, delete the objects there and finally associate the new game screen with the window. This code isn't part of the new game screen. It exists outside of it, though it is referenced from it.

I think keeping your screens on a stack would only make sense if you want to be able to move quickly (without loading) from one to another.

Well, cause while the main_menu state needs only a pointer to the gui/window objects, the game_screen object needs those, plus the entities vector and the map (which main_menu can't provide), and the next game state has different arguments as well, and so on and so forth. So it's better to call them from one manager class Game, which has all of that stuff, instead of making shit global, or passing one ton of un-needed arguments to every game_state object, only so they can pass them forth.

 

[Hirato]

Depends on your game.

Most older games would run different code paths if they're in the main menu or not.
I use this approach personally, and in my case it boils down to two states, "is in game" and "is not in game". In the former case the gameworld is drawn and in the latter just a background is drawn instead.

Most modern games treat the main menu as a separate game in itself that then loads up the proper game.
You can pretty much safely assume that this approach was used if you can see the game world, game models looping their animations in the background, or the game playing out in the background with dumb AI.


In the vast majority of cases, the loading screen isn't really a state, It's rather noise you draw while you wait for the loading to finish.
For older games, which are basically singlethreaded, they loaded the items one by one and drew the occasional frame with an updated progress bar.
Due to this simple nature, these games have no 'loading state' they're simply loading.

More modern games do the loading in the background in a separate thread, so it can continue playing the game or do other things while things are actually loading.
Generally you get a thread that draws a very smoothly animated loading screen while waiting on the loading thread to finish, this isn't a change of state either.

Interactive loading screens on the other hand almost always have a change of state, as it either changes controls, disables certain things, or involves a little minigame.



It's hard to give a general answer as lots of it boils down to implementation details of the game logic, and what supports that game logic.

 

[DraQ]

A flexible solution would be to not have a menu state.
Just a main menu that is overlaid over the game screen like all the other menus, be them inventory, stat screen and so on

This is how most of the FPS games I can think of and games like Morrowind seem to do it.
You don't really need your menu to handle any sort of logic on its own, just capture input and send it to the underlying logic.
This way you don't have the separate main menu and in-game menu, the main menu is just your general purpose menu overlaid over dummy game state made to show up as blank screen, some background graphics, animation or an "attract mode" which is usually a prerecorded demo.