Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm running in circles here trying to figure out how to implement game states!

Many of the articles I have read use an abstract class that game states inherit, and another "manager" class that handles pushing/popping game states.

This is fine I guess, but for the game I'm planning on making, I can only imagine I'll have MANY classes, alot of which are nearly identical. For example, I have one game state which is basically a view of my scene with a few GUI buttons. Another game state gets entered when the user clicks the "Terraforming" button, which allows the user to modify the terrain. Both of those have many similarities - they are both rendering the same scene, the controls are the same, much of the GUI is the same except for a new window that contains terraforming controls, and mouse clicking is handled differently. It sounds silly to completely reconstruct a new game state when 90% of it will be identical.

Am I thinking about this the wrong way? Or is there a better solution for managing game states?

share|improve this question
This question needs a more descriptive title, but I can't think of a good one... – Anko Jun 15 '13 at 1:01
up vote 1 down vote accepted

Game states can be implemented however makes the most sense for your game. If you simply have a new mode that slightly alters the running game (like an edit mode), there is nothing wrong with just adding a boolean flag to the game state that indicates edit-mode is on.

You can also keep using different states but put all the shared data in another place. Perhaps you have a singleton GameData that holds everything needed for a running game which is set up and torn down when you transition between the main menu states and the playing states.

Yet another option is to use sub states. You have top-level states like LoadingMain, MainMenu, CharacterCreation, Playing, etc. Inside the Playing state is another state machine with states like LoadingLevel, InGame, Editing, Paused, and so on. The game data is all conveniently stored on the Playing state object while the sub-states control how the simulation is run, what HUD UI is overlaid on the game scene, etc.

Sub states can be implemented by having a generic state machine engine which you can embed in your global engine object to handle top-level states and embedded in individual state objects for sub-states or even in sub-state objects to have sub-sub-states (e.g., if your in-game editor has multiple modes/states). You can also implement it via state stacks.

share|improve this answer

When I started to develop my game engine, I created StateManager and BaseState class, but further I found it extremly unpractical, and removed state management completely. Now I simply use SceneManager loading, unloading scenes. Main problem was transition between states. Now, I just use substates inside scene and that's all

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.