One of the classic arcade games that many people remember is Missile Command, which involves the defense of a group of cities against a nuclear attack. The nuclear attack involves missiles that travel down from the top of the screen toward the cities at the bottom. Your job is to fire upon the missiles and destroy them before they reach the cities. Although Missile Command made for an interesting game in the era of the hit movie War Games, the threat of nuclear attack is somewhat diminished these days, at least in terms of what most of us perceive as a realistic threat. However, there has been increasing talk in the past few years of the possibility of a meteor striking the Earth and causing major damage.

The premise of the game you develop in this hour is similar to Missile Command in that you’re defending helpless cities against an incoming threat. In this case, however, the threat is giant meteors, not nuclear warheads. The Meteor Defense game employs a game play strategy similar to Missile Command in that you fire missiles at the incoming meteors to stop them from destroying the cities below. As you’ll find out, the critical skill to becoming a good player at Meteor Defense (and Missile Command as well) is learning how to target a meteor and give a missile time to get there. In other words, you often have to lead a meteor by a certain distance to give the missile time to get there and make contact.

The object of Meteor Defense is to simply protect the cities against the incoming meteors for as long as possible. One interesting aspect of the game is that you lose points whenever you fire a missile, which makes it important to be efficient when you fire on the meteors. In other words, if you unleash missiles indiscriminately, you will no doubt protect the cities but your score will suffer. This is a subtle way to discourage sloppy game play. Small touches like this can often make a game much more appealing to serious game players.

The design of the Meteor Defense game flows directly from the overview of the game that you just went through. The game is well suited for the starry background that you created and used in previous hours. It’s also fairly obvious that the meteors should be represented by animated sprites similar to those found in the Roids program example from the previous hour. Because you must be able to detect a collision between a meteor and a city, the cities also need to be modeled as sprites even though they don’t move. Representing cities as sprites also gives you the freedom to hide them whenever they are destroyed by a meteor.

Note

In case you were wondering, the terms meteor, meteorite, and meteoroid are all closely related. A meteoroid is a chunk of rock in space that ranges in size from a speck of dust to 100 meters across. A meteor is the bright flash of light generated by a meteoroid when it travels through Earth’s atmosphere. And finally, a meteorite is a meteor that has survived the transition through Earth’s atmosphere and comes to rest on the Earth’s surface.

The missiles in the game are ideal candidates for sprites because they move and collide with meteors. This is generally a good rule of thumb when it comes to deciding which graphical objects should be represented as sprites and which ones can simply be placed in the background: If the object needs to move, animate, or collide with other objects, it should be a sprite. A good application of this test is the guns used to fire missiles in the Meteor Defense game. The guns don’t move, they don’t animate, and it isn’t important to detect a collision between them and anything else. Therefore, you can simply include the guns in the background image for the game.

Wait a minute, I just mentioned using a background image, but I already said that the background is the starry background from earlier in the book. The Meteor Defense game actually uses a hybrid background in that it displays an image of the ground over the starry background. This allows you to get the benefits of the animated starry sky while also showing the ground where the cities are located—not to mention the guns that fire the missiles. To help you get a feel for how the Meteor Defense game is laid out, take a look at Figure 19.1.

Figure 19.1. The Meteor Defense game consists of a starry background, a ground image with guns, several cities, incoming meteors, and missiles.

The figure reveals how the guns are part of the background image that appears along the bottom edge of the game screen. Keep in mind that a starry background still appears in the majority of the screen—the background image just shows the ground where the cities are located. The city sprites are laid on top of the edge of the ground so that they blend into the ground image. The missile and meteor sprites move around on top of the starry background, while the score is displayed centered near the top of the game screen. One last piece of the game not shown in the figure is the target sprite that you guide with the mouse, much like the target sprite you saw in the Battle Office game from earlier in the book.

Now that you understand the basics of the game and how it is laid out, it’s time to examine what kinds of sprites need to be used. Following is a list of the sprites that go into the Meteor Defense game:

The city sprites appear along the bottom of the screen, as shown in Figure 19.1. The meteor sprites are created at random, and fall from the top of the screen toward the cities at the bottom. The missile sprites are fired from the gun locations on the screen upward toward the meteors. I haven’t mentioned the explosion sprites yet, and that’s because there isn’t a whole lot to them. An explosion sprite appears whenever a meteor is blown up or a city is destroyed and involves displaying an animation of a fiery explosion. Finally, the target sprite appears as a crosshair that you guide with the mouse to aim missiles that you launch via the left mouse button.

Beyond the sprites, the Meteor Defense game also requires several bitmaps. Following are the seven bitmap images required of the game:

These images should make sense based on the description of the game and the sprites that you’ve learned about.

With the graphical objects squared away, you need to turn your attention to the other information that must be maintained by the game. For example, the score needs to be maintained throughout the game, as well as the number of remaining cities; the game ends when all four of the cities are destroyed by meteors. This is a game in which it is important to increase the difficulty level as the game progresses. So, it’s important to store the difficulty level of the game and gradually increase it as the player continues to keep his cities protected. The last critical piece of information to maintain is a Boolean variable to keep track of whether the game is over.

To recap, the design of the Meteor Defense game has led us to the following pieces of information that must be managed by the game:

With this information in mind, you’re now almost ready to take the big step of assembling the code for the Meteor Defense game. However, there is a modification you need to make to the game engine to support a critical feature of the game, and ultimately improve the game engine for future games.

If you’re a particularly inquisitive person, you might have wondered how exactly the explosion sprites will work in the game. The animation part is simple enough because the Sprite class in the game engine now allows you to flip through a series of animation images. However, an explosion sprite must cycle through its animation frames and then immediately go away, which sounds simple but presents a problem for the game engine. The problem is that there currently is no mechanism for a sprite to hide or kill itself automatically when it is no longer needed. Granted, you can kill a sprite from within the game code, but how would you keep track of when the frame animation for an explosion is finished?

The real problem I’m talking about here is that of allowing a sprite to animate through one cycle and then go away. The game engine doesn’t currently support this feature, but it’s not too difficult to add. Without this feature, there is no straightforward way to use a sprite such as an explosion that must cycle through its animation once and then exit the game. The key to adding this feature to the game engine is including a couple of new variables to the Sprite class:

BOOL m_bDying;
BOOL m_bOneCycle;

The m_bDying member variable determines whether a sprite has been flagged as dying. In other words, normal sprites have their m_bDying variable set to FALSE, whereas a sprite on the way out has it set to TRUE. The cool thing about this variable is that it allows you to kill a sprite at any time by simply setting the variable to TRUE. Of course, this requires some additional code in both the Sprite and GameEngine classes to make it actually work.

The second member variable, m_bOneCycle, indicates whether a sprite should animate once through its frames and then kill itself. Because this variable only makes sense within the context of a frame animated sprite, it is set when you call the SetNumFrames() method. You see how the SetNumFrames() method is modified to account for the m_bOneCycle variable in a moment.

For now, let’s take a look at how the two new Sprite member variables are initialized in the Sprite() constructors:

m_bDying = FALSE;
m_bOneCycle = FALSE;

As you might expect, the default value of both variables is FALSE, which makes sprites behave normally.

The m_bDying member variable can be set to TRUE through the Kill() method, which is really just an accessor method because all it does is set the variable:

void Kill()  { m_bDying = TRUE; };

This method now gives you a clean and efficient means of killing any sprite—with the security of knowing that it will be properly removed from the sprite list maintained by the game engine. This is a crucial aspect of destroying a sprite because the sprite list in the game engine would go haywire if you were to simply delete a sprite from memory and not remove it from the list. The Kill() method provides a clean interface for carrying out this task.

Whereas the Kill() method provides an immediate way to kill a sprite that can be useful in some situations, the more elegant approach is to allow a sprite to kill itself when it finishes cycling through its frame animations. The UpdateFrame() method now supports this feature by examining the m_bOneCycle variable, and then setting the m_bDying variable accordingly. The original version of this method simply set the m_iCurFrame variable to 0 so that the animation starts over, which this method still does if the m_bOneCycle variable is FALSE. However, if the m_bOneCycle variable is TRUE, the m_bDying variable is set to TRUE, which starts the sprite on a path to destruction.

The m_bOneCycle variable is set in the SetNumFrames() method, which now looks like this:

void SetNumFrames(int iNumFrames, BOOL bOneCycle = FALSE);

As you can see, the SetNumFrames() method now includes a second argument for setting the m_bOneCycle member variable. To help make the transition to using the new version of the method easier, the bOneCycle argument is given a default value of FALSE. This allows you to use the method just as you’ve already grown accustomed. However, if you want to create a sprite that cycles through its animation once and then goes away, just pass TRUE as the second argument to SetNumFrames().

Getting back to the killing of a sprite via the m_bDying member variable, the place where the murder plot unfolds is in the Update() method, which is shown in Listing 19.1.

 1: SPRITEACTION Sprite::Update()
 2: {
 3:   // See if the sprite needs to be killed
 4:   if (m_bDying)
 5:     return SA_KILL;
 6:
 7:   // Update the frame
 8:   UpdateFrame();
 9:
10:   ...
11: }

If you recall, the Sprite::Update() method is actually a large method, so I’m only showing you the beginning of it here because this is all that has changed. The method now checks the value of the m_bDying member variable (line 4), and then returns SA_KILL if it is set to TRUE (line 5). If you recall from earlier in the book, SA_KILL is a sprite action you created that notifies the game engine when a sprite needs to be killed. Prior to now, it was only used to kill a sprite when it encounters a boundary.

Simply killing a sprite isn’t quite sufficient when it comes to improving the game engine for future games. You’ll find out later in the hour that it can be incredibly useful to know when a sprite is being destroyed—regardless of why it is being destroyed. For example, when a meteor sprite is destroyed, you can create an explosion sprite to show the destruction of the meteor. The notification of a sprite being killed is made possible through the SpriteDying() function, which is called whenever a sprite is dying:

void SpriteDying(Sprite* pSprite);

Understand that the SpriteDying() function is a function that you must provide as part of a game. In other words, it is designed to house game-specific code that responds to particular types of sprites dying within a game.

The final change to the game engine to support the new sprite killing features appears within the GameEngine class in the UpdateSprites() method, which now includes a call to SpriteDying() that notifies a game of a sprite being destroyed and removed from the sprite list. This gives the game a chance to respond to the sprite’s demise and carry out any appropriate actions.

You can breathe a sigh of relief because you’re finished making changes to the game engine for a little while. However, the real challenge of putting together the Meteor Defense game now awaits you. Fortunately, the game isn’t too difficult to understand because you’ve already worked through a reasonably detailed game design. The next few sections guide you through the development of the game’s code and resources.

 1: #pragma once
 2:
 3: //-----------------------------------------------------------------
 4: // Include Files
 5: //-----------------------------------------------------------------
 6: #include <windows.h>
 7: #include "Resource.h"
 8: #include "GameEngine.h"
 9: #include "Bitmap.h"
10: #include "Sprite.h"
11: #include "Background.h"
12:
13: //-----------------------------------------------------------------
14: // Global Variables
15: //-----------------------------------------------------------------
16: HINSTANCE         _hInstance;
17: GameEngine*       _pGame;
18: HDC               _hOffscreenDC;
19: HBITMAP           _hOffscreenBitmap;
20: Bitmap*           _pGroundBitmap;
21: Bitmap*           _pTargetBitmap;
22: Bitmap*           _pCityBitmap;
23: Bitmap*           _pMeteorBitmap;
24: Bitmap*           _pMissileBitmap;
25: Bitmap*           _pExplosionBitmap;
26: Bitmap*           _pGameOverBitmap;
27: StarryBackground* _pBackground;
28: Sprite*           _pTargetSprite;
29: int               _iNumCities, _iScore, _iDifficulty;
30: BOOL              _bGameOver;
31:
32: //-----------------------------------------------------------------
33: // Function Declarations
34: //-----------------------------------------------------------------
35: void NewGame();
36: void AddMeteor();

 1:  void GameStart(HWND hWindow)
 2:  {
 3:    // Seed the random number generator
 4:    srand(GetTickCount());
 5:
 6:    // Create the offscreen device context and bitmap
 7:    _hOffscreenDC = CreateCompatibleDC(GetDC(hWindow));
 8:    _hOffscreenBitmap = CreateCompatibleBitmap(GetDC(hWindow),
 9:      _pGame->GetWidth(), _pGame->GetHeight());
10:    SelectObject(_hOffscreenDC, _hOffscreenBitmap);
11:
12:    // Create and load the bitmaps
13:    HDC hDC = GetDC(hWindow);
14:    _pGroundBitmap = new Bitmap(hDC, IDB_GROUND, _hInstance);
15:    _pTargetBitmap = new Bitmap(hDC, IDB_TARGET, _hInstance);
16:    _pCityBitmap = new Bitmap(hDC, IDB_CITY, _hInstance);
17:    _pMeteorBitmap = new Bitmap(hDC, IDB_METEOR, _hInstance);
18:    _pMissileBitmap = new Bitmap(hDC, IDB_MISSILE, _hInstance);
19:    _pExplosionBitmap = new Bitmap(hDC, IDB_EXPLOSION, _hInstance);
20:    _pGameOverBitmap = new Bitmap(hDC, IDB_GAMEOVER, _hInstance);
21:
22:    // Create the starry background
23:    _pBackground = new StarryBackground(600, 450);
24:
25:    // Play the background music
26:    _pGame->PlayMIDISong(TEXT("Music.mid"));
27:
28:    // Start the game
29:    NewGame();
30: }

 1: void GameEnd()
 2: {
 3:   // Close the MIDI player for the background music
 4:   _pGame->CloseMIDIPlayer();
 5:
 6:   // Cleanup the offscreen device context and bitmap
 7:   DeleteObject(_hOffscreenBitmap);
 8:   DeleteDC(_hOffscreenDC);
 9:
10:   // Cleanup the bitmaps
11:   delete _pGroundBitmap;
12:   delete _pTargetBitmap;
13:   delete _pCityBitmap;
14:   delete _pMeteorBitmap;
15:   delete _pMissileBitmap;
16:   delete _pExplosionBitmap;
17:   delete _pGameOverBitmap;
18:
19:   // Cleanup the background
20:   delete _pBackground;
21:
22:   // Cleanup the sprites
23:   _pGame->CleanupSprites();
24:
25:   // Cleanup the game engine
26:   delete _pGame;
27: }

 1: void GamePaint(HDC hDC)
 2: {
 3:   // Draw the background
 4:   _pBackground->Draw(hDC);
 5:
 6:   // Draw the ground bitmap
 7:   _pGroundBitmap->Draw(hDC, 0, 398, TRUE);
 8:
 9:   // Draw the sprites
10:   _pGame->DrawSprites(hDC);
11:
12:   // Draw the score
13:   TCHAR szText[64];
14:   RECT  rect = { 275, 0, 325, 50 };
15:   wsprintf(szText, "%d", _iScore);
16:   SetBkMode(hDC, TRANSPARENT);
17:   SetTextColor(hDC, RGB(255, 255, 255));
18:   DrawText(hDC, szText, -1, &rect, DT_SINGLELINE | DT_CENTER | DT_VCENTER);
19:
20:   // Draw the game over message, if necessary
21:   if (_bGameOver)
22:     _pGameOverBitmap->Draw(hDC, 170, 150, TRUE);
23: }

 1: void GameCycle()
 2: {
 3:   if (!_bGameOver)
 4:   {
 5:     // Randomly add meteors
 6:     if ((rand() % _iDifficulty) == 0)
 7:       AddMeteor();
 8:
 9:     // Update the background
10:     _pBackground->Update();
11:
12:     // Update the sprites
13:     _pGame->UpdateSprites();
14:
15:     // Obtain a device context for repainting the game
16:     HWND  hWindow = _pGame->GetWindow();
17:     HDC   hDC = GetDC(hWindow);
18:
19:     // Paint the game to the offscreen device context
20:     GamePaint(_hOffscreenDC);
21:
22:     // Blit the offscreen bitmap to the game screen
23:     BitBlt(hDC, 0, 0, _pGame->GetWidth(), _pGame->GetHeight(),
24:       _hOffscreenDC, 0, 0, SRCCOPY);
25:
26:     // Cleanup
27:     ReleaseDC(hWindow, hDC);
28:   }
29: }

 1: void MouseButtonDown(int x, int y, BOOL bLeft)
 2: {
 3:   if (!_bGameOver && bLeft)
 4:   {
 5:     // Create a new missile sprite and set its position
 6:     RECT    rcBounds = { 0, 0, 600, 450 };
 7:     int     iXPos = (x < 300) ? 144 : 449;
 8:     Sprite* pSprite = new Sprite(_pMissileBitmap, rcBounds, BA_DIE);
 9:     pSprite->SetPosition(iXPos, 365);
10:
11:     // Calculate the velocity so that it is aimed at the target
12:     int iXVel, iYVel = -6;
13:     y = min(y, 300);
14:     iXVel = (iYVel * ((iXPos + 8) - x)) / (365 - y);
15:     pSprite->SetVelocity(iXVel, iYVel);
16:
17:     // Add the missile sprite
18:     _pGame->AddSprite(pSprite);
19:
20:     // Play the fire sound
21:     PlaySound((LPCSTR)IDW_FIRE, _hInstance, SND_ASYNC |
22:       SND_RESOURCE | SND_NOSTOP);
23:
24:     // Update the score
25:     _iScore = max(--_iScore, 0);
26:   }
27:   else if (_bGameOver && !bLeft)
28:     // Start a new game
29:     NewGame();
30: }

 1: void MouseMove(int x, int y)
 2: {
 3:   // Track the mouse with the target sprite
 4:   _pTargetSprite->SetPosition(x - (_pTargetSprite->GetWidth() / 2),
 5:     y - (_pTargetSprite->GetHeight() / 2));
 6: }

 1: BOOL SpriteCollision(Sprite* pSpriteHitter, Sprite* pSpriteHittee)
 2: {
 3:   // See if a missile and a meteor have collided
 4:   if ((pSpriteHitter->GetBitmap() == _pMissileBitmap &&
 5:     pSpriteHittee->GetBitmap() == _pMeteorBitmap) ||
 6:     (pSpriteHitter->GetBitmap() == _pMeteorBitmap &&
 7:     pSpriteHittee->GetBitmap() == _pMissileBitmap))
 8:   {
 9:     // Kill both sprites
10:     pSpriteHitter->Kill();
11:     pSpriteHittee->Kill();
12:
13:     // Update the score
14:     _iScore += 6;
15:     _iDifficulty = max(50 - (_iScore / 10), 5);
16:   }
17:
18:   // See if a meteor has collided with a city
19:   if (pSpriteHitter->GetBitmap() == _pMeteorBitmap &&
20:     pSpriteHittee->GetBitmap() == _pCityBitmap)
21:   {
22:     // Play the big explosion sound
23:     PlaySound((LPCSTR)IDW_BIGEXPLODE, _hInstance, SND_ASYNC |
24:       SND_RESOURCE);
25:
26:     // Kill both sprites
27:     pSpriteHitter->Kill();
28:     pSpriteHittee->Kill();
29:
30:     // See if the game is over
31:     if (--_iNumCities == 0)
32:       _bGameOver = TRUE;
33:   }
34:
35:   return FALSE;
36: }

 1: void SpriteDying(Sprite* pSprite)
 2: {
 3:   // See if a meteor sprite is dying
 4:   if (pSprite->GetBitmap() == _pMeteorBitmap)
 5:   {
 6:     // Play the explosion sound
 7:     PlaySound((LPCSTR)IDW_EXPLODE, _hInstance, SND_ASYNC |
 8:       SND_RESOURCE | SND_NOSTOP);
 9:
10:     // Create an explosion sprite at the meteor's position
11:     RECT rcBounds = { 0, 0, 600, 450 };
12:     RECT rcPos = pSprite->GetPosition();
13:     Sprite* pSprite = new Sprite(_pExplosionBitmap, rcBounds);
14:     pSprite->SetNumFrames(12, TRUE);
15:     pSprite->SetPosition(rcPos.left, rcPos.top);
16:     _pGame->AddSprite(pSprite);
17:   }
18: }

 1: void NewGame()
 2: {
 3:   // Clear the sprites
 4:   _pGame->CleanupSprites();
 5:
 6:   // Create the target sprite
 7:   RECT rcBounds = { 0, 0, 600, 450 };
 8:   _pTargetSprite = new Sprite(_pTargetBitmap, rcBounds, BA_STOP);
 9:   _pTargetSprite->SetZOrder(10);
10:   _pGame->AddSprite(_pTargetSprite);
11:
12:   // Create the city sprites
13:   Sprite* pSprite = new Sprite(_pCityBitmap, rcBounds);
14:   pSprite->SetPosition(2, 370);
15:   _pGame->AddSprite(pSprite);
16:   pSprite = new Sprite(_pCityBitmap, rcBounds);
17:   pSprite->SetPosition(186, 370);
18:   _pGame->AddSprite(pSprite);
19:   pSprite = new Sprite(_pCityBitmap, rcBounds);
20:   pSprite->SetPosition(302, 370);
21:   _pGame->AddSprite(pSprite);
22:   pSprite = new Sprite(_pCityBitmap, rcBounds);
23:   pSprite->SetPosition(490, 370);
24:   _pGame->AddSprite(pSprite);
25:
26:   // Initialize the game variables
27:   _iScore = 0;
28:   _iNumCities = 4;
29:   _iDifficulty = 50;
30:   _bGameOver = FALSE;
31:
32:   // Play the background music
33:   _pGame->PlayMIDISong();
34: }

 1: void AddMeteor()
 2: {
 3:   // Create a new meteor sprite and set its position
 4:   RECT    rcBounds = { 0, 0, 600, 390 };
 5:   int     iXPos = rand() % 600;
 6:   Sprite* pSprite = new Sprite(_pMeteorBitmap, rcBounds, BA_DIE);
 7:   pSprite->SetNumFrames(14);
 8:   pSprite->SetPosition(iXPos, 0);
 9:
10:   // Calculate the velocity so that it is aimed at one of the cities
11:   int iXVel, iYVel = (rand() % 4) + 3;
12:   switch(rand() % 4)
13:   {
14:   case 0:
15:     iXVel = (iYVel * (56 - (iXPos + 50))) / 400;
16:     break;
17:   case 1:
18:     iXVel = (iYVel * (240 - (iXPos + 50))) / 400;
19:     break;
20:   case 2:
21:     iXVel = (iYVel * (360 - (iXPos + 50))) / 400;
22:     break;
23:   case 3:
24:     iXVel = (iYVel * (546 - (iXPos + 50))) / 400;
25:     break;
26:   }
27:   pSprite->SetVelocity(iXVel, iYVel);
28:
29:   // Add the meteor sprite
30:   _pGame->AddSprite(pSprite);
31: }

It’s safe to congratulate yourself at this point because you’ve now worked through the design and development of the Meteor Defense game, and you can now bask in the glory of playing the game. Granted, playing a game for the first time is certainly more of a test than it is a true playing experience, but in this case I can vouch that the game works pretty well. Figure 19.2 shows the game at the start, with a couple of meteors hurtling toward cities.

Figure 19.2. The Meteor Defense game gets started with a couple of meteors hurtling at the cities.

Saving the cities from the meteors involves targeting the meteors and blasting them with missiles. When you successfully blast a meteor, you’ll see an explosion as the missile and meteor both are destroyed (see Figure 19.3)

Figure 19.3. Successfully destroying a meteor results in an explosion being displayed.

When the game progresses as more meteors fall, you’ll eventually start losing cities to the meteors. Figure 19.4 shows an example of how the meteors can begin to overwhelm you late in the game.

Figure 19.4. As the game progresses, you tend to lose cities as the meteors start to overwhelm you.

When you finally lose all four cities to the meteors, the game ends. Figure 19.5 shows the end of the game, which involves displaying the game over image on the screen on top of the other game graphics.

Figure 19.5. When all four cities are destroyed, the game ends and the game over image is displayed.

Although it’s sad to think that you’ve ultimately failed to save the cities in the Meteor Defense game, you can sleep well knowing that you can always right-click the mouse to start over and take another stab at it.

This hour carried you through the design and construction of another complete game, Meteor Defense. The Meteor Defense game took advantage of the new game engine features you developed in the previous two hours, and also took a leap forward in terms of showing you how to create engaging action games. The game makes heavy use of sprites, including frame animation—not to mention a great deal of collision detection. Perhaps most important is the fact that the Meteor Defense game can serve as a great starting point for creating an action game of your own that takes full advantage of the game engine.

This hour concludes this part of the book. The next part of the book tackles artificial intelligence, or AI, which allows you to make your games more intelligent.

The Workshop is designed to help you anticipate possible questions, review what you’ve learned, and begin learning how to put your knowledge into practice. The answers to the quiz can be found in Appendix A, “Quiz Answers.”