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

Basically, in every single game I've made so far, I always have a variable like "current_state", which can be "game", "titlescreen", "gameoverscreen", etc.

And then on my Update function I have a huge:

if current_state == "game" 
  game stuf
else if current_state == "titlescreen"

However, I don't feel like this is a professional/clean way of handling states. Any ideas on how to do this in a better way? Or is this the standard way?

share|improve this question
Which language, framework, etc. you are using? – Petr Abdulin Aug 25 '12 at 10:28
Usually Lua+LOVE. I also just discovered that different frameworks have different ways of handling this. SFML seems to have a very nice Screen class. – David Gomes Aug 25 '12 at 10:30
Have you looked into state machines? – Darcara Aug 25 '12 at 11:12
You could also look for gamestates in the search bar on the upper right. Should give some results. – TravisG Aug 25 '12 at 11:14
Must second Darcara - this seems exactly what State Machines are used for. – balajeerc Aug 25 '12 at 14:43
up vote 14 down vote accepted

Since you are talking about screens, I feel it's best to separate all that logic into different Screens. What I normally do:

Define an interface called screen, and have multiple screens implement it. Like LoadingScreen, MainMenuScreen, GameScreen, GameOverScreen, HighScoreScreen etc. In your game you put a variable that holds the current screen. Each loop, you call screen.update() and render the current screen. This will save you a lot of "if this state do that" as your state is defined by current screen.

This will separate your logic very nicely.

Example code:

### Screen interface ###
public interface Screen {

    public void show();

    public void update(float delta);

    public void render(float delta);

    public void hide ();

### An implementation of screen ###
public class MainMenuScreen implements Screen {

    private Game game;

    public MainMenuScreen(Game game) { = game;

    public void show() {
        // init stuff

    public void update(float delta) {
        // react to clicks, update animations etc.
        if (buttonwasclicked) {
            game.setScreen(new GameScreen(game)); // change the screen

    public void render(float delta) {
        // draw everything

    public void hide() {
        // release all resources, as the screen is being hidden

### Game, drawing the appropriate screen ###
public class Game {

    public Screen screen;

    public void update() {

    public void setScreen(Screen screen) {

        this.screen = screen;;

Or depending on your game setup, you maybe have an infinite loop as your game.

while(true) {
share|improve this answer

If you're already using Middleclass, there's an excellent state-machine library to go along with it called Statefull. It's easy to use and esposes the same ideas that Matsemann proposed.

share|improve this answer

If your current_state variable is a string, then this is really easy in Lua:

game_states = {}
    -- game stuff
function game_states.titlescreen()
    -- title screen stuff

-- then, inside the Update function:
share|improve this answer

What I do is roughly as follows:

I have a directed acyclic graph data structure, which is essentially just a bunch of nodes that point at each other. Each node represents a game system. e.g. the UI, the world, the input, the rendering. And each node points at other nodes that come before or after it. Once all the nodes are in place, it's easy to flatten it out into a simple list. Setting up this DAG is the first thing I do during the game's start up. Any time I want to add a new system, say AI, I can just say write that code then tell my game what it depends on and what should depend on it.

My main game loop comes after that and simply runs each system in order. First input is handled, then world updates, then other stuff... UI is near the end, and rendering is last. When the game first starts, there is no world or physics or AI, so those steps are essentially skipped, and just the title screen is displayed. When the you start the game proper, the UI sends a message to the world system to turn on, and it just takes care of itself. Managing game state just means turning on and off the various systems. Each system has it's own set of state information that is handled more or less independently of all others (That's not totally true actually, many systems act on the same set of data - the UI system for example grabs data from the world to display info for example. The AI system also needs to look at and send messages to entities in the world).

share|improve this answer
This answer is a good answer to a different question. – Matsemann Aug 25 '12 at 19:38
How so? He asked how to set up his various game states, and my solution isn't to use a state machine like he has now, but to instead split up the bits into various systems which are not a state machine but rather a DAG. – Alex Ames Aug 25 '12 at 20:58

Here's how I organize my states in Lua + Love2d. It avoids the long if/then statements.

First, I create a basic class that contains an update(dt) and render() methods. You can also give it event handling methods, like onKeyDown(key). I call this class Stage, but any object that implements the methods will work. Then, I make an instance of that class for each game state, implementing the necessary methods. I then create a key/value table with the state's name and the instance of the state. Then keep track of the currentState at the global scope so the states can change it when a certain condition is met.

states = {}
states["title"] = title   -- Where title implements Stage class.
states["game"] = game     -- You could create the instance of 'game' lazily too.
currentState = "title"

function love.update(dt)
    if states[currentState] ~= nil then
share|improve this answer

Well, though it's not pretty it's OK to handle states this way, IMO. You can make it much more cleaner using functions for each state, like:

if current_state == "game" 
else if current_state == "titlescreen"

or something other bothers you in this approach (I mean except that Update method is very long)?

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.