Creating an Engine for Games for Windows - Breaking a Game Down into Events
(Page 3 of 11 )
Every Windows program can be broken down into events, which are things that take place while a program is running, such as mouse clicks and window resizes. Just as Windows programs have events that they must handle, games have their own unique set of events that must be taken into consideration during development. The initialization process of a game can be considered an event, and its responsibilities are to load graphics and sounds for the game, clear the playing field, zero out the score, and so on. Similarly, user input carries over to games as well, meaning that mouse clicks and key presses are events that games certainly must concern themselves with. Additionally, keep in mind that, in Windows, it's possible for some games to be minimized or otherwise placed into the background, which means that you'll probably want to pause the game. This activation and reactivation process can be represented by a couple of events.
Note - Many commercial Windows games run only in full-screen mode, which means that they can't be tiled visually with other running Windows applications. Even so, these games are technically still running alongside other programs and, therefore, must be able to pause themselves if another application takes center stage.
Although many other events could certainly factor into a game engine, the following are some of the core events applicable to just about any game:
Initialization
Start
End
Activation
Deactivation
Paint
Cycle
The initialization event occurs when a game is first launched and gives a game a chance to perform critical initial setup tasks, including creating the game engine itself. The start and end events correspond to the start and end of a game, and they provide good places to perform initialization and cleanup tasks associated with a specific game session. The activation and deactivation events come into play when a game is minimized or sent to the background and then later restored. The paint event is sent when a game needs to draw itself and is similar to the Windows WM_PAINT message. Finally, the cycle event enables a game to perform a single game cycle, which is very important, as you learn next.
Establishing the Timing for Games
If you've never taken a look at a game from a programming perspective, it might surprise you to learn how all the movement and the animation in a game are orchestrated. You will learn all the details of animated graphics in Chapter 9, "Making Things Move with Sprite Animation," but for now, I want to touch on the importance of game timing as it applies to animation and other facets of games. Every game, except extremely simple card games, relies on some sort of timing mechanism to enable the game to break down its execution into frames or cycles. A cycle of a game is one slice of time, which usually corresponds to a snapshot of the game's graphics and data. If you think of a game as a movie playing on a VCR or DVD player, pressing Pause allows you to view a single cycle. Stepping forward one frame in the video is like moving to the next cycle of the game. In any given cycle, a game takes care of updating its graphics, as well as performing any other calculations and processing related to how characters and objects are moving and interacting with each other.
A good way to get a grasp on the importance of game cycles is to take a practical game as an example. The classic Space Invaders game was mentioned in the opener of this chapter, so let's use it as an example to demonstrate game cycles. When Space Invaders first starts, the ship is created, along with several rows of alien invaders. Each of these objects has an initial position and velocity. If Space Invaders had no timing or game cycles, the game would be forever frozen in its initial state, as if you had pressed a permanent Pause button when the game started. We know that this isn't the case, however, because the game starts out with the aliens slowly moving across the screen. If you were to view Space Invaders a cycle at a time, you would notice that, in each cycle, the aliens are only moved slightly. This is because there happen to be quite a few cycles taking place in a given period of time, which gives the effect of smooth motion. Figure 2.1 shows a few hypothetical cycles of Space Invaders and how the aliens move ever so slightly, along with a shot fired by the player's ship.

Figure 2.1. A few cycles of a hypothetical Space Invaders game reveals how the objects in the game change slightly with each cycle.
Figure 2.1 reveals how each cycle of the Space Invaders game reflects a small change in the state of the objects in the game. Therefore, the role of a game cycle is to update the status of all the objects in the game and then reflect these changes by updating the graphics shown on the screen. Judging by how fast things are visibly changing in most games, can you guess how often game cycles take place? Even the most sluggish of games includes no less than 12 cycles per second, which is incidentally the minimum rate required to trick your eyes into thinking that they are seeing movement instead of a series of changing images. As a comparison, televisions display 30 different images (cycles) per second, whereas motion pictures rely on 24 images per second. You learn much more about the significance of different rates of animation in Chapter 9. For now, it's important to understand that just about every game is highly dependent on periodic cycles.
Note - A single screen of graphics in a game is known as a frame. Because a new screen of graphics is drawn during each game cycle, the speed of games is often measured in frames per second, or fps. Because the discussion in this chapter is centered on cycles, as opposed to frames, I refer to game speeds in cycles per second. However, cycles per second, frames per second, and even images per second are really the same measurement.
The more cycles a game can run through in a given amount of time, the smoother the game appears to run. As an extreme example, compare the "smoothness" of a slideshow to a motion picture. The slideshow abruptly moves from one still image to another with no transition or sense of smooth movement, whereas a motion picture shows fluid motion as if you were experiencing it in real-time. Similarly, a game with only a few cycles per second will appear choppy, whereas a higher number of cycles per second will result in a much smoother game. A larger number of cycles per second also gives you more flexibility in speeding up or slowing down a game to arrive at a perfect speed.
Knowing that more cycles result in smoother graphics and better flexibility, you might think that you could crank up the cycles per second really high. As with most things in life, there is a trade-off when it comes to game cycles and game efficiency. The problem lies in the fact that the amount of processing taking place in a game in each cycle is often considerable, which means that to perform numerous cycles per second, your computer's processor and graphics card have to be able to keep up. Even with the blazingly fast computers prevalent these days, there are practical limitations as to how fast most computers can perform game processing. In reality, most games will fall in the range of 15 to 20 cycles per second, with a maximum speed surpassing that of a motion picture at 30 cycles per second. Except for some rare situations, the minimum speed you should shoot for is 12 cycles per second.
Note - Commercial 3D games are always pushing the envelope of what is possible given the current computer hardware available. The number of cycles per second for a modern 3D game is the most common measurement used to determine if the game is being too ambitious in terms of how much it is taxing the processing capabilities of the computer. In an ideal world, you would design games with beautifully detailed graphics and not worry about whether the game brings a user's system to a screeching halt. In reality, game designers are always walking a tight rope to make games look incredibly good yet still maintain a decent frame rate (ideally, 30fps or more).
Now that you understand how the timing of a game is expressed in terms of cycles, you can probably see why a cycle is a type of game event. It works like this: When a game first starts, you initialize the game engine with the game speed in cycles per second. Let's say that you go with 12 cycles per second. The game engine is then responsible for setting up and managing a timer that fires a cycle event 12 times each second. The game code receives these cycle messages and handles them by updating the objects in the game and redrawing the game screen. You can think of a cycle event as a snooze alarm that keeps going off over and over; except in this case, it's going off 12 times a second. Your game clearly isn't getting much sleep!
Note - Speaking of sleep, another role of a game engine is to put a game to sleep whenever it is no longer the active window. In practical terms, putting a game to sleep simply means that the game engine stops sending cycle messages. Because no cycle messages are being sent, the game is effectively paused.
This chapter is from Beginning Game Programming, by Michael Morrison (Sams, ISBN: 0672326590). Check it out at your favorite bookstore today.
Buy this book now. |
Next: Developing a Game Engine >>
More Code Examples Articles
More By Sams Publishing