Radford University ITEC

ITEC120-ibarland (incl. office hrs)—info—lectures—labs—hws

hw06:
gRUe, pt. II

Due Nov.12 (Mon)13 (Tue) 17:00 (but still, try to complete it over the weekend)

(Orange text is clarification added after the first release of the homework.) Solution to part I (.jar), to use as you will.

We continue our work on the Grand Repository of Underground Entertainment (gRUe), adding Rooms for the the explorer to interact with. Before starting on this homework, make a backup copy of hour hw05!

For part II, we will develop one new class, and modify some of our Explorer methods.:
As usual, include javadoc code for each class. Write these comments before writing the actual code; the comments will help you focus on what the method does. PIs have been instructed to not help you on a method, if you don't have those comments already written.
Similarly, if you are requesting help on a method, and don't have all other already-written methods called and tested from your test method, you must do that before receiving later help.

  1. A Room has a name and a description, and (for now) one initial Treasure item. Some examples might be:
    name: Davis 225 lab
    description: This room is dark, the only light coming from an eerie screen saver.
    item: A computer

    name: Mt. Everest, west ascent.
    description: The sun shines bright on the glacier above you.
    item: A chocolate egg.
    1. create a class with these attributes. (Note that the 'item' will be an instance of class Treasure.)
    2. write a constructor which takes the required information as parameters. (You will pass it in an already-created Treasure as the third parameter.)
    3. write a toString method for Rooms.
    4. write a static method testRoom which creates several Room instances, and prints them to the console window with system.out.println (make two examples, different from the ones shown above.) For every further Room method you write, add some tests to this method.
    5. Our game will need one distinguished room, which Players will start in. Make a named constant1 variable STARTING_ROOM, and initialize it with some Room.
  2. Now that we have Rooms, we can have a place for explorers to hang out in!
    1. go back to class Explorer, and add a field for the Explorer's current Room. Your constructor should intialize that field to Room.STARTING_ROOM. Update your javadoc comments and your testExplorer method accordingly.

      Should this field be static? That is, if you have ten different Explorers, do they all have identically the same notion of their current Room?

    2. Many things a player does will depend on which Room they are currently in. Write a getter function for the Explorer's Room.
    3. Write a Player method look(), which returns the name and description of the current room, along with its treasure. Keep in mind that in future versions of gRUe, the Explorer will be wandering from Room to Room (even though we haven't yet added that feature); be sure to have look() describe whatever Room they are currently in, so that your code will still work great the moment we change their current Room.
    4. Modify the dropLeft(), dropRight() methods so that the dropped Treasure gets placed in the Room.
      Update your javadoc comments accordingly. (Leave grab() unchanged, for now.)
    At this point, you should be able to run a session similar to the following, in BlueJ's code pad2 
    Explorer me = new Explorer( "Dora" );
Treasure jc = new Treasure( "Jolt Cola", "An unopened 2liter bottle", 4.4 );
me.grab(jc)
"You have picked up a Jolt Cola."

me.inventory()
"You are carrying:
left pocket: a Jolt Cola -- An unopened 2liter bottle
right pocket: lint -- a little fluffy ball"
me.look()
"Davis 225 lab:
This room is dark, the only light coming from an eerie screen saver.
There is a computer3."
me.dropRight()
"You drop a Jolt Cola."
me.look()
"Davis 225 lab:
This room is dark, the only light coming from an eerie screen saver.
There is a Jolt Cola."
    (Note how the Room's computer has disappeared.) (The above text is just a guideline, though you should include at least the same rough amount of information, and at least as human-readable.)
  3. Once you have that working, modify Room so that it contains not just one Treasure, but a list of Treasures!
    1. Change the Room's field from type Treasure to type ArrayList<Treasure>.
    2. For backwards compatability, we still want to let people call the constructor which accepts exactly one Treasure. Keeping that Room signature (interface) the same, modify the code (implementation) so that the one given Treasure is the sole initial Treasure. [Optional: Write a second constructor which takes an ArrayList<Treasure> as a third input. More optional: after reading about variable argument lists in Chapter 7, and ArrayList's addAll method, allow the constructor to take two String arguments followed by 0 or more Treasures!] (Test this, before proceeding.)
    3. Change any other Room methods as needed. (For example, you may want to tweak toString, and you might want the list of a Room's Treasures to print as suggested in lab12(Wed.). ) (Test this, before proceeding.)
  4. Now we can go back to class Player, and fix up its interaction with a Room's Treasures:
    1. Modify Player's dropLeft and dropRight methods so that the dropped item is added to the Room's list of Treasures. (Test this, before proceeding.)
    2. Let's update grab so that it can (try to) take any of the items in the current Room, and when an item has been successfully grabbed then it is no longer in the Room's list of Treasures. More precisely:
      • This version of grab will take an int: an index into the list of items in the Room.
        (Keep the old version around, and overload it with this version taking an int.)
      • If that int is not a valid index, then this method returns "I don't know what (item) you're talking about".
      • Otherwise, the Explorer tries to pick up the indicated item. If they succeed the Treasure is removed from the Room. (See the ArrayList method remove(int).) Whether or not they succeed, a String message is returned just like before.
      (It's difficult to re-use our previous version to get this augmented version. Don't worry much about trying to avoid repeated code. We'll see in the next part, things will be much easier once we get rid of the left-pocket right-pocket distinction.)

    Once you have this working, the above Code Pad example should be similar, except that items won't disappear — dropping a bottle of cola leaves the room with both a computer and a cola. We might continue: 

    me.dropLeft()
"You have dropped a lint."
me.dropLeft()
"You have dropped a lint."
me.look()
"Davis 225 lab:
This room is dark, the only light coming from an eerie screen saver.
There is [a computer, a Jolt Cola, a lint, a lint]."
me.grab(0)
"You have grabbed a computer."4
me.look();
"Davis 225 lab:
This room is dark, the only light coming from an eerie screen saver.
There is [a Jolt Cola, a lint, a lint]."
    It doesn't matter where in the list new items are added, and don't worry too much about making your messages perfectly grammatical. (For instance, if there are no Treasures in the Room, then look() might return a message like "There is [].". You may also wish to write a nice list-printing function as worked on in lab.) Don't make the messages excessively long though — looking about the room should mention the name of items, but not their full description. (If you like, you can write a method Player.examine(int), which returns the full description of the with the given index.) You are certainly welcome to make your messages nicer, but that's not required for the grade, as long as the right Treasures are listed.

    Also, making the eerie light disappear once the computer has been grabbed requires a much more sophisticated program; we won't do that this semester! You might enjoy pondering how to let items affect the room description, though…

1That is, a static final variable.      back

2Remember that in the Code Pad, you don't want to include a semicolon when making a method call whose result you want to see, like grab and look. But, you must include a semicolon for assignment statements, since they return no result.      back

3If you have grab drop a lint, then lint will have replaced the computer.      back

4If you have grab drop a lint, then there will be an additional lint lying on the floor.      back

ITEC120-ibarland (incl. office hrs)—info—lectures—labs—hws

©2006, Ian Barland, Radford University
Last modified 2006.Nov.15 (Wed)		 Please mail any suggestions
(incl. typos, broken links)
to ibarlandradford.edu		 Powered by PLT Scheme