Program Structure

Every computer program ever written is about processing data. As a result, when you design your game program structure, you must specify what data the program processes and what processing operations it performs. This two-step process tells you how to write your program.

To specify the data your program processes, you design the program's objects. Specifying the operations the program performs involves designing the member functions for all of the objects.

Designing Game Objects

Software objects were introduced in chapter 3, "Introducing Object-Oriented Programming." In general, figuring out what objects a game needs is pretty straightforward. Essentially, you create objects for the things you see on the screen. In fact, writing games is one of the best ways to learn object-oriented design because you can generally see the objects you're designing. Figure 7.1 shows a screen shot of the game Ping, which we'll write later in this chapter. Ping provides good practice for learning game software design.

Figure 7.1. Ping requires objects for the ball and the paddle.

The Ping game shown in this figure is a simple simulation of ping-pong or table tennis. Players use the paddles at the left and right edges of the screen to hit the ball back and forth. As you can see by looking at this screenshot, it's very intuitive that the game requires at least two types of objects in the software: one to represent the ball and another to represent the paddles.

Note

You'll find the files for Ping on the CD in the folder \Source\Chapter07\Prog_07_01. There's a compiled executable version of Ping that you can run in the \Source\Chapter07\Bin folder.

After you figure out what objects a game needs, you must design the objects themselves. Specifically, you design your objects identifying the important characteristics or attributes of the object. For example, the ball in Figure 7.1 would require an object that has a position, a height, and width, and a vector describing the ball's movement, and a bounding rectangle. chapter 4, "Introducing the LlamaWorks2D Game Engine," demonstrated the use of such an object by introducing the llamaworks2d::sprite class.

Obviously there is a lot more to designing objects than I've explained in these few paragraphs. In fact, entire books have been written about this topic. However, this short introduction should be enough to get you started. After you finish this book, it's a good idea to invest in a book on object-oriented design. You'll find a few such books in the Suggested Reading list on the CD.

Designing Game Tasks

Although each game you write is unique, nearly every game performs the same set of basic tasks, which are listed below. After you've written code for these tasks for a couple of games, you will become very proficient at it. As a result, you'll be able to rapidly move into the tasks that are unique to the game you're working on.

Factoid

Game programmers have various terms for the message loop. They may call it the update loop, the rendering loop, the main game loop, or the game loop.

• Game initialization During game initialization, your game creates the objects that it uses throughout the entire game. At this point, it does not create objects that it uses on individual levels. Instead, it performs tasks such as loading bitmaps for opening screens and for backgrounds the player sees on all levels of the game. It can also be a time for loading menus, setting up game controllers, initializing the player's score, and so forth.

• Level initialization When your game initializes a level, it creates all the objects used on that level. This is when you should load all of the bitmaps the level requires. As mentioned in previous chapters, loading bitmaps is not a task you want your game doing while it is running. It's a lengthy task and will bring the game to a standstill. That's why your game should take care of it during level initialization. Level initialization is also a good time to load music clips that the level uses.

• Processing messages in the message loop Every game uses a message loop. During the message loop, the game checks the input devices, such as the keyboard or mouse, for input messages. If there are input messages, the game calls functions that react to the messages by updating the game's state. The Ping game shown in Figure 7.1 is a good example. The player using the right paddle presses the up or down button on the keyboard to move the right paddle. The player on the left uses the A and Z keys to move the left paddle up and down, respectively. Every time Ping's message loop executes, it checks the keyboard for those four keystrokes. When it gets messages saying that one of those four keys has been pressed, the loop reacts by adjusting the position of the appropriate paddle.

• Updating and rendering a frame As you've seen in previous chapters, every game must update the state of its data during each frame. The update may be based on the input the game gets from the player. It may also be based on information from the previous frame, such as using a ball's velocity to move it to a new position on the screen. In addition, the update can include playing the appropriate sounds and music. The game must also render all onscreen objects during each frame of animation.

• Level cleanup During level cleanup, your game deletes any objects that it will not use on the next level. It also releases the memory for bitmaps that will no longer be used, displays the player's score for the level, saves the score, and so on.

• Game cleanup Your game performs game cleanup just before the program exits. This task involves deleting all objects used by the game, releasing all memory used by bitmaps and sound clips, displaying the player's score for the session, saving the level number that the player last completed, and so forth.

The example game Ping will demonstrate how to handle all these tasks.