Credit
This project is loosely based on a Nifty Assignment created by Dr. John Estell as
Escape to Pokegon.
I've changed a lot of it, but some of the text is copied verbatim with
Dr. Estell's permission.
Any mistakes are mine.
Overview
The developed software will be an adventure game that simulates
one or more adventurers exploring Lancaster County.
The adventurers will be directed by text commands typed by the
person playing the game.
|
Adventure games generally consist of an adventurer moving from room to
room through a set of interconnecting corridors. For our purposes,
each room has a number, and (usually) up to four corridors leaving the room. The directions for travel are indicated by position:
top is north, bottom is south, left is west, and right is east
as shown in the figure at right.
Normally corridors can be traversed in both directions but not always.
Some of the rooms have objects within them. These objects can be taken by the adventurer and carried to another location where they can then be deposited. The adventurer maneuvers through the rooms by using one or two word commands. The commands generally consist of an action followed by an object. For example, go north would move the adventurer north into a corridor or room if that is possible. Take pie might add a pie to the adventurer's inventory. |
 |
For this program, instead of rooms and corridors there are locations and roads that need to be represented. In this case, a "room" is now a particular location, and the "corridors" are the roads that lead from that location. Each room also has associated with it a description of the room. In some cases, more than one description is available, depending on various situations. This handout gives a sample room description. More of these will be available as a resource during the project; however, the actual room descriptions (which may incorporate any of the samples) are up to you.
Remember that your software should be G-rated with minimal violence. Aim for a general local audience.
Vocabulary
There must be a text interface to the game.
Upper and lower case letters are not significant.
Arrow keys may be used for movement, but text commands should also work.
Movement is performed by using either of the action words go or move followed by the direction. The allowed directions are north, south, east, west, up, or down. If the adventurer can move in that direction, the movement is performed and the description of the new room or location (for example, somewhere along route 30) is displayed. If the movement is impossible, an error message must be displayed. In addition, if an object is present in the room, the user must be told of this. As a shorthand notation, the direction words can also be used as action words; for example, north, go north, and move north all have the same meaning.
There are two actions for handling objects: take and drop. Take allows the explorer to pick up an object that is present in the room while drop allows an object being carried to be placed in a room.
Some commands are miscellaneous in nature. Quit allows the user to end the game (with options to save the game). Look is used to reprint the room descriptor text. Inventory gives a list of what the explorer is currently carrying. Score is used to print out the current score. Save is used to save the current game state. You may, and should, add further commands.
Required Elements
You are required to use software objects to represent the rooms, objects, and adventurers in this game.
Those objects must be built using meaningful inheritance.
Be sure that your intended implementation substantially supports an
object-based approach to the problem.
There should be at least one adventurer. Inform the player where the adventurer is at the start of the game. I'd like there to be multiple adventurers exploring a variety of locations sometimes alone and sometimes together. They may start separately or together. You might also have other non-player characters.
There should be a variety of objects to collect on the journey.
In the final product, there must be a way to save and restore the game's state. That state must be stored in editable text so that it can be changed by a person.
The game must be able to read a game description that includes, in separate plain text files as described below, room descriptions and object descriptions. I am flexible on the precise format of those files. The objects, their point value, and their initial room location are in the object file. We can discuss including group objects such as a quilt assembled from collected pieces and delivered to the Quilt Museum. We can discuss how to represent characters if you want to do that.
There should be stated goal and a scoring algorithm. The scoring algorithm should include visiting major locations, completing journeys, assembling group objects, and depositing items at the correct location.
Files of Game Description
Dr. Estell suggests that the best approach to writing this type of
program is to create an adventure "engine" where data files
are used to specify the rooms, their descriptions, and their
interconnections. Another one is used for describing the objects.
We might go with the following format for the room database:
Line 1: data in comment form containing room number. Rooms are sequentially enumerated beginning at zero.
Line 2: six integers indicating the ability to travel (in order) north, south, east, west, up, or down from the current room. The value -1 is used to indicate that one cannot travel in that direction; any other value indicates the room number of the room that would be visited if one travels in that direction.
Line 3: points received for visiting this room.
Line 4: name of image file used by your graphics package to illustrate where you are.
Line 5: one line (i.e. short) description of where you are. Short descriptions are often used when revisiting a room.
Line 6: start of (long) descriptive room text. Text will be formatted on the display exactly as it appears in the data file. Multiple lines are permitted; you may assume that a single line of input contains no more than 100 characters. The word END at the beginning of a line is used to indicate the end of the descriptive text.
Example of a room description in a data file:
// ROOM 3 6 12 15 -1 -1 -1 5 WrightsvilleBridge.jpg You are at the Wrightsville Bridge in Columbia. You are at the Wrightsville Bridge in Columbia. A previous bridge at this location was burned by Union troops fleeing the Confederate Army in the Civil War. This is the western edge of Lancaster County. River Road leads north and south from here. ENDObjects can also be represented in a data file. For this example, one could use a one line per object format:
4 2 5 swan 3 0 3 shoofly pie 2 0 6 bag of Wilbur budsIn this example, there are four fields: three integers followed by a string. The first field is where the object is initially located. Note that it is possible to have more than one object present in a room. The second field is the room where the object is to be deposited for credit. The third field is the number of points received for depositing the object in the "credit room". The last field contains the name of the object.
These are examples. You are free to design your own format specifications for your data files. However, that file format must be human readable and the details of the game locale and objects should be there. It should be straightforward to use your program to create a game based on Colonial Williamsburg by changing the data files.