Structuring Pong

I am making Pong using C++ and OpenGL using Visual Express 2010. It is one of the first games I have made, and I am wondering how to best structure it. The main part that is stumping me is the game menu. Should I put the different game modes in 开发者_C百科different functions, and have a switch in my main function? For example, in Main.cpp, I would include the line

glutDisplayFunction(maincode)

In another file, I would define maincode as something like such (again, psuedocode):

maincode():
    switch m:
       case 1:
           singleplayer = true
           multiplayer = false
           menu = false
       case 2:
           singleplayer = false
           multiplayer = true
           menu = false
       case 3:
           singleplayer = false
           multiplayer = false
           menu = true

I would then, in each file, check to see the values of singleplayer, multiplayer, and menu to determine which mode I am in, then display code accordingly.

However, I get the feeling that this method would get much more complicated as the game gets more complicated, so I don't think this is the proper way to do it.

How should I structure the game and menu?

P.S. I am a C++ programmer for a living, but I just don't have experience programming games.

It's just unnecessary complexity to have 3 distinct bools (totaling to 8 different states, 3 of which would be valid) when the only information you need is which mode you are currently in.

Better use an enumeration, i.e.

enum GameMode {

  GM_SinglePlayer, GM_Multiplayer, GM_Menu

};

and a single variable of type GameMode:

GameMode mode;
mode = GM_Menu;

Having different, mutually exclusive (that's the point that you missed here!) states to switch in between is an important concept in programming, so you are definitely on the right track. Keep working.

The best way to organize a GUI application is using the MVC design pattern. Either that, or it's small modification presenter first.

Knowing that, answers to such questions as your are simple to answer (Alexander Gessler's answer is quite ok)

glutDisplayFunc() is a quick way to display stuff but it quickly becomes more trouble than it's worth when writing simple projects.

Unless you're multithreading and keeping a constant copy of your game-state for glutDisplayFunc() to read, I'd say avoid using it - and even then, probably, too.

For game loops, I believe it's better to drive OpenGL rather than let it drive you.

enum EMode { ...etc };

EMode menu();
void single();
void multi();

int main()
  {
    init(...);
    bool loop = true;
    while(loop)
      {
        switch(menu())
          {
            case EMode.single:
              game_loop(1);
              break;
            case EMode.multi:
              game_loop(2);
              break;
            case quit:
              loop = false;
            ...etc
          }
      }
    finish(...);
    return 0;
  }

Simple menu loop. (Forgive my code style it's different than usual).
It's not a great layout, but it would work for a simple game.

• init() initializes openGL.
• menu(), single() and multi() each have their own loops, which render and swap the buffers manually.
• menu() returns a value specifying which menu item was chosen.

Game loop that runs at constant speed and doesn't waste CPU.

void game_loop(int players)
  {
    CGame game = new Game(players);
    bool loop = true;
    time_type next_frame = get_time() - 1;
    while(loop)
      {
        time_type time = get_time();
        if(time > next_frame)
          {
            do_input(game);
            while(time > next_frame)
              {
                game.tick();
                next_frame += frame_period;
              }
            do_render(game); // draw stuff here, and swap buffers.
          }
        else
          {
            // Don't waste CPU (optional).
            wait_till(next_frame);
          }
      }
  }

Again, not wonderful, but function enough. (I use something like this).

• CGame is the game class (if you want to be OO).

• get_time(), wait_till(), time_type etc are all made up. Use whatever function/type suits.

Quick and off the top of my head - probably even has some bugs - but it could give you an idea.