10.1 The cGame class

10.1 The cGame class

The cGame and cCritter classes are the key classes for writing games using the Pop Framework. In using the Pop Framework to write a game you will typically define a few new child classes of cCritter and a new child class of cGame . Your cGame child will include some new members and will override some of the base class cGame methods .

The most significant member of the cGame is a cBiota *_pbiota object. The cBiota object is a collection of pointers to all of the game's active cCritter objects. The name of this class cBiota is based on the fact that the class is meant to hold the entire population, the 'biota' of the world of the game. This collection class is implemented as a type-safe, serializable CArray , and it has some array-walking methods: draw, move, update, animate, feellistener . Each of these methods calls the method of the same name for each member critter. Thus, for example, update acts like this.

 void cBiota::update(CPopView *pactiveview, Real dt)  {      for( int i=0; i<GetSize(); i++)          GetAt(i)->update(pactiveview, dt);  } 

There's more information about cBiota and its methods at the end of this chapter.

The cGame also has a distinguished cCritter *_pplayer that represents the player. In the Spacewar game, for instance, the _pplayer is the little ship shooting the asteroids . To make our code easier to maintain we always assume that _pplayer is some valid pointer (not NULL ).

Usually _pplayer is a member of _pbiota , but in a few games, like the PickNPop Game, we don't have a visible player; in this case we use a default critter for _pplayer and don't add it to the _pbiota .

It may be that you'll want to add some other distinguished cCritter pointers to the cGame . Thus if, for instance, you want to have a goal to shoot at in the Airhockey game, you might want to define a cCritterHockeyGoal class and give your cGameAirhockey a cCritterHockeyGoal *_pmygoal member. We'll return to this idea later.

cGame also has a cRealBox _border member to specify the size of the game as a rectangle in the mathematical real-number plane or as a box in 3D space. We can choose to have a square flat game world as in Spacewar, or a long thin flat rectangle like in Ballworld. Alternately, _border can be like a solid aquarium as in the 3D Game Stub game, or like a hallway as in the 3D game Defender.

It's worth noting that the apparent sizes of the critters depends on the ratio of their sprites ' radii to the size of the _border .

cGame has an integer _wrapflag to determine if the default behavior of its critters should be to wrap around the edges, bounce, or possibly just stop at the edges. (The codes for these three options are, respectively, cCritter::WRAP, cCritter::BOUNCE , and cCritter::CLAMP .) The individual cCritter have _wrapflag members as well, so this looks like an example of what we call a 'forgery,' that is, of keeping the same data in two different places. But we want to allow for the possibilities that different critters might have different wrap properties. The cCritter(cGame *pownergame) constructor sets the new critter's _wrapflag to match the game's _wrapflag , but then in the rest of the constructor you're free to set the critter's _wrapflag as you like. The cCritterUFO constructor does this for the Spacewar game, so that the cCritterUFO don't wrap even if the other critters do.

cGame has an integer _seedcount to specify how many critters to seed with, and it has an integer _maxscore that can be used to determine when a game is over. Normally the cGame::score() accessor will return the _pplayer->score() .

Another cGame member that we like to adjust is the CArray<HCURSOR, HCURSOR> _arrayHCURSOR . This is used to specify which kinds of cursor tools the game will use. If you run the Pop program and switch among the games, you'll notice that for different games, different sets of cursor tool icons are active in the toolbar.

Another cGame member worth mentioning is the collection class cCollider _pcollider , which holds pairs of critters that we want to check for possible collisions. We'll discuss this class in Chapter 11: Collisions.