Players

Context

What is missing is the action. If you are interested, you should be able to figure out how to write the last part by yourself.

Exercises

Change 24

Using the previous changes as a model, define the Player class. No header file will be given. Instead, I'll describe what I want the Player class to do and you will have to figure out how to do it.

A player has a location on the board. You will store it as a SpacePtr and provide an access function similar to the location() access function in the Deed class.

A player has an Account. Once again, provide an access function to that data element.

A player may be in jail. Use a Bool for this. true means the player is in jail, false means he is on the run.

A player may keep one chance card and one community chest card in his hand (get out of jail for free). Use a CardPtr for each. You will need access functions to those too.

Players are stored in a PlayerLoop which is similar to the SpaceLoop. You will need to code a nextTurn() function that will wrap over the end of the list. Since we will also need to loop through all players, code a head() and a next() function that will just be a wrapper (with a cast) for the ones defined in Listable.

Have a look at the game.data file and see how players are encoded.

Note that you will need to use the same trick as we used for CardPtrDeque to resolve circular dependencies in Game.

The test we wrote for change 23 will also work here, so it will be sufficient to do a regression test.

Change 25

Some objects may be owned by a Player. We therefore need a PlayerPtr class. Use the previous pointer classes as a model to define and implement it.

Use the PlayerPtr classes where it is needed. We will use a <nil> value to represent "no owner". Have a look at the new game.data and the tests

Change 26

To complete things, we will store miscellanous items in a special class called Bank. This is basically all the stuff the banker has to keep track of:

• Money in the bank: an Account.
• Who's turn is it? a PlayerPtr.
• How many houses, how many hotels? two integers.
• Why not also put the Dice in this structure... that way everything will be neatly packaged...

To access the data elements, you can either define access functions or make the data elements public.

The main reason to have this package is so that we can again use the CardPtrDeque trick to defer the actual definition of Bank to the implementation and avoid circular references when using PlayerPtr.

Perhaps it might be a good idea to make all data members of Game.h be pointers, so that you no longer need to remember which elements are pointers and which aren't. This requires a little work, but if you are thinking of finishing this project, you will be happy you did it.

Obviously, there will be only one bank in a game, so you can derive Bank directly from Base.

Refer to the now complete game.data file.

Only a regression test is required here. You might need to edit the test code files if you change the Game class to use pointers.