ITEC120-ibarland (incl. office hrs)—info—lectures—labs—hws—java.lang docs—java.util docs

hw-ec-grue:
gRUe

Due Dec.15 (Fri) 17:00 — no late submissions accepted.
Submit on WebCT, and slide the hard copy under my door if I'm not around.

There are oh-so-many ways to add on to the gRUe program we've written. The problems here aren't as fully specified as a usual homework; you'll need to use your own initiative and common-sense on how to best organize your code. You can do any of the following you like; you don't need to do them in order. If there is a sub-task which you can describe in a few English words, you should write them as auxilliary “helper” functions, which get called from your overall function.

Before starting on any of these complete all of hw08, and be sure to copy your hw08 to a new project.

Scoring: All Extra credit points from this sheet will be added to your lowest homework score. That is, if your lowest homework score is 23/40, you can get up to³ 17pts of extra credit from this assignment. These are separate from arrays extra credit option. Also, note that the points listed below assume you do a good job on the entire task.
Recall that extra-credit points are graded more demandingly than regular points; be sure to include javadoc, test cases, good variable names and comments, etc..

• (?? pts) Integrate this code to your project, which reads a database file (as on the wiki), and calls your code to actually make Rooms etc. from it.
  You will need to read the documentation for that class; the comments guide you on how to integrate it into your own program, but it will take you some puzzling out.
• (10pts) Modify Explorers so that they carry a backpack full of Treasures, rather than just two pockets. (You'll find this actually makes your code simpler as well as making it more general — the sign of good design.)

• (20pts) Our program, as it stands, doesn't distinguish between adjacent rooms, and passages to adjacent rooms. That is, you might see that Davis-225 has two adjacent Rooms -- “Davis-200 hallway” and “Sidewalk outside Stuart”. It would be more interesting if explorers had to commit to a destination without quite knowing where it led: that is, a room might have two exits “a door in the northeast corner” and “a sunny window along the west wall”.

  Add a class Passage, which has a description and a destination.

• (40pts for the first two points below) Our command-handling is one place to improve. Currently we have about six commands, and already our explore method is getting kind of long. What if we want 20 commands, or 100 commands?

  1. Make class Command, and have a (static) list of all possible Commands. This one list will get used for the “help” instructions. as well as actual command processing.

  2. In fact, the long list of if (cmd.equals("inventory")) … else if … can be avoided: inside each Command object, contain a method perform, which contains the actual code for that Command. That is, you'll have an abstract class Command, along with a class InventoryCommand extends Command; the String perform(Explorer e) method will be overridden in each such subclass. (And oddly, there will only need to be one instance of InventoryCommand.) This will result in may files, but each one is just a few lines long.

     This is called “the command pattern”. It is be used when you want to pass a function as an input into another function, which is really what we're doing here.

  3. (Optional) If you read about “anonymous inner classes”, you can actually avoid a separate file for each Command.
  4. Other possible extensions to command-handling: While doing the above, further allow multiple strings to all represent the same command. (That is, “inventory” and “items” might both list an explorer's items; “help” and “?” might both invoke the help command; “bye”, “quit”, “exit” and “sayonara” might all exit the program.)

• (20pts) Improve the select interface by allowing users to either type in the number of a choice, or the name of a choice. That is, “grab rainbow” would be a valid input, rather than something like “grab 3”.

  Better yet, allow abbreviations to be any prefix which is unambiguous (that is, “grab rai”, as long as there is no “raisin” sitting next to the rainbow).

  (You might make a method which takes a list of Describables and a command-prefix; return a list of all describables whose name is compatible with that command-prefix, and re-prompt the user using that smaller list.)

  What will you do if a number could refer to either a numbered-choice, or the name of a choice? (There are several reasonable answers; the important part is to think about and document it.)

• (20pts) Add a picture to every room. Every room will have a field (say) “pictureURL” or “pictureFileName”; whenever a room is entered, that picture is displayed in a pop-up window.

  This will require some effort on your part: You'll need to look on the web for (hopefully) a couple of lines of code which can take a URL or filename, and figure out how to display the picture. Once you have that, then start grue-specific tasks of adding it as a field to a room, calling that code at the right time, etc. You will probably want to have some way of indicating rooms which do not have a valid picture associated with them.
  (You might want to encourage people to include image entries, in the wiki.)

• (30pts) As the previous step for pictures, but using sound instead.
• (5-10pts, or 40pts for a general solution) Add keys, which are needed to pass through specific doors/passages (or similarly, certain items which are needed to enter certain rooms: you can't enter computer lab if you don't have the Treasure “ID-card”, etc. Alternately, you can have doors which ask you riddles, to pass through them.
  Messy, hard-to-modify code won't be worth many points on this one. For a general solution, good documentation is essential. This is a hard one.
• (40pts)

  Add triggers specific to (say) entering a room. For example: When an explorer enters the kitchen, then if they are carrying a flashlight, then the room's description changes (and certain treasures are added to the room, which weren't there before).

  One approach to this would be a big unwieldy if-else-if statement in the code for entering a Room. Yech, what an organizational nightmare. Another possibility would be to use the Command pattern as alluded to above: there is a class TriggerAction with a single method, performTrigger which does nothing interesting. Every Room might contain a TriggerAction object, and when a Room is entered, the perform method will be always be called (which usually does nothing extra). However, you can make a subclasses TurnOnLights extends TriggerAction, whose performTrigger checks whether an Explorer's inventory contains a flashlight, and if so it will then add Treasures to the Room. Then, make one new instance of TurnOnLights, and that's the particular TriggerAction object which will be sitting inside the kitchen object.

  This approach lets you add triggers bit by bit, without having to hard-code hundreds of specific cases into the entering-a-room code.

• (10-40pts, depending) Include monsters or people, which can/must be fought or talked with.
• Right now, you might have several different Explorers who are all wandering through your Rooms simultaneously. Yet, we don't have any support for interaction between players. (We can't even see any other Explorers in the same Room.) Think up what sort of interactions between players you want to add, and add them. Then, change your game to include 2 (or more) new Explorers. There are two overall approaches which must be taken:
  • Turn-based (20pts): Add top-level driver, which loops through all the current Explorers, calling their explore method in order (and, the explore method will process only one command, rather than looping forever.⁴ getting one action from each in order. (Note that each Explorer will still have their own IO access; in fact, some players might be using TextIOs while others are using GuiIOs.)
  • (40pts) Asynchronous: To truly support multiple players doing their actions asynchronously would take reading about threads, and synchronzed access to shared lists.
    This option requires a lot of work and a lot of concepts we haven't covered. I don't recommend doing this, but if you do clear this with me before you spend time working on it!
• (??pts. But see me before investing too many hours!)
  Any other addition you like! Be sure to document and test it. (I shouldn't have to look at your code to figure out what new features it has; I should only need to read the javadoc comments.)

ITEC120-ibarland (incl. office hrs)—info—lectures—labs—hws—java.lang docs—java.util docs

©2006, Ian Barland, Radford University Last modified 2006.Dec.09 (Sat)

Please mail any suggestions (incl. typos, broken links) to ibarlandradford.edu