In understanding the importance of the cCritter class for the Pop Framework, it will be useful to have a little overview of some of the cCritter child classes that we use. Let's put the UML class diagram (Figure 8.1) here of some (but not all) of our cCritter child classes.
We'll get into more details about various critter child classes later on. For now, note that in the Spacewar game, the player inherits from cCritterArmedPlayer, the asteroids inherit from cCritter, the UFOs inherit from cCritterArmedRobot, and the various kinds of bullets inherit from cCritterBullet. Children of the cCritterWall class are used in the Dambuilder and Airhockey games.
Typically you will define some special cCritter child classes for each new game that you write. The best practice is to put the prototype headers for your new critters in the same *.h file as your game header, and to implement your overridden critter methods in the same *.cpp file as your game implementation.
Which cCritter methods do you typically reimplement for child classes? Certainly you will write a child class constructor to change some of values of the critter fields set by the base class constructor. And you very often override the cCritter::update method. Other cCritter methods you might override are called reset, touch, collide, die, and damage. Table 8.1 on p. 180 lists the overrides.