ok i am writing my tile-based game in C++. I have seperated the drawing/rendering code and game code. drawing everything in game is pretty straight forward ( just drawing tiles and characters ( it looks neat ) ), but... what about if i do a little menu screen or an intro? i have no idea how make make this neatly so it doesnt look messy. for example i might want a logo to move accross the screen, would i do: gamecode() { if( intro ) { logo.x++; if( x is too big stop ) { blah } } else { movecharacters(); } } render() { if( intro ) drawlogo; else drawcharacters; } IMO that looks messy. i would like to know how you guys set out your projects.

You can keep a stack of gamestates. Each game state knows how to render itself and handle input. In your main loop, you just tell the top state to render, and give all the input to the top state.

Now, states can do a few things to manipulate the state stack.
They can push a new state on top.
They can pull themselves off.

In your case; when the game started your startup code would create a main menu state. This should always be the bottom state. Then it would create an intro state, and push it on top of the main menu. The intro would play itself, and when it finished, it'd pop itself off and, bam, theres the main menu.
When you start a new game, you push a 'playing' state ontop of the main menu. When you enter the menu from the game, you push a 'in game menu' state ontop of the playing state.
The game loop does not know - or care - what state is on top.

A usefull trick doing this is to just end the program when the game loop discovers the state stack is empty. That way, the 'quit' button just pops the state and nothing else.

i never thought of doing it this way
very clever :)

Don't credit me; it's not my idea. I think it falls under 'Inspiration of the masses', as just about everyone does it this way. Now I'm going to get dozens of flames full of examples that don't do it this way, of course.

Yes, it is. :/

Another idea is to render more than one state each frame. For example you would render the (paused) playing state, then the in-game menu state over it.

You can extend that:

Make a state manager, a gui manager and a scene manager. The gui objects are added to the gui manager, scene objects to the scene manager. When a state changes, you can disable/enable objects in the managers.

Quote:Original post by zdlr
Isn't it just a specific application of the GoF State Pattern?

I don't think so; the GoF state pattern is a particular way to realize a state-machine in code. There are other ways to go about creating the acutal state-machine. The idea to use a state-machine is higher level. Also, the GoF state pattern doesn't explicitly involve a state-stack.