Purposes of this assignment:

• Give you more practice with Swing GUIs
• Give you more practice with the structure of OOP programs

General idea of the 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.

Most adventure games use commands of two or more words. We're going to use a GUI.

Details:

The game itself:

An adventure game consists of:

• An AdventureGame 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.
    
    
• A Model 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.
    
    
• 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.
  • A description, to be shown when the adventurer "looks" at it.
  • A "use" method, 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; at least two of the objects should have some "use" relevant to the game. Each partner should do some rooms and some objects. 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.

The GUI:

You also need to write a Swing GUI to allow a person to play the game. Although there is only one GUI, I would like each partner to write all the code (creating the components, laying them out, attaching listeners) for part of the GUI. For that reason, I'm dividing the GUI up into four "areas" (where each area is a JPanel), as follows:

• One partner should write:
  • The "room" JPanel, which displays:
    • The name of the room.
    • The long description of the room.
    • Where each "exit" (North, etc.) leads, if anywhere.
  • The "things in the room" JPanel, which has:
    • A list of things in the room (could be in the "room" area instead, if desired).
    • A JComboBox, for choosing a particular thing in the room. (You will have to add things to and remove things from this JComboBox, as appropriate).
    • A JButton for looking at the selected thing.
    • A JButton for picking up the selected thing (and adding it to the adventurer's inventory).
• The other partner should write:
  • The "adventurer" JPanel, which has:
    • A JComboBox, for choosing a particular thing from the inventory. (You will have to add things to and remove things from this JComboBox, as appropriate).
    • A JButton for looking at the selected inventory item.
    • A JButton for "using" the selected inventory item.
    • A JButton for dropping the selected inventory item (goes into the room)
    • Four JButtons, for moving to the north, south, east, or west. Buttons should be disabled if the adventurer can't go that way. You may have buttons for other directions (for example, up or northwest), as needed by your game.
  • The "results" JTextArea, which displays the result of the adventurer's most recent action (looking at something, picking something up, using something, or dropping something--but not moving, which will change the "room" display).

The above division of the GUI is suggested, not required. You can rearrange things as necessary to create a good-looking GUI, but each partner should do all the work for a JComboBox, some JButtons, and a text component.

• Do JUnit testing on the basic commands (look, take, drop, use, go).
• Javadoc comments are required on all non-private variables and methods. Do them correctly!
• Estimate the time you will spend on the program, and keep track of how much time you actually do spend. Add this information (for each of you separately) to the readme.txt file.

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.

I am providing a sample game, McGame.zip. This is a very simple game where the main class (McGame) uses the classes and methods of the game, and does all the (text-only) input/output; the game does not "know" who is calling it. However, McGame is not perfectly designed; the McGame class does all the room creation and setup, etc., and this should be done in a model class. Ideally, the main class should be general enough to play any text adventure game, without knowing any of the details of the game.

Notes:

In the last assignment (Battleship II) you had to switch between two GUIs. This assignment is somewhat simpler, since you have only a single GUI, and the structure of that GUI doesn't change. You will be enabling and disabling buttons, putting things into and removing things from combo boxes, and writing text, but you lay out the components once and don't change them.

In this assignment, the user talks to the program by clicking buttons, choosing items from a combo box, etc., but never has to type anything. The program responds by displaying text in text components. It doesn't display pictures, only text.

Due date:

Thursday, November 15, 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.