CIT 590 Assignment 12: Text Adventure
Spring 2009, David Matuszek

Enter a title before removing this line.

Purposes of this assignment:

General idea of the assignment:

Note: You will not have a partner for this assignment.

Write a text adventure game. If you have no idea what I'm talking about, go to and play around for awhile.

In a text adventure game, there is an Adventurer, which is an object representing the human player. You need this object because you need to keep track of where the player is, what the player is holding, and anything else you need to remember about the player.

A text adventure has locations, usually called Rooms. However, a "Room" might be anyplace: In a canoe, lost in the woods, at the north end of a long corridor, etc.

A text adventure has Things, such as knives, batteries, vending machines, flowers, etc. Most Things have some use in the game (but not necessarily). If a Thing has a multi-word name, such as "box of chocolates," the player has to refer to it by one word, possibly "box" and possibly "chocolates." (If you wish, you could allow either word.)

A game is supposed to be fun. There are some minimal conditions for a game to be fun:

The adventurer plays the game by typing in commands. Commands consist of one or two words (more than two is too much work).

There are several commands which are found in nearly every game:

  • go direction -- Moves the Adventurer from one Room to another. The direction is usually one of "north", "south", "east", "west", and sometimes "up" and "down." Occasionally other directions are used, such as "northwest" or "sideways". Directions can usually be abbreviated, such as "n" for north, "u" for up, etc. Many games allow the verb "go" to be omitted, so "n" is short for "go north".
  • look -- Gives a full description of the Room that the Adventurer is in.
  • look thing -- Gives a full description of the named Thing. For this command to work, the Adventurer must either be holding the named Thing, or at least be in the same Room with it. Looking at a thing sometimes reveals surprising details about it.
  • take thing -- Picks up a Thing that is in the same room as the Adventurer. The game might containing Things that cannot be picked up, such as a vending machine, or a cave painting.
  • drop thing -- Puts down a Thing that the player is holding. Usually this means that the Thing is put into the Room that the Adventurer is in, but there may be exceptions (if the Adventurer is on a tightrope, for example), depending on the game.

Here is a command that is occasionally available:

  • use thing -- This is a very general command, whose meaning depends on the Thing. Using a gun is very different from using a key, or a chocolate. Most often, though, games require more specific verbs: shoot gun, open safe, eat chocolate. It's up to you.

Every command should get a response. If there is nothing much to say, the response can be simply OK. If the command can't be done, the player should be told, for instance, I don't understand or You can't go that way. When the player moves to a new location, the response should usually be a full description of the newly-entered Room.


The game itself:

An adventure game consists of:

Your assignment is to write a small adventure game. By "small" I mean somewhere between four and twelve rooms, and four to eight objects (these are suggested numbers, not absolute limits). At least two of the objects should have some "use" relevant to the game. The theme of the game, and the goal of the game, is up to you.

So that your adventure game is not too difficult to grade, please:

Structure of the assignment:

The above are requirements. You may have additional classes and methods as needed, and they should be documented and unit tested as appropriate.

The GUI:

I am providing a simple GUI, You can use this GUI as is (although you will need to at least add some listeners to it), or you can modify it in any way you like. There is also the start of an class.

Separation of concerns:

The classes for the game itself should not do any input/output; in particular, they should not use the GUI in any way. The game should not even "know" the GUI exists. Instead, the GUI should use the classes and methods of the game.

The GUI should get commands from the user and send them to the model. As noted, the model should not know about the GUI, or do any GUI-related things. However, the various areas of the GUI have to be kept up to date. I think that using Observer and Observables may be a good way to do this, but I haven't tried it. At the very least, the GUI could call methods in the model after every command, to get updated information.

Due date:

Tuesday, April 28 , before midnight. Turn in your program electronically, using Blackboard. (See my Instructions for Using Zip Files and Blackboard). Only assignments submitted via Blackboard will be accepted--do not send your program by email. The usual late penalty of 5 points per day (out of 100 points) will apply, up until the time we do the grading for this assignment. No programs beyond that (unspecified) date will be accepted.

We reserve the right to give bonus points to particularly good games.