Playing the Game

Once the primary game state is entered, the game itself starts. The game loop begins executing as soon as the player enters this state. The game loop consists of the following general steps:

• Process player inputs.

• Calculate automated player actions.

• Update the dynamics for all dynamic models.

• If in multiplayer mode, exchange state information with other players (not included in the sample game engine).

• Render the next frame.

These steps that make up the game loop continue to execute as long as the game is in the play state. The first step works with the control preferences defined through one of the option screens. These preferences map mouse, joystick, or keystroke actions to game control functions, which include movement control, weapons control if applicable , and game state control (save game, exit game, activate game console, etc.).

The second step in the game loop provides a similar control function for any computer-controlled models. By controlling the automated models at the same level of fidelity as the player-controlled model, it provides several positive factors. It simplifies the dynamics software by eliminating duplication of creating two separate versions to support both player-controlled and automated models. The other bonus is the degree of fidelity attained by keeping a level playing field between the player and the automated opponents.

Next, we need to update all of the dynamic models. In other words, everything that should move is moved. Objects that support the IDynamic interface have their Update method called in order to calculate new positions or sequence an animation. Once everything has been updated, we are almost ready to redraw the screen. Before we continue on to the rendering phase, we check to see if this is a multiplayer game. If it is, then we must send the state of any local controller objects out to the other players and accept any updates that have been sent to us.

Now we are finally ready to update the screen. The Render method of each object is called. The order in which we make calls is important for some of the objects. As you will see in Chapter 4, the SkyBox object (if it exists for this game) should always be rendered first so that it appears in the background. User interface and console objects should always be rendered last so that they appear on top of the scene. If any of this seems a bit confusing right now, no need for you to worry. As we build up the game engine during the course of the book, each of these steps will be dealt with in detail.

After everything has been rendered, it is time to make a decision. Is the game over? If not, we branch back to the process player inputs step and continue to iterate the game loop. If the game is over, it is time to proceed to the next state ”player scoring.