I'm not sure if this really belongs here, but here goes. Right now, I'm working on a space-strategy game (a la the Master of Orion series). Among other features that this game would have (and many of which are still undecided), the basic game architecture will be as follows: 1. Introductory Screen - handles things like New Game, Load Game, Exit, etc. 2. New Game Screen - handles game parameters such as the number of stars in the "galaxy", AI difficulty, number of players, etc. 3. Game Screen - where the actual game-playing takes place. Since I'm still a novice at game design, I'm unsure how to link these basic functionalities together. What seems most intuitive is to have an over-arching "system core" that contains the actual game information (uninitialized until a game is actually begun) and uninstantiated Introductory, New Game, and Game "screens" (i.e. objects). The Intoductory screen is initialized first. If the user selects the "New Game" option, the New Game screen is initialized next. Once the user selects the desired parameters for his game, the Game object is initialized with those parameters. Finally, for cross-referencing, I think each screen class should have a reference to the system core. How does this all sound? Comments, questions, and especially criticism is welcome! Thanks, - Rob

I cant seem to actually keep my mind focussed enough to write a longer coherent post at the moment, so Im just going to suggest this: dont obsess over your menu screens, theyre just menus, you can do all that stuff with raw text input if you had to, worry instead about the game mechanics and what you need to achieve them.

Well spoken, xanin!
RobAU78, just start with the game itself. Don't bother having menues at all first. Design the game core first (the functions/classes that actually handle gameplay) and keep things modular (e.g. have stubbed functions for load map, load/save game data and similar things that will be accessed from the menues later).