home—info—exams—lectures—labs—hws
Recipe—Laws—lies—syntax—java.lang docs—java.util docs
hw08
hw08
Rooms to explore
Due Apr.09 (Mon) 17:00
Will be accepted until Apr.11 (Wed) 17:00, w/o late penalty.
5pts extra-credit for having it done by Monday.
But the late penalty still starts counting from Monday eve -- so not
accepted after Apr.12 (Thu) 17:00.
We continue our work
on our Explorer/Treasure program, to be
a Grand Repository of Underground Entertainment (gRUe).
This week, we add Rooms for the explorers to interact with.
Before starting on this homework,
make a backup copy of hour hw06!
In this part we will develop one new class, and modify some of
our Explorer methods.
As usual, include javadoc code and test cases for each class.
Write these before writing the actual code;
they 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 and test cases 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.
-
A Room has a name and a description, and
one initial Treasure item.
Two examples of rooms would 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.
- create a class with these three attributes.
(Note that the 'item' field will be an instance of class Treasure.)
- write a constructor which takes the required information
as parameters.
(You will pass it in an already-created Treasure
as the third parameter.)
-
Before proceeding, make several test cases:
several Room objects.
(You don't have to make exactly the examples above,
but realize that before creating a Room object, you'll need to have
a Treasure to place in it.)
- Write a public toString method for Rooms,
which only returns the Room's name.
Write a method toDetailedString,
which returns a message describing
the Room's name, description, and
the contained Treasure's toString1
- Our game will want one special Room object,
which all new
PlayerExplorers will start in.
Make a named constant
STARTING_ROOM,
and initialize it with some particular Room.
(This is a static2 field.)
-
(Optional, but will count for towards participation points:)
See http://ru-itec120.pbwiki.com/grue-data-2007spring (password: “highlander”). Read the instructions closely, and then edit the wiki page and add at least two Rooms to that page.
-
(Optional, but will help you test your other methods, especially later:)
Write a Room method boolean contains(Treasure t).
- Now that we have Rooms, we can have a place for
explorers to hang out in!
- Go back to class Explorer, and add a field
which holds (a reference to) the Explorer's current Room.
Your constructor should intialize that field to the one designated constant
Room.STARTING_ROOM.
Update your javadoc comments
method
accordingly.
To think about:
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?
And if an Explorer
later moves to a different Room,
how will our program represent that?
(Can you draw a picture of the objects involved, before-and-after?)
- Many things a player does will depend on which Room they
are currently in. Write a getter function for the Explorer's Room.
- Write a
PlayerExplorer method look(),
which returns the detailed listing of the Explorer's current room.
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 the Explorer's
current-room, which might someday be different than the starting-room.
-
Modify the
dropLeft(),
dropRight()
methods
so that the dropped Treasure is 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 pad3
Explorer me = new Explorer( "Dora" );
Treasure jc = new Treasure( "Jolt Cola", "An unopened 2liter bottle", 4.4 );
me.grab(jc)
"You drop a lint. You pick 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 lint4."
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."
|
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.
-
Once you have that working,
modify Room
so that it contains not just one Treasure,
but a list of Treasures!
- Change the Room's field from type Treasure
to type LinkedList<Treasure>.
- 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.
- Change any other Room methods as needed.
Test this, before proceeding.
)
For instance, if you wrote the
Room method boolean contains(Treasure t),
the signature stays same but you need to re-write the body.
- Extra credit:
Write a second constructor which takes
an entire LinkedList<Treasure> as a third input.
Take care that your room includes all the treasures in the list,
but that the Room's list itself is not ==
to the list passed in.
(After all, suppose somebody maintained a list of the
most-valuable Treasures in the game,
and passed that list to a Room constructor.
At that moment the room would be made, full of the best goodies.
If, later, an Explorer picks up something from that room,
we don't want to be modifying the original list of most-valuable
Treasures!
Include a some test cases to verify this isn't happening in your program.)
-
More extra credit:
after reading about variable argument lists in Chapter ???,
and the addAll method of LinkedList,
allow the constructor to take two String
arguments followed by 0 or more Treasures
arguments.
- Now we can go back to class
PlayerExplorer, and
fix up its interaction with a Room's Treasures:
- Modify
PlayerExplorer's
dropLeft and dropRight methods
so that the dropped item is added to the Room's list of
Treasures.
(Test this, before proceeding.)
- 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 Linkedlist 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."5
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 PlayerExplorer.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…
1I
recommend going back to class Treasure and having its
public toString() method return just the Treasure's
name. ↩
2Be sure to make this field static.
If it is a regular field, then you are saying that every Room contains
a Room inside of it; but of course that Room
would then (by your definition) also contain a Room,
which would contain …. If you mistakenly do this,
BlueJ will make about 1000 recursive calls before spewing out
a bunch of red lines saying “stack overflow”.
↩
3Remember 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. ↩
4If you don't have grab drop a lint,
then the room will still contain a computer. ↩
5If you have grab drop a lint, then there will be an additional lint lying on the floor. ↩
home—info—exams—lectures—labs—hws
Recipe—Laws—lies—syntax—java.lang docs—java.util docs
rad�ford.edu