Implementing a text adventure game

In this program assignment, you will be inventing and implementing a text adventure game. You will be working with a number of classes, many of which will be subclasses of existing classes provided for you in the student.jar library. You will also be working with interfaces. Adventure games have been around for a long time, dating back to the Colossal Cave Adventure, (see Colossal Cave Adventure page (Links to an external site.), or DG Jerz's Colossal Cave Adventure page (Links to an external site.)), but there is more to the history of adventure gaming than this initial spark. In particular, Infocom (Links to an external site.) was famous as a computer game producer who made text (and later, graphic) adventure games. Zork, their oldest adventure game, is considered by many to be the most famous of all text adventures, or "interactive fiction games". You can even download and play (Links to an external site.) Zork I, II, and III. There is even an on-line PHP version (Links to an external site.) of Zork you can play in your web browser. You can also read the definitive history of Zork (Links to an external site.), or read its entry in Wikipedia (Links to an external site.). This assignment offers you a large amount of creative freedom, so do not hesitate to have fun with it!

Learning Objectives
Exposure to object-oriented dispatch
Familiarity with interfaces
Familiarity with creating subclasses
Familiarity with overriding methods
Familiarity with polymorphism
Familiarity with using library classes
Inventing Your Game
First, you should decide what the goal of your game is. It should be something along the lines of: You have to find some items and take them to a certain room (or a certain person?). Then you can get another item. If you take that to another room, you win. Build on your own puzzles using your creativity.

For example: You are a grad student in CS5044 at Virginia Tech. You have to find out the secret of the Hokie Bird. To do this, you have to track down the current student in the Hokie Bird costume. He will provide you some hints about the location of the Hokie Bird treasure and others who might be able to help you. You will need to talk to others for clues about the location, items you will need and trials to overcome to get the treasure. If you get to the treasure room in time, and you have found items you need somewhere along the way, and you have also enlisted the aid of people like Frank Beamer to help you, then you have a chance to win the final battle with the guardian of the treasure. Or: You are lost in a dungeon. You meet a troll. If you find something to eat that you can give to the troll, then the troll tells you where to find a magic wand. If you use the magic wand in the big cave, the exit opens, you get out and win.

It can be anything, really. Think about the scenery you want to use (a dungeon, a city, a building, a local park, an historic site) and decide what your locations (rooms) are. Make it interesting, but don't make it too complicated (we suggest no more than one or two dozen rooms.) Put objects in the scenery, maybe people, monsters, things that can be picked up or things that are stationary. Decide what task(s) the player has to master.

Support Classes Provided by Virginia Tech
Just as in the Tetris assignment, you have a number of support classes available that will help in constructing an adventure game. These classes are all located in the student.adventure package, which is already provided in the student.jar file you've already been using (be sure to add it to your project, as with earlier assignments).

The are four main classes for creating adventure games in the package student.adventure:

Game represents the main class of a game. It sets the game up, and then enters a loop to read and execute player commands. Note that Game is an abstract class: that means you cannot create an object of this class directly, because some of its methods have not been given definitions. Instead, you must create your own subclass (that extends Game) that defines the missing pieces.
Player represents the person playing the game. The student.adventure.Player class provides minimal features. However, you can create/extend your own custom subclass of Player that adds any new features you wish.
Room represents a location in the game. The student.adventure.Room class provides minimal features. However, you can create/extend your own custom subclass of Room that adds any new features you wish.
Command is an interface that defines the common properties of all command objects. In particular, it requires every command object to implement an execute() method. There are three classes that implement this interface that are also provided for you in the student.adventure package: GoCommand, HelpCommand, and QuitCommand. You can use these three commands, and create any new ones you like.
These four classes (well, three classes and one interface) are the aspects of the student.adventure package that you will use most often. You will probably need to create your own subclasses of each one at some point, although you can work toward a solution incrementally. Study their javadoc documentation (Links to an external site.) on the course web site well so that you understand what their methods do. In addition, the student.adventure package contains two other classes to help you implement a game:

CommandWords represents a dictionary of known commands in a game. This class uses a Map (Links to an external site.) to associate words with Command objects. This makes it easy to add new commands without affecting the structure of this class.
Parser reads command lines and breaks them up into words, looking the command word up using a CommandWords object. The parser implemented here understands one- and two-word input lines, where a one-word command is a verb (like "quit"), and a two-word command is a verb followed by an object (like "go east" or "take wand").
Requirements
You will need to extend several classes to implement a base level of required features in your game. Your game implementation must do the following:

Include your own custom subclass of Game.
Include your own custom subclass of Player.
Include your own custom subclass of Room.
Include a variety of locations/rooms (a minimum of 10).
It must be possible for a player to reach each of the locations/rooms.
You must extend the basic game to support items. Each item should initially be located in some room. Every room can hold any number of items. Some items can be picked up by the player, others cannot. The player can carry some items with him or her. Every item has a weight. The player can carry items only up to a certain total weight.
Your game must support the commands take and drop for manipulating items, and inventory (abbreviation: i) for listing out the items currently being carried by the player.
The player can win. There has to be some situation that is recognized as the end of the game where the player is informed that he/she has won.
In addition to the "go" command (which is already implemented for you in the GoCommand class), you must also support the following one-word movement commands: north, south, east, west, up, and down, together with one-letter abbreviations for each: n, s, e, w, u, d. Note: you can support all of these with a single command class, so you will loose points if you use six (or twelve!).
Implement a command back that takes you back to the last room you've been in.
In addition to the commands provided in the student.adventure package and the additional commands explicitly required in this list, add at least four new commands of your own devising. Beyond these basic requirements, you are free to explore any other game features you wish to provide. Feel free to take advantage of this flexibility to have fun while you complete the assignment.