Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I'm trying to decide on how to structure my main game loop - every example I've seen of the game loop looks a bit like this:

while (true) {
    UpdateGame();
    DrawGame();
}

i.e. it ignores the menu. Should my game loop look like this:

if (ShowMenu() == Play) {
    PlayGame();
}

PlayGame() {
    while (true) {
        UpdateGame();
        DrawGame();
    }
}

ShowMenu() {
    while (true) {
        HandleUserInput();
        DrawMenu();
    }
}

(I.e. the menu and game have separate loops), or should I structure my loop as such:

while (true) {
    switch (state) {
    case Menu:
        MenuLoop();
        break;
    case Game:
        GameLoop();
        break;
    }
}

GameLoop() {
    HandleUserInput();
    DrawMenu();
}

MenuLoop() {
    HandleUserInput();
    DrawMenu();
}

I.e. one big outermost loop. (or does it not really matter?)

For what its worth I'm using SDL / C (although I'd like to think that the question is language agnostic)

share|improve this question
6  
11  
@Joe These QA sites would be brilliant if it wasn't for all those pesky users asking questions... –  Justin Oct 28 '10 at 9:54
    
As an naive beginner I appreciate the overwhelming coverage this question and others like it get. Generally I piece together understanding from multiple answers / resource / viewpoints. –  codinghands Apr 6 '12 at 1:23
add comment

2 Answers 2

up vote 5 down vote accepted

From having read a couple of the related questions posted by Joe I've identified that menu state and game state is often maintained through a stack of states. For example if the user is playing the game and brings up the menu, then after navigating around a bit the game state stack might look a little like this:

  • Graphics menu
  • Options menu
  • Main menu
  • Playing game

The game loop is then structured as single outer loop that updates the current state stack (rather than a loop for each state) - This has the added advantage of being able to cope with a far more complex menu system, for example one where multiple states are layered on top of each other, however the previous state is still visible.

while (true) {
    // This example only updates the topmost state,
    // however it might be necessary to perform processing on
    // the other states if (for example) the menu doesn't obscure
    // the entire screen and the game itself still needs drawing
    Tick(GetTopmostState());
}

The following questions are related to this and cover it in more detail:

share|improve this answer
add comment

That depends a little bit on how the menu is related to your game.

If you are using the standard GUI stack for menus (say you have a traditional GUI form with a drop-down menu but your game in a specialized canvas context) then the event loops are already separated, and you would use the primary event system for your GUI to handle menu events. This won't go into the main loop, because your GUI system presumably already has one.

If instead your menus are part of the context of the game, there are still two options - The menu pops up as part of the game, or the menu state is a completely separate state. In either case, I would probably make the menu elements based on the same kinds of content as the rest of your game, SDL sprites for example. That way, if the menu is integrated into the game, you can just have a sprite group containing the menu elements, and break your event-handling code into code to read traditional elements and menu elements (maybe as separate functions.)

If the menu is in an entirely different state, the easiest thing is to have your entire game switch states and have a new event-handling trigger inside the menu state.

Hope this helps...

share|improve this answer
add comment

Your Answer

 
discard

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.