Inheritance and saved games
In this final stage, you should use inheritance to make a number of subclasses
of object
for different kinds of objects. Once you do this, in order for
polymorphism to work, you will have to change all your vector<object>
to
vector<object*>
and use dynamic allocation to create your objects.
The other major task of this stage is to implement two new commands:
save
saves the current state of the game to a file or files, using thefstream
facilities.load
completely replaces the current game state with the state in the files.
The player should be able to play the game (moving around, picking up objects,
dropping them in other locations, etc.), save
, quit the program completely,
start it up again, maybe move around a bit, load
, and then have everything
be exactly as it was when they save
d.
Some hints:
You can use more than one file to save the game! One file per-location, plus a file for the player’s inventory will make things much easier than trying to pack everything into a single file.
You only need to save data to the file which can be changed by the player! E.g., the text descriptions (
look
) for rooms and objects presumably don’t change, so there’s no point in saving them. Similarly for the directions that connect the different locations; these don’t change, so don’t save them. The player’s inventory, location, and the contents of each location can change. If the player can manipulate objects in some way (turn them on and off) then that would need to be saved.load
should not make any assumptions about the current state of the game. E.g., you should not assume that the player will only do aload
after they have just started the game! A common pattern is to save your game, try something, and then if it doesn’t work, load and try something different. This means thatload
must be capable of “resetting” the entire world before it incorporates the changes saved in the files.
Submitting
Save your source code file(s) into ~/projects/stage4/
.