Let's say I'm making an adventure game. When the program run, I'd need it to do some initialization stuff--load some bitmaps, load up some Lua scripts, whatever--and then open up a standard New/Load/Options/Quit menu. New and Load would then take the player to the main game loop game loop. From the main game loop, then, I'd need to be able to access a save game menu, an inventory display, and... let's say a dialogue tree for conversing with other characters in the game. I'm completely clueless as to how I'd go about switching between these things. The sort of underlying structure I'd need the program to have to handle this. Conceptually speaking, of course. The actual coding itself shouldn't be a problem. Reading over some of the tutorials on the site, I get the impression that I could have a Game class, which would be a composed of objects from other classes representing the various modes of operation I need. The Game class would contain all of the important content and state information about the game, and the other objects contained in the Game class would be ways of handling this data in a more contextual manner. I also get the impression that the basic layout for my gameloop should be something like: 1. Get input. 2. Process input. 3. Redraw screen according to results of step 2. Or maybe something like: 1. Get input. 2. Generate an event based on input. 3. Have the current mode of operation parse this event based on the current context. with the even being stored as a variable in the overarching Game class. Still, horribly confused as to how I'd go about writing a program that's not just "Do one specific thing and then quit."

Okay, just out of curiosity, what might be a non-object oriented approach to doing this?

Go object oriented, IMO.

But a bare bones ("don't do it this way") would look maybe something like this:

int mode = MODE_MENU;bool finished = false;while (!finished){    // get user input    ...    switch ( mode )    {    case MODE_MENU :        ...        if ( user clicked on 'Exit' )            finished = true;        break;    case MODE_GAME :        ...        break;    }    // render stuff    ...}

The best way to get a handle on this sort of thing is just to write a simple game. Make tic-tac-toe or pacman or tetris or space-invaders or whatever. Use the DirectX examples, the SFML examples, the SDL examples, etc if you get stuck.

Take a look at the State pattern.

I think I'm still not getting something here.

Going with the XNA game state manager for a second, it sounds like the main advantage of storing the screens in a stack is that you can, say, go into state Y from state X, go into state Z from state Y, and then get back to state X by popping Z and Y off of the stack and setting X as the active state again, without having to go back to some intermediate state-chooser in between. Is this right?

Going from the State Pattern wikipedia article, though, what would be the advantage of doing *that* over a procedural approach?

I guess my problem is that I'm still not seeing why going object oriented for this would be all that hugely advantageous.