You may also want to study a concept call State Machines.
I have briefly explained them at the bottom of this post here.
If you design your game around different States you can then “push” those states onto your state manager.
Each state >loops< on itself until a condition you specify is met then it transitions on to the next state specified based on the condition(s) met.
Example:
stateSplashScreen
if(>5 seconds delay) push new stateMenuScreen();
(state loops until condition is met)
stateMenuScreen
if(buttonPlay) push new stateStartPlay();
if(buttonConfig) push new stateConfiguration();
…
The nice thing about using this scheme is you can easily rearrange the the processing of your game by adding states.
An example would be what if you wanted to ask the user for his name after you left the splash screen BEFORE the game’s main menu is displayed?
Instead of changing a bunch of GUI code for your main menu, you can create your stateEnterName() class and transition to that first, and then transition to the Main Menu from that state.
Each state is responsible for creating any GUI required and testing for input conditions to cause a transition to other states.
In my states I like to have 3 phases; Init(), Proc() (processing) and Exit().
Every state gets its Init() called - this is where you create your GUI for the state, init variables etc.
Proc() does the bulk of the state’s processing and also checks for transition conditions.
Exit() does any cleanup the state requires (removes GUI, stores settings etc.
How you code your state manager dictates how you create your states and push them onto the processing queue and how they get popped off and processed.
It’s a bit extra coding but sometimes the flexibility is worth the trouble…
-Will