Lab 5: Designing a class hierarchy

The goal of this lab is gain experience designing the relationships among classes. This will also give you experience in working on a group project.

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

The first thing to do is to organize into five groups (of three students each). I'll assign you a number N, so that your group will be groupN.

To check out the code, substitute your group for groupN, and do

hg clone ssh://hg@cshg/245s13/groupN

That will make a directory with your group name, with a subdirectory game. (If you use eclipse, use the groupN directory.)

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

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 additional specificiations, too) next week.

5. Extra tips

Sharing via Mercurial

To share changes with your teammates, you need to

1. Commit the changes to the repository. To do that,
   • Do hg status to check where you are.
   • If needed, hg add filename to tell Mercurial about files that you have added.
   • Use hg commit -m "log message" to commit your changes to your local repository.
2. Use hg push to push your commits to the shared repository.
3. Your teammates can then use hg pull to pull your commits to their repositories, followed by hg update to show those changes in their working copy.

Very simple merging

1. Use hg pull to pull the other changes into your repository.
2. Use hg merge to incorporate those changes into your working copy.
3. As the merge command reminds you, don't forget to commit. So do that as described above.
4. After you've committed, don't forget to push the changes so that your teammates can pull them.

Your merge command will complain if the changes you have made to a file overlap. I'll add instructions for dealing with that...

Printing code

a2ps -2 --file-align=virtual filenames

• -2 print two pages per sheet
• --file-align=virtual don't insert any blank pages between files