Lab 5: Designing a class hierarchy

The main goal of this lab is to gain experience designing the relationships among classes. This will also give you experience in working on a group project, which will involve using a revision control system (in our case, Mercurial). Furthermore, in this project you will begin to see how various things we have been talking about in class are applied, including polymorphism and encapsulation; Java Collections classes like ArrayList, HashMap, and HashSet; and class extension (subclassing).

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. Making this text-based gives it a element of retro-charm.

The code for the game we will work on is very flexible 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 as a group, but each of you in the group will be working on a different part.

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

hg clone ssh://hg@cshg/cs245s15/groupX

Where X is the number of your group (eg, group1, group2, etc).

The code is in a folder/package called game. Make a new Eclipse project (emember, make the project to be in the folder containing the package folder game.) You may find it easier to run the program from the command line than through Eclipse. From the folder containing the game folder, run it with

java game.PlayGame

That is, the class PlayGame has the main method. 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. In each turn

• a description of the current room is displayed
• the user is prompted
• 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 require 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.
  
  
• Modify the code so that rooms can give the option of moving in various directions other than "north", "south", etc. --- for example, up, down, northwest... 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.
  
  

3. Process

The first thing you must each do is read this lab description (which, presumably you have done, if you have gotten this far). Then you will confer together and assign tasks to everyone.

Next you will take some time to think through what you need to do for your task and plan and design. You should do this in conjunction with whomever is working on tasks that affect or are affected by your task.

Once you have planned out your changes and considered how it will affect other parts of the program, begin to implement. In order to test, you will have to integrate your work using Mercurial.

4. To turn in

Work until lab time is finished. Ideally by the end of lab, your group will have done all four tasks at least to some extent, will have integrated your changes, and will have a working version. At any rate, we will resume working on this (with new specifications, too) next week.