Public Group

# Game states

This topic is 3720 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I am a bit confused on game states. Can someone give me a brief overview on them?

##### Share on other sites
The idea is that being at the main menu is very different from playing the game. For one thing, nobody's shooting at you, and there's buttons, and a mouse cursor. I guess that's three things. So you have a variable that tells you which of these situations you're in, and then when it comes time to handle input or draw graphics, you do different things depending on the current state.

Game states are primarily notorious for being heavily overengineered. All you really need is an enum of possible states, and short switch statements for checking which one you're in. You can implement a stack of states if you want to be able to navigate through menus and return from whence you came, but even that's pretty trivial. However, a lot of people -- a little bit drunk on OO -- come up with outlandish yet constraining StateMachine systems which are more difficult to read and to use. Don't be that guy. Don't attack a simple problem with a complicated solution.

##### Share on other sites
Quote:
 Don't be that guy.

Brilliant! That could be the response to about 40% of the posts in these forums...

But I agree. This is quite possibly one of the simplest game specific programming issues, and also one that gets WAY too much energy focused upon it.

##### Share on other sites
Is this a good way to design one?

WinMain
-check to see if any states need updating-

individual states(true)
--logic
--Render()

##### Share on other sites
Quote:
 Original post by ShadowwoelfIs this a good way to design one?WinMain-check to see if any states need updating-individual states(true)--logic--Render()

I'm not sure what you mean by "any states need updating". A state doesn't need updating, because a state isn't an object, just a possible value for a variable. Try this:

Render(){  switch(gameState)  {    case STATE_MENU: RenderMenu(); break;    case STATE_INGAME: RenderGame(); break;  }}

.. and similar for what you're calling "logic".

##### Share on other sites
Quote:
 Don't attack a simple problem with a complicated solution.
There are considerable benefits to using an object-oriented state system, not the least of which is a simple, clean facility for a state stack in a conceptually clean manner. I think you're trivializing the benefits of this approach.

##### Share on other sites
typedef std::stack<GameState> SimpleCleanFacilityForAStateStackInAConceptuallyCleanManner;

How's that? Use std::vector instead if you don't like container adapters (I sure don't).

##### Share on other sites
Quote:
 Original post by SneftelThe idea is that being at the main menu is very different from playing the game. For one thing, nobody's shooting at you, and there's buttons, and a mouse cursor. I guess that's three things. So you have a variable that tells you which of these situations you're in, and then when it comes time to handle input or draw graphics, you do different things depending on the current state.Game states are primarily notorious for being heavily overengineered. All you really need is an enum of possible states, and short switch statements for checking which one you're in. You can implement a stack of states if you want to be able to navigate through menus and return from whence you came, but even that's pretty trivial. However, a lot of people -- a little bit drunk on OO -- come up with outlandish yet constraining StateMachine systems which are more difficult to read and to use. Don't be that guy. Don't attack a simple problem with a complicated solution.

Just to clarify, your statement is on the focus of Game states, not all states, right?

I say this because StateMachines are much more powerful than an enum/switch in appropriate situations.

##### Share on other sites
Quote:
 Original post by ShakedownJust to clarify, your statement is on the focus of Game states, not all states, right?

Yes, definitely. State machines with many similar, easily and regretlessly parameterizable states are ideal for an OO approach. the "game state" machine does not fit that mold.

##### Share on other sites
Edit: whoops I think I misread it. So you have 2 switches. One for logic and the other for rendering? sorta like this?
Logic(){  switch(gameState)  {    case STATE_MENU: Menu(); break;    case STATE_INGAME: Game(); break;  }}Render(){  switch(gameState)  {    case STATE_MENU: RenderMenu(); break;    case STATE_INGAME: RenderGame(); break;  }}

Which would end up being a lot of functions...

[Edited by - Shadowwoelf on May 16, 2008 2:50:26 PM]

1. 1
2. 2
3. 3
Rutin
19
4. 4
5. 5

• 10
• 14
• 30
• 13
• 11
• ### Forum Statistics

• Total Topics
631782
• Total Posts
3002338
×