Purposes of this assignment:

• Introduce you to 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 just going to use buttons.

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.
• 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.

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," as follows:

• One partner should write:
  • The "room" area, 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" area, 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
    • 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" area, which has:
    • A JComboBox, for choosing a particular thing from the inventory
    • 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.
  • The "results" area, 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 absolutely 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.

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.jar. 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. (Note: you can execute the game by double-clicking it, or you can change the name to McGame.zip and unpack it.)

Last-minute additions:

No JUnit tests are required for this assignment.

As always,

• Javadoc comments are required on all non-private variables and methods.
• Estimate the time you will spend on the program, and keep track of how much time you actually do spend.

When you turn in your program, include a readme.txt file to tell us how to play your game to a successful completion.

Due date:

Thursday, November 16, before midnight.