3.6 Using the Pop Framework

In this section we'll talk about how to use the Pop Framework to make a game of your own. To be quite concrete, we'll work through the steps necessary to use the Pop Framework to make a version of one of the simplest and oldest arcade games , the Space Invaders game of the early 1980s.

Extending the Pop Framework

To use the Pop Framework to create a computer game, you take over all of the Pop code and then make some changes to it: either by changing some of the files, by adding some new files of your own, or both.

The fact that this is fairly easy to do means that the Pop code is actually a framework , where a framework is, once again, a collection of powerful code that is written in such a way that it is easy to tailor it to your needs.

By way of making the Pop code into a usable framework, the code is designed so that a fairly complete description of a game can be fitted into a single class extending our basic cGame class. Thus, if you were to make a game called, say, Space Invaders, you might do this by creating a new cGameSpaceInvaders class which extends cGame . The class declaration for cGameSpaceInvaders would live in a new file called gamespaceinvaders.h , and the implementation of the class methods would be in a file called gamespaceinvaders.cpp .

With good planning and object-oriented design, your project need not involve much more new code than is found in, for example, the two gamespacewar files. How will you add files to the project? An easy way is to use copy-and-paste in Windows Explorer to copy some existing similar files, then rename the files, then edit them using the Visual Studio editor, and then use the Visual Studio Project/Add Existing Item... dialog [or Project Add to Project Files... dialog (Version 6.0)] to add your new files to the project. If your game is very similar to, say, the Pop Framework's Spacewar, you might use the gamespacewar files as the ones to copy and rename, otherwise you might use one of our other sample pairs of game files such as gamedambuilder , gamestub , or gamestub3d .

What other new code might you need? You may need some new kind of behaviors for the moving objects onscreen. This involves extending the cCritter class. So as to make your code easier to work with, it's usually a good idea to define your new kinds of critters within your two game class files; that way you still only have two files to open and close.

Another area that you will eventually change in building your game is the appearance of the bitmaps and the background, not to mention the menus and the toolbar. These are all resources that live in the res directory.

The Game Stub classes

Game stub with solid background, Open GL view, and mixed sprites

In the exercises at the end of this chapter, you will actually carry out a series of changes to the Game Stub classes that turn it into a Space Invaders game. For reference, let's get an overview of what the Game Stub classes are. To begin with, Figure 3.12 shows a UML diagram of the important Game Stub classes.

Figure 3.12. UML diagram of the Game Stub classes

Each class has its own constructor, of course. This is where we internally set the characteristic features of the object, such as its behavior and its appearance.

The cCritter child classes generally override damage , collide , update and sometimes in the case of a player critter the reset method. The cCritterBullet children often don't need to override anything, but will sometimes override the initialize(cCritterArmed *pshooter) method that gets called right after the bullet's constructor. The cGame child class overrides a few more methods; the most important ones will turn out to be seedCritters and adjustGameParameters . This is illustrated in Table 3.2.

Table 3.2. The special classes used in the Game Stub code.

Parent class	Child classes	Overrides
cGame	cGameStub	constructor Serialize reset seedCritters adjustGameParameters statusMessage InitializeView collide
cCritter	cCritterStubPlayer cCritterStubRival cCritterStubProp	constructor damage collide update reset
cCritterBullet	cCritterStubPlayerBullet cCritterStubRivalBullet	constructor initialize

Just for example, here's what two of the class prototypes look like in a recent version of Pop. Note that our UML diagram (Figure 3.12) wasn't fully detailed. There is actually an intermediate Pop Framework class called cCritterArmedPlayer between cCritterStubPlayer and cCritterArmed ; and cCritterRivalBullet derives from a special kind of Pop Framework bullet called cCritterBulletSilver . You can find more information in the gamestub.h file.

 class cCritterStubPlayer : public cCritterArmedPlayer //Our player.  {  DECLARE_SERIAL(cCritterStubPlayer);  public:      cCritterStubPlayer();  //overrides      virtual void reset();      virtual int damage(int hitstrength);      virtual BOOL collide(cCritter *pcritter);      virtual void update(CPopView *pactiveview, Realdt);      virtual cCritterBullet* shoot();  };  class cGameStub : public cGame  {  DECLARE_SERIAL(cGameStub);  //Name your statics here  static int PLAYERHEALTH;  static int DEFAULTRIVALCOUNT;  static int DEFAULTSEEDCOUNT;  private:      int _rivalcount;  public:      cGameStub();  //overrides      virtual void Serialize(CArchive& ar); /*Override for          _rivalcount */      virtual void reset();      virtual void adjustGameParameters();      virtual CString statusMessage();      virtual void initializeView(CPopView *pview);      virtual void initializeCritterViewer(cCritterViewer *pviewer);          //To change the default view direction.      virtual void seedCritters();      virtual BOOL collide(cCritter *pcriti, cCritter *pcritj);  };