Chapter 10. Games

A computer game, or other kind of simulated world, will contain a number of agents , or critters, each with its own sprite. It's natural to have a Game base class to hold the active array of critters. As well as being a container, the Game class should take on some additional duties . When the play begins, the Game object initializes the geometry of the world and adds in the critters. While the play continues, the Game object repeatedly updates the critters and shows them on the screen. At the same time, the Game object tracks the critters' status and decides when the world should be moved to a new level. And the play ends when the Game object decides that it's over.

We implement these design ideas as the cGame class that makes up the core of the Pop Framework.

Remember that in an MFC program like Pop, the data for the program lives in a CPopDoc document object, and the onscreen window display is controlled by a CPopView view object. Except for one little extra bookkeeping variable, the sole member that we put inside our CPopDoc class is a cGame* _pgame .

Why is it that we use a cGame* _pgame instead of a cGame _cgame ? As we've mentioned before, we do this because we want polymorphism to work! In C++, a call like _pgame->seedCritters() will work polymorphically and figure out the correct version of the method depending on what kind of cGame child class object _pgame actually points to. But a call like _cgame.seedCritters() will always just use the base class cGame::seedCritters . Always remember, in C++ pointer variables behave polymorphically, but instance variables do not. See Chapter 22: Topics in C++ for more about this point.