   Questions about creating a main menu
  Ok, so I want to create a simple main menu for my game. This will consist of new game, load game, exit, etc. It's just going to be text, and when you click on the text, based on coord, the selected statement will execute. What I want to know is should I put this main menu into a seperate .cpp ie. mainmenu.cpp, or should I just put it in with the game, ie. as game.cpp. Also, what would be the best way to execute the statement that is clicked. Such as, if the user selects new game from the main menu, how should I go about starting it. Would i call a function to load all the game stuff (graphics, sound, etc.), or is there a better way? BTW I am using C++ and with SDL.   
  I jus handle all the menu stuff through WinProc. And have the menu as a resource, static, i know.   ;  you should use a game state class, and a gamestate manager of some sort, maybe a simplified interface like this:class GameState(){protected:    void input() = 0;    void render() = 0;public:    void init() = 0;    void gameLoop( float delta ); //calls input, render, etc in order}just a simple idea, i dont have my code so i cant refernece what ive done. as far as menu's go, you should create a small engine for those things to help create ui in other parts of the game.Button, MenuBox, ActionListeners, etc. Take a look at Java Swing api and see how they do it, and implement something similar to fit your needs. Its what I did and it seems to work pretty well.   ;  Looking at it from an OO perspective (I write C# so I have no choice!), you've got two routes you can choose. Either the menu itself is a single entity which handles the whole list of options:// Callback signature for an actiondelegate MenuitemSelectedEvent(Menu menu, int index);struct Menuitem { string Text; Color Color; // anything else that is *data* for // this menu item}class Menu { List<Menuitem> items; int selectedIndex;   // Attach a handler to this from your game logic, which // will remove the menu and change the game state public event MenuitemSelectedEvent MenuitemSelected; Menu(List<Menuitem> Items){ items = Items; ... }  // Someone will want to know how to draw the menu! void Render(Renderer renderer){ ... } // Handle the mouse and work out which item was clicked void DoClick(int x, int y){ ... }}The second route is where each menu item is a seperate control, and the menu is just a 'blank screen' onto which you place the controls. Controls then react to mouse input in the usual way, and your standard UI manager would work out which item was clicked. (If you don't have a 'standard UI manager' yet, the simple idea is that it checks each control's bounding rectangle and gives the event to the first one that it is inside. Keyboard events are passed to the current control.) You'd attach an event handler to the Click event of each menuitem individually in that case.   ;  I agree completely with the previous two posters!I'd recommend implementing a gamestate stack.  Whatever is on the top of the stack receives any events and updates and is also responsible for saying when it's finished.Example States:Main Menu (MM)Gameplay (GP)Options Menu (OM)To Initialise the game you push the (MM) state on to the stack.  Now all your input will go to the (MM) event handler.  Should you click on start game then that pushes the (GP) state on to the stack and now all your input automagically goes to the (GP) handler so now a click fires your gun instead of selecting a menu option.  Now I hit esc mid game to change the options or pause the game.  The (GP) state handler picks up the key and pushes the (OM) state on the stack.  When the (OM) state finishes it pops itself off the stack and everything goes back to (GP) state.You can have non-blocking states so your (OM) state might pass events down the state stack if they're not handled.  This way your options menu wont pause the game, great for multiplayer.   ;  I always feel the game-state stack and the menu stack should be separate. The game-state stack should have things like the basic level view at the bottom, then an FMV sequence, or whatever. You can get into trouble otherwise if, for example, the level changes or you come to a cut-scene while you're on a menu.   ;  That's an interesting point...If you pass messages down the stack then you could always pass messages up the stack too... it depends on whether you pause a game state when entering another.For instance:1. Playing FPS Game.2. Hit Esc for Menu.3. Red Team wins message comes in.The message isn't handled by the menu so drops down the stack until it's handled or rejected.  The next state down is the game which updates the game state.  Now you want to be able to collapse any states above this, so maybe an interuptable flag on a state?  e.g. menu is interuptable, pop it from the stack and continue processing.Alternatively if you want the menu to stay there's no reason you can process the game state further down the stack, you just have to stop it pushing new states.   ;  Yes, you can work around it like that. But that's not really the point; in my opinion the menu tree is not a game state, and mixing the two on one stack is silly. Plus, if you are playing multiplayer and your game includes sequences which involve pushing a game state (and if it doesn't, why bother with a stack anyway?) you need to push that at the top of the game state stack but keep the menus on top. If you add 'insert before menus' functionality to your game stack then it's not a stack any more.   