Adding a Title screen / organizing code

[Kulade]

Ok, I'm not sure how I should implement a title screen into my game. Making one is incredibly easy, of course, but... I don't know how to make the Title screen lead to the actual game. A better way of putting it is that I have no clue how to make both of them part of the same program. It's pretty embarrassing... :oops:

I'm fairly sure that there are a few ways to do this, so could you guys give me some suggestions? Thank you for any help.


EDIT: Actually, the Title Screen isn't a big problem. It's just that I'm trying to find a way to organize my code. The best question I should ask is: In what way do you write organized code? Also, is that something that a beginner should be worried about?

[Relic]

One of possible ways to organize a graphical application is using "application state" paradigm and scenes binded to each state. For example you can create states like:
1. Intro (title, app description, credits etc.)
2. Menu (main gui)
3. Settings
4. Game (the game process itself)
5. Game Over
6. .... whatever you wish
The states may switch when specified events occur:
Intro->Menu switches when intro time expires
Menu->Settings (or Game) switches when a user clicks a menu button
...

[Disch]

Another polymorphic approach would be something like this:

Code: [Select]


class GameState
{
public:
  virtual ~GameState() { }
  virtual GameState* Run() = 0;
};

// .. derive different game states from GameState, such as
//  TitleScreen, Settings, MainGame, etc

// .. then in main:

GameState* currentstate = new TitleScreen;
while(currentstate != 0)
{
  GameState* nextstate = currentstate->Run();
  delete currentstate;
  currentstate = nextstate;
}



The idea is that each game state then returns an instance of the next state to run.  So TitleScreen::Run would return "new MainGame;" or "new SettingsMenu;" or something depending on whatever options the user took at the opening menu.

Just have run return 0 when you want the program to close.


EDIT:  another advantage of this is that you can nest states.  For example, you could call Run from inside other Run functions (for instance if you wanted to open the SettingsMenu from MainGame, or something like that).

In which case returning 0 would mean "go back to the previous state" instead of "close the program"


EDIT 2:

Also, is that something that a beginner should be worried about?

Yes.  Code organization is a big deal.  I can't tell you how many projects I've ultimately dropped because over time the code just became too messy to work on any more.