The Components of a Game

Now it's time to look at what makes a video game program different from any other kind of program. Video games are extremely complex pieces of software. In fact, they are without a doubt the hardest programs to write. Sure, writing MS Word is harder than writing Asteroids, but writing Unreal is harder than writing any other program I can think of!

This means that you have to learn a new way of programming that's more conducive to real-time applications and simulation, rather than the single-line, event-driven, or sequential logic programs that you may be used to. A video game is basically a continuous loop that performs logic and draws an image on the screen, usually at a rate of 30 frames per second (fps) or more. This is similar to how a movie is displayed, except that you are creating the movie as you go.

Therefore, let's begin by taking a look at a simplified game loop, as shown in Figure 1.4. The following list describes each section.

Section 1: Initialization

In this section, you perform the standard operations you would for any program, such as memory allocation, resource acquisition, loading data from disk, and so forth.

Section 2: Enter Game Loop

In this section, the code execution enters into the main game loop. This is where the action begins and continues until the user exits the main loop.

Section 3: Retrieve Player Input

In this section, the player's input is processed and/or buffered for later use in the AI and logic section.

Section 4: Perform AI and Game Logic

This section contains the majority of the game code. The artificial intelligence, physics systems, and general game logic are executed, and the results are used to draw the next frame on the screen.

Section 5: Render Next Frame

In this section, the results of the player's input and the execution of game AI and logic are used to generate the next frame of animation for the game. This image is usually drawn on an offscreen buffer area, so you can't see it being rendered. Then it is copied very quickly to the visible display.

Section 6: Synchronize Display

Many computers will speed up or slow down due to the game's level of complexity. For example, if there are 1,000 objects running on the screen, the CPU is going to have a higher load than if there were only 10 objects. The frame rate of the game will vary, which isn't acceptable. Hence, you must synchronize the game to some maximum frame rate and try to hold it there using timing and/or wait functions. Usually, 30fps is considered to be optimal.

Section 7: Loop

This section is fairly simple—just go back to the beginning of the game loop and do it all again.

Section 8: Shutdown

The shutdown phase indicates the end of the game, meaning that the user has exited the main body or game loop and wants to return to the operating system. However, before the user exits, you must release all resources and clean up the system, just as you would for any other piece of software.

You might be wondering about all the details of a real game loop. Granted, the preceding explanation is a little oversimplified, but it captures the essence of what's going on. In most cases, the game loop will be an FSM (finite state machine) that contains a number of states. Listing 1.1 is a more detailed version of what a C/C++ game loop might look like in real code.

Listing 1.1 A Simple Game Event Loop

// defines for game loop states
#define GAME_INIT       // the game is initializing
#define GAME_MENU       // the game is in the menu mode
#define GAME_STARTING   // the game is about to run
#define GAME_RUN        // the game is now running
#define GAME_RESTART    // the game is going to restart
#define GAME_EXIT       // the game is exiting

// game globals
int game_state = GAME_INIT; // start off in this state
int error      = 0;     // used to send errors back to OS


// main begins here

void main()
{
// implementation of main game loop

while (game_state!=GAME_EXIT)
    {
    // what state is game loop in
        switch(game_state)
    {
        case GAME_INIT: // the game is initializing
             {
             // allocate all memory and resources
            Init();

            // move to menu state
            game_state = GAME_MENU;
            }  break;

         case GAME_MENU:  // the game is in the menu mode
              {
              // call the main menu function and let it switch states
              game_state = Menu();

              // note: we could force a RUN state here
              }  break;

         case GAME_STARTING:   // the game is about to run
              {
              // this state is optional, but usually used to
              // set things up right before the game is run
              // you might do a little more housekeeping here
              Setup_For_Run();

              // switch to run state
              game_state = GAME_RUN;
              }  break;

          case GAME_RUN:    // the game is now running
               {
               // this section contains the entire game logic loop
               // clear the display
               Clear();

               // get the input
               Get_Input();

               // perform logic and ai
               Do_Logic();
               // display the next frame of animation
               Render_Frame();

               // synchronize the display
               Wait();

               // the only way that state can be changed is
               // thru user interaction in the
               // input section or by maybe losing the game.
               }  break;

               case GAME_RESTART:  // the game is restarting
                    {
                    // this section is a cleanup state used to
                    // fix up any loose ends before
                    // running again
                    Fixup();
                    // switch states back to the menu
                    game_state = GAME_MENU;
                    }  break;

              case GAME_EXIT:   // the game is exiting
                   {
                   // if the game is in this state then
                   // it's time to bail, kill everything
                   // and cross your fingers
                   Release_And_Cleanup();

                   // set the error word to whatever
                   error = 0;

                   // note: we don't have to switch states
                   // since we are already in this state
                   // on the next loop iteration the code
                   // will fall out of the main while and
                   // exit back to the OS
                   }  break;

        default: break;
        }  // end switch

    } // end while
// return error code to operating system
return(error);

} // end main

Although Listing 1.1 is nonfunctional, I think that you can get a good idea of the structure of a real game loop by studying it. All game loops pretty much follow this structure in one way or another. Take a look at Figure 1.5, the state transition diagram for the game loop logic. As you can see, the state transitions are fairly sequential.

We'll talk more about game loops and finite state machines later in the chapter when we cover the FreakOut demo game.