Jump to content
  • Advertisement
Sign in to follow this  
Shadowwoelf

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.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Advertisement
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by Shadowwoelf
Is 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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by Sneftel
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.


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 this post


Link to post
Share on other sites
Quote:
Original post by Shakedown
Just 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 this post


Link to post
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]

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!