CP1300:The Caverns of Mysteriousness [只是题目,无代码]

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