Purposes of this assignment:

Give you more practice with the structure of OOP programs
Give you an interesting final assignment
Give you a chance to be creative

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 www.ifiction.org 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:

A game should have a goal. The goal should be either stated explicitly, or quickly discovered. Wandering around aimlessly for a long time, wondering what you are supposed to be doing, isn't much fun.
A game should have puzzles to solve. The important thing to realize about puzzles is that they are always much harder than you expect them to be. (It would be a good idea to try out your game on a friend or classmate before handing it in.)
A game should have a mood: It should be tense, or funny, or grim, or ridiculous. Or something. Decide on a mood and try to achieve it.
A game should reward the player who wins. At the very least, provide a congratulatory message. Don't leave the player wondering if the game is over.

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.

Details:

The game itself:

An adventure game consists of:

A TextAdventure class. This class:
- Contains the main method used to start the game.
- Extends JFrame and is the container for the entire GUI.
- Has listeners to respond to inputs.
- Talks to the model and to the adventurer, as needed.
An AdventureModel class. This class:
- Creates the Rooms, the Things, and the Adventurer.
- Connects the Rooms with "paths" to other Rooms.
- Places Things in the Rooms.
- Places the Adventurer in some Room.
- Accepts commands from the player, and executes them.
  - As commands are entered, they should be copied to the main text area.
  - The method that executes commands should return a String to be displayed in the main text area.
An Adventurer (the human player).
- An adventurer has:
  - A location (some room).
  - An inventory (the things being carried).
- An adventurer can:
  - Move from room to room.
  - Carry a number of objects.
  - Pick up, drop, look at, and use various objects.
Some number of Rooms. A room has:
- A name.
- A description, possibly several sentences long.
- Contents: the things in the room.
- Exits: paths to other rooms (usually some of north, south, east, and west).
Some number of Things. A thing has:
- A name
  - If some of your Things have multi-word names, such as "fire-breathing dragon" or "that thing that your aunt gave you that you don't know what it is", then you might want to give your Things both a full name and a one-word name..
- A description, to be shown when the adventurer "looks" at it.
- One or more methods for using the Thing. You can have a multi-purpose use verb, or you can make up your own verbs (for instance, drink water or pour water), which determines what the thing does when the adventurer tries to use it.
  - For simplicity, we will say that the adventurer can only use things being carried (in the inventory)
  - Whether "using" a thing does anything or not (or exactly what it does) can depend on what room it is in, what other things are in the room or in the inventory, or any other conditions you can think 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:

Don't let the player "die" or otherwise get into a situation from which there is no possibility of winning the game.
Include a walkthrough (in a file named readme.txt) to tell us how to play your game to a successful completion.

Structure of the assignment:

Project name: TextAdventure
Package name: adventure
Class names and method signatures: As above.
Provide JUnit tests for: Not required.
Provide Javadoc documentation for all classes and methods, except JUnit tests
- Document JUnit tests if they are complex or do something non-obvious
Name to use for Blackboard: Project_yourName

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, TextAdventure.java. 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 AdventureModel.java 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.