Lab 4: 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 in groups of three or four, but each of you in the group will be working on a different part. The groups are

• Group A (or "1"): Lily, John Charles, and David.
• Group B (or "2"): Daniel, Kendall, Suzanne, and Michael

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

svn checkout file:///cslab.all/ubuntu/cs245/reposA/game

or

svn checkout file:///cslab.all/ubuntu/cs245/reposB/game

depending on whether you are in group A or B.

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

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