Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: State machines or Screens?  (Read 14044 times)

0 Members and 1 Guest are viewing this topic.


  • Newbie
  • *
  • Posts: 38
    • View Profile
State machines or Screens?
« Reply #15 on: October 25, 2011, 12:56:17 pm »
In my state machine there are two ways to change state:

1) Push the new state onto the state stack
2) Change the top state on the state (basically a pop followed by a push)

That way you can have the main menu push the play state onto the stack, and when the game ends and the play state gets poped, you'll automatically get back to the main menu.

You can also eg. have a paused game state. When resume the game again, the paused state gets poped and you're back in the game again.

When the player selects "Quit" from the main menu, the menu state gets poped, and since there are no more states on the stack, the game ends.
/Peter Welzien


  • Newbie
  • *
  • Posts: 19
    • View Profile
State machines or Screens?
« Reply #16 on: October 25, 2011, 02:03:29 pm »
Ok, thanks. I'll keep that in mind and try to implement my next state machine that way.


  • Jr. Member
  • **
  • Posts: 65
    • View Profile
State machines or Screens?
« Reply #17 on: October 25, 2011, 03:27:24 pm »
Quote from: "TheCake"
I should have seen your second design earlier ... Because it's kind of similar to what PeterWelzien suggested. Thank you, this is what I'm going to consider for my next design.

But I have a new question. I saw some designs given in this thread that use a stack of states, with the running one one top of the stack. Is it really useful to store old states ? Do you have an example of situation where this could be necessary ?

It depends on what you need really. For something like a pause menu where you want to render it over the previous game state and/or return to the previous game state, it's probably a good idea, but you could do the latter with the second design but it wouldn't feel as clean and would probably be a bit hacky. (ex, storing a pointer to the previous game state into the pause menu state so you can return to it later). I personally prefer the first design for larger projects where you need flexibility and the second design for smaller projects where you won't need as much flexibility or if you have memory limitations, as the first design allows you to store multiple states which could eat up memory quickly. If you want examples of implementation you could look at http://code.google.com/p/gqe/ for the first design, and I think http://sourceforge.net/projects/gorefactorsfml/ used a system like the second.
Need a place to upload your code, files or screenshots? Use SFML Uploads!