Due Wednesday, October 7th, 2009 at 11:00am.
In this homework you will work on expanding the functionality of the Adventure game that we started in HW2.
In the previous homework assignment, you were instructed to create a simple text-based adventure game essentially from scratch. This assignment builds on Homework 2, quite literally in fact. For this assignment, you will be given a fully working Adventure Game solution. Your task will be to incorporate additional functionality into the framework that is provided.
In order to make the game playable, we will add functionality to characters to let them take textual commands from users. We will record a global history of every 'command' that has occurred. Then we will add a 'look' command that lets players see descriptions of rooms in more detail. Last, we will add two new types of Characters: a Tagger that can add graffiti to the floor of rooms and a Janitor that can then clean rooms up.
The maximum score for this assignment is 100 points.
To ensure that inheritance is used well in your code (and nothing is implemented more than once), 10 of the points the automatic Tester will give you will depend on how short your code is. It does this by counting the number of "tokens" in your file, where a token is either a symbol like { or a string of letters and numbers like thisIsAReallyLongNameForAnInt.
Remember that identifiers are counted as one symbol, no matter how long they are, and comments and white space are not counted. So, for example,
int x = 5;
x++;
System.out.println(x);
int thisIsAReallyLongNameForAnInt = 5;
thisIsAReallyLongNameForAnInt++;
System.out.println(thisIsAReallyLongNameForAnInt);
int x = 5; x++; System.out.println(x);
all have the same number of tokens. So there is no need to obfuscate your code (by writing everything with one-letter names or putting everything on one line) to get a good score for conciseness.
The tester will tell you how many tokens your code has when you run it.
The first thing you want is make sure you have Eclipse installed on your computer, as described in this week's lab notes. Once you've got eclipse up and running, create a new Java Project (in the File menu). Then, you want to download hw3.jar and add it to the project, by right-clicking on the project and choosing (Properties-->Java Build Path--> Libraries-->Add External Jar).
You will also want to
import Tester.java, GameRunner.java
and Controllable.java. The easiest
way to do this is to save the files into the
directory workspace/HW3/src/ (assuming that you named
your Java project "HW3"); then right-click on the HW3 project in the
Package view, and select "Refresh" (or just highlight the HW3
project and hit F5). You can also save the files anywhere you like,
then right-click on the src directory under your HW3
project, and select Import... > General > File System. Then
click "Browse..." to navigate to the directory where you saved the
.java files, click OK, put a tick mark next to each file you want to
import, and click "Finish" to import the files into your project.
As before, there are several ways to test your code.
Make sure hw3.jar and your code are in the same directory. Navigate to this directory in your console, and type:
java -cp .:hw3.jar Tester
java -cp .;hw3.jar Tester
You should see the test script's output in the terminal window. (Of course, it will tell you almost all the tests are failing at the moment!)
Once you've imported Tester.java, press the Green "Play" button or use the menu (Run-->Run) to run the Tester. If prompted, run the tester as a Java Application. If asked to select between several classes with main methods, select Tester.java (default package).
In the event that Tester.java does not appear when you attempt to run your code, go to (Run-->Run Configurations) from the menu. Right-click on Java Application to the left, and select New. Name this run configuration "Tester", and make sure the Project is set to your current project and your Main class is Tester. Then try to 'run' again, selecting Tester as your Run Configuration if prompted.
After running the tester, the Console (available as a tab on the bottom, as in Dr. Java) should display the output of the Tester.
Though Eclipse does not have an equivalent for Dr. Java's Interactions pane, it is possible to test your code outside of the Automatic Tester. To do so, make sure you've imported GameRunner.java and try to 'Run' it the same way that you ran the Tester; that is:
Try to play around with the Game; it doesn't have very much functionality yet, but once you start adding commands, GameRunner will be a great way to simulate the Interactions Pane and test out your code.
Open up the GameRunner class within Eclipse: you will notice it is fairly short and consists of two methods. The first is a main method which we have written for you, which interacts with the console and repeatedly asks the player for instructions and then responds with the current status of the game (don't worry if this isn't clear before you finish question 1). The second is the setupEnvironment method, which currently sets up a very small testing environment (two rooms and a single item) and a Character (tagger) who will represent the player in the game.
Feel free to change the setupEnvironment method to your liking, building as elaborate or useful Adventure Maze as will be necessary for your testing. You will not need to submit the setupEnvironment method; it will not count against you when accounting for length.
Using the GameRunner.java interface to test your code/play the game is optional but recommended (and fun).
When you wish to debug your code and add breakpoints (as in the lab), you may need to set up Debugging Configurations. These are identical in form to the Run Configurations, but are accessed through the menu in (Run-->Debug Configurations) or through the Debug button. This is the button to the left of Run, that looks like a bug.
It should be possible to debug both the results of your code as they are tested by the Automatic Tester and as they are run through the GameDriver.
In HW2, if we had a Character named Bob and we wanted Bob to move north, we would type something akin to bob.move("north") into the interactions pane. This worked OK within Dr.Java, but is not the type of game that could be shipped and sold (even on an iPhone).
A real user interface is needed, which is what we will be working with in Question 1. Specifically, we will be able to implement a textual interface that lets users of AdventureGame interact with the game via the console, giving the characters textual commands and receiving textual responses.
For this purpose, we will use the Controllable interface which Characters will be able to implement in order to translate text commands from the user into actual methods that the characters can then invoke.
The Controllable interface (which is provided for download here) is very short. In fact, this is it:
public interface Controllable{
public String command(String commandName, String commandParam);
}
Classes that implement Controllable must contain a command method that takes two arguments:
String commandName,String commandParam,The command method returns a String describing the result of the command, or a String starting with "Error:" describing the problem, if the command was not executed successfully (IE, tried to move in a non-existant direction could return "Error: I don't know how to move there").
Yiour task in this question is to create a new character type named Tagger (the name Tagger will become clear in Problem 4). Tagger should implement the Controllable interface and be able to execute commands.
Note: If we had access to the source for Character.java, it would also be possible to open Character.java, add implements Controllable to the Character definition, and then implement the command method there. For this homework, however, any modifications to the work done in HW2 are not allowed (though we can still use all of the HW2 classes and methods from the provided jar file).
Specifically: Tagger should be able to take the following text commands:
See the Command Guide for the standard way the commands should respond for a successful outcome. Don't worry about the other commands list for now.
Tagger also requires a constructor, taking String name as the first parameter and a Room location as the second. This would also be a good time to take a look at the provided javadocs for reference.
Once Tagger is implemented, GameRunner should be able to respond to commands. This will look something like:
> move north Bob moves deftly into Kitchen >drop laptop laptop falls to the floor > move upstairs Error: no such exit available.
What is an adventure without a tale? Problem 2 adds a class AdventureLog, whose purpose will be to record all the results of Characters' commands. AdventureLog stores the return of the every command method and, when asked for, returns everything that's happened so far.
AdventureLog has three methods:
addLine(String result)history()clearLog()You should also look at the AdventureLog JavaDocs for detailed method summaries.
Once AdventureLog is implemented, make sure that the result of any successful command inside your AdventureGame is stored within the log.
To make the games one could create in AdventureGame more powerful, a more expansive list of possible commands is necessary. Problem 3 revolves around the implementation of the look command, which lets Characters make a more detailed examination of the room they are in.
Unfortunately, the existing Room class does not permit the storage of description at multiple detail levels. To solve this, we will create a DescriptiveRoom class which will store both a short and a long description.
Key methods of DescriptiveRoom include
public DescriptiveRoom(String description, String longDescription)public String getLongDescription()Now that we have initialized rooms with something to look at, we need to add a look for Character to use. A look command would, in the game, look something like this:
>look
Wizard sees a great hall filled with light. The hall is eerily empty. A dark entry-way appears in the north corner of the room.
>move north
Wizard moves deftly into Kitchen
>look
Wizard sees Dirty pots fill the sinks and drawers. The Kitchen is dark and smells foul. A large doorway to the south leads to a bright hall.
The implementation of look should be straightforward, with a few caveats:
It's time to see why Tagger is actually called Tagger. In Problem 4, we add a tag command that taggers can use to change the description of a DescriptiveRoom (but not a normal Room). The room's
| Command | Format of Reply | Value of Parameter |
| pickup | John leans over and picks up peach | name of object to pick up |
| drop | peach falls to the floor | name of object to drop |
| move | John moves deftly into Restroom | direction of exit |
| look | John sees a beautiful night sky, covered in stars | none |
| tag | John writes "bite me" on the floor of the room | text of message |
| look (when tagged) | John sees a room tagged: bite me No thank you |
none |
| scrub | John cleaned up the room; now it looks good as new | none |