CP1300 Assignment 2: The Caverns of Mysteriousness
Due: 4 July 2007
You are to implement and test a text-based adventure game:
“The Caverns of Mysteriousness”.
Some documentation will also be required.
Notes About Completion of this Assignment
1. Although the result of completing this assignment will be a playable game,
this is a programming assignment -- you will not be assessed on, for
example, the beauty of your room descriptions. If you are seriously interested
in writing text-based adventure games (aka interactive fiction) please
consider game engines such as TADS3 and Inform rather than expending
your artistic talent on this assignment.
2. Your program will be tested on lab’s Linux. You may develop your program
on whatever computer you wish – a TRS-80, a z-machine, a Turing machine,
Baby’s First PC, or whatever you like -- but it will be tested by typing make on
lab’s Linux to compile your program, and ./caverns to run your program. Your
program must make and run properly; otherwise, expect to be awarded 0
marks in total.
Part 1: Basic Functionality
Replicate the supplied example game’s basic functionality.
You can play the example game by typing:
./caverns
Make sure that you can understand and finish the game. Explore the maze of rooms
thoroughly, especially the mirror room, to understand how they function. Look at the
map in Appendix 1. Later you will need to produce a similar map for your game.
Notes on the game:
Bugs in the example program need not be reproduced in your program.
The only moves available are the directions n, s, e, w, and quit. The player
can type either n or north etc. There is no need to implement diagonal
directions ne, sw etc.
Notes on general implementation:
There is no requirement to implement maze (room configuration) saving and
loading, the maze will be hard-coded, created in code at the start of your
game.
Ignore command line options for the moment, they will be done in part 3
To help with your testing don’t limit the number of player steps yet, wait until
your game is working properly
Don’t worry about the Mirror Room yet, it will be done in part 2
You must not use a grid system, e.g. a multidimensional array, to store
your rooms or connections. Please think of the caverns as different shaped
rooms connected to each other rather than as a grid.
You must not use any global variables in your program.
Begin by creating a class Room. One Room object will represent 1 room of your
maze.
Class Room will have at least:
a description that your program will show when the player enters the room
a method add_connection to connect neighboring rooms
a method travel that is used for player movement between rooms
Make sure that room.h has a comment describing what the Room class is for (same
applies for any other classes you create).
Each Room object must be allocated with operator new. (Don’t worry about deleting
the rooms until part 4 of the assignment.)
Write a function create_maze in file caverns_main.cpp that creates your maze by
making rooms and connecting them. Include testing in the function that ensures that
the rooms really did connect up properly. Here is an example fragment of
create_maze:
Room * room1 = new Room("a large, dry cavern");
Room * room2 = new Room("a narrow tunnel");
// going north from room1 leads the player to room2
// (AddConnection should set both directions)
room1->add_connection(north, room2);
assert(room1->get_connection(north) == room2);
assert(room2->get_connection(south) == room1);
method add_connection must work as shown above, that is, it must use the syntax
above and create a bidirectional connection between the rooms.
To understand the assert function, you can go to:
http://www.cplusplus.com/reference/clibrary/cassert/assert.html.
Create several interconnected rooms. Thoroughly test your room connections before
continuing with the assignment, and keep this testing as asserts in create_maze.
Write the body of your game, including getting commands from the player, and make
sure that the game is playable. Limit the number of steps i.e. make it possible for the
player to die. You may want to create other classes to take care of some aspects of
the game, the design is up to you.
Documentation – program_running_transcript.txt: provide a text transcript of your
game running. See Appendix 2 for a convenient way of doing this. Before
submission make sure that the transcript demonstrates the latest version of your
game running on lab’s Linux.
Part 2: More Complex Rooms
Implement class MirrorRoom so that rooms of this class perform the same
way as in the mirror room in the example program.
Invent and implement a class for another type of interesting room. (You don’t
have to implement the boggy cavern if you don’t want to.)
Documentation – map.doc or map.pdf: once you have a reasonably interesting maze
created (minimum 8 rooms, not the same as any other student’s maze) create a
pictorial map of your maze. This must be submitted along with your code. Also
submit a string of commands that allow the player to successfully navigate the maze,
and a string of commands that leads to death e.g.
Example success path: nnenwse
Example death path: nnwneswneneneswnen
See Appendix 1 for an example map.
A good implementation of parts 1 and 2 may be enough to secure a grade of credit.
Part 3: Command Line Processing
Do not attempt this section unless your game is fully functional.
To make the game as a whole easier to test, provide the following command line
functionality:
Usage: caverns [-gnsewnn] [-c]
-g automatically go in directions listed (in this example north, south, east,
west, north, north), then let player continue & unless the player dies or wins
before the list of commands is finished.
-c cheat mode, infinite number of player steps allowed
misuse of parameters should cause a usage message to be shown
To get an understanding of this functionality explore the options using the example
program.
Documentation – command_line_test.txt Test your command line processing
functionality using the success and death paths you described in part 3. Save a
transcript of this test to a file command_line_test.txt. (see Appendix 2)
Part 4: Finishing Up
You should now have a fully functioning game that is easy to test. Part 4 will add
some programming niceties. Do not attempt these if parts 1, 2, and 3 are incomplete!
Overloaded Operators
Overload the << operator in room so that the room description can be shown
conveniently. Use this functionality in your main program.
Exceptions
Modify the travel method of Room to throw an exception of type TravelException if
the player tries to move in a direction that does not have a connecting room. Catch
the exception in your main program. Test that this exception is thrown in your
create_maze function.
Cleaning Up Memory Allocation
As described in part 1, your Room objects should be allocated with new.
At this stage delete the rooms properly. This can be a complex task because the
rooms are connected together in complex ways.
Implement the deletion using either reference counting(see lecture notes), or by
using the following code fragment from a different program to give you ideas.
Person::~Person()
{
// mark this Person object as deleted so that others don't
// try to delete it again
marked_for_deletion = true;
// delete friend People, unless they are already
// marked for deletion
if (best_friend && !best_friend->marked_for_deletion) {
delete best_friend;
}
if (second_best_friend && !second_best_friend->marked_for_deletion) {
delete second_best_friend;
}
cout << "Debugging: ~Person: deleted person " << name << endl;
}
Use cout to print messages to show that the objects are being properly deleted (as in
the example program and the code fragment).
A good implementation of parts 1, 2, 3, 4 may be enough to secure a grade of high
distinction, with a maximum mark of 100%
Submission
Submit a single zip file called SurnameFirstname.zip containing all of your files.
At a bare minimum the files would be:
Makefile
caverns_main.cpp – main program, must also include adequate testing of
class Room through assertions
room.h
room.cpp
program_running_transcript.txt screen capture of text showing that your game
works (see Appendix 2)
(files for any other objects you needed)
If you have completed part 2 you should also have at least:
mirrorroom.h
mirrorroom.cpp
(plus files for another type of room)
map.doc (or map.pdf) containing:
o a map and explanation of your maze
o a path that leads to success
o a path that leads to death
(see Appendix 1 for an example.)
If you have completed part 3 you should also have at least:
command_line_test.txt – screen capture of text showing that your command
line functionality works (see Appendix 2)
Marking Scheme
Criteria Explanation Marks Available
Functionality Does the program make and
run correctly on lab’s Linux?
10
Quality Is it easy to read, understand,
maintain?
Does it use programming
language constructs well, even
if it may not work all that well?
Will look at
comments
identifier names
structure of code,
including inheritance
10
Tests Have room interconnections
been properly tested, including
the mirror room?
Has the program been properly
tested, and is proof of this
supplied in a file?
Has command line functionality
been properly tested and is
proof of this supplied in a file?
10
Total 30
Marks will be capped based on which parts you completed. It is no use going on past
a part that you have not completed successfully.
Appendix 1: Map for the Example Caverns Program
Example map.doc or map.pdf file for the example program (your maze should be a
little larger than this one)
success path: we
o Minimal, quick escape from the maze
Example success path: nnewsswe
o Visits every room then escapes the same way as the minimal path
Example death path: wwnneeeeeewwwwwwwwww
o Tries mirror room then gets lost in the bog
Appendix 2: Script: A Useful Unix Command
To save your interaction with your program to a file use the command script.
This will change your prompt to remind that it is in operation, and record actions to a
file named typescript.
When you are finished interacting with your program type exit at the prompt, then
look at the file typescript to see that your interactions were recorded properly.
Copy the file typescript to the file you want to keep, e.g.
cp typescript program_running_transcript.txt