Lab 5: Designing a class heirarchy

The goal of this lab is gain experience desiging the relationships among classes.

1. Introduction and set-up

In this lab we initiate a running example that will come up in future lectures and labs: An "adventure"-style computer game. The central element of this kind of game is that it takes place in a world composed of locations (which we will call "rooms", even though it's possible that these locations could be interpreted as being outside) among which the user moves. In these rooms the user's character can find and use items, interact with other characters, and move to a different room. The object of the game might be to find something, rescue someone, or escape a cave or dungeon. Games like this are often text-based, but they don't have to be.

The code for the game we will work on is very flexbile and (if designed well) extensible. It can be used to play games with a wide variety of scenarios, maps, and objectives. You will be working on it together as a class, but you will each be working on a different part.

Make a new directory for this lab and checkout the code.

svn checkout file:///homeemp/tvandrun/svn/245/lab5

The game software is in working order and can be played. However, right now the game is pretty lame. It consists of four rooms (each described only as "a room"), laid out as a 2-by-2 grid, with each room connected to its two adjacent rooms (not to the diagonal room). It also is a pretty annoying game since there is no object and no way for the game to end. However, playing the game (compile and run the PlayGame class) will give you a feel for the basic setup. In each turn

• a description of the current room is displayed
• the user is promted
• the user's command is interpreted

2. Your task

Your first task is to inspect the code to see how it is set up. It is extremely simple.

Then confer with each other and assign to each person at least one of the following modifications to be made.

• Add the concept of an item. An item is something that is found in a room (a key, a weapon, food...) and possibly can be picked up by a user, carried around, and used. Design this in such a way that it is easy to add new kinds of items and so that kinds of items that have things in common can share code. Note that this will requiring changing other things so that a room can contain an item and so that a user can carry an item around.
  
  
• Add commands that the game understands. Obvious additions are "help" (give a list of commands) and "look" (list the exits of the room, and/or items). Design this in such a way that it is easy to add new commands, and for some commands to be room-, item-, or game- specific. Hint: Adding things to the if-else block in Parser.executeTerm() will not make this easy.
  
  
• Add so that some rooms also give the option of going up or down (if these rooms are in a multi-level building). Note that this will affect the list of commands. Design this is such a way that it is easy later to add new kinds of rooms that give various options of movement. Hint: Adding a new instance variable to Room.java for every new movement option will not make this easy.
  
  
• When the game is being built, if two rooms are adjacent to each other, one must call a setDirection() method on both rooms; see the constructor of Game. Modify this so that this is unified with one method call (for example, something like pairWestEast(room[1], room[2])). Design this in such a way that it will be easy later to add a feature that will allow a special one-way door between rooms.
  
  
• Add a kind of room or door that will transport the user to a random room in the game. Note that the way Game is set up now, this is very hard. It's better to change Game so that this (and future) changes are easy, rather than doing it the hard way.
  
  
• The Room methods setNorth() etc may be called any time, which means that the map could change mid-game. Modify this so that once a map has been built, it cannot be changed. Note that we can't simply get rid of the setter methods and require that the adjacent rooms be passed to the constructor, since two rooms can't be instantiated at the same time. Design this is such a way that it will be easy later to make a special type of room whose doors can change mid-game.
  
  
• Add three more games/maps-- be creative in thinking up some scenarios. Design this in such a way that it is easy to add new games later. Either the map can be chosen randomly, or different main classes can be written to choose which game to play. Hint: Doing the whole maze construction in the constructor of Game will not make future changes easy.

In deciding who should do what, you should also decide what task to leave for our absent swimmer. Discribe her assignment (and any other information that should be passed on to other people modifying your code) in the file TODO.

3. To turn in

Commit your final changes to subversion.