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

gRUe pt. IV: conclusion

Due Dec.08 (Fri) 17:00; standard 3-day late policy

The last essential step to gRUe will be to add connections between rooms. Every room will be connected to zero or more other Rooms; connections can be one-way. (That is, you might be able to get from room A to room B, but not back.)

Before proceeding, you'll need to have at least 3-4 Rooms already created in your test-code for Room.

We already have a class which represents an individual Room; what is a data type which can represent “0 or more Rooms”? Add a field to class Room, to hold the 0-or-more-adjacent-Rooms.
Newly-created Rooms will have no other adjacent Rooms.
(After adding this field, and updating toString as needed, re-run your Room-test-method, and make sure the field is there.
Important: your toString method, when processing the list of adjacent rooms, should not call the toString of any of its adjacent rooms. (This means, don't call the list's default toString.)

Why not? Because if roomA has roomB as a neighbor and in turn roomB has roomA as a neighbor, then printing would be infinite: roomA.toString() would attempt to make a string using (in part) roomB.toString(), but roomB.toString() would attempt to make a string using (in part) roomA.toString(), but roomA.toString() would attempt… you get the picture. Java will report “Stack overflow”.

Instead: just print out (say) the names of the adjacent rooms, or call describablesToString giving it the list of adjacent rooms.

Add a Room method connect, which takes one input (the adjacent Room to connect to), and adds that Room to the list of adjacent Rooms. That is,

  /** Test driver for Room.
   */
  static void testRoom() {
    //... make rooms roomA,roomB,roomC

    System.out.println( "Adding a connection from " + roomA.getName() + " to " + roomB.getName() + ":" );
    roomA.connect(roomB);
    System.out.println( roomA.toString() );
    System.out.println( roomB.toString() );
    System.out.println( roomC.toString() );
    }

After the above code, it is possible to get from roomA to roomB (but not back to roomA). Write some more test cases for the method, then write the method, and then test your code before proceeding. (You should include more than just this one test. What happens if you have a room connected to itself? Can you have one room which connects to several others?)

Add a method ¹ biconnect, which makes a two-way connection. Hint: This body of this method should consist of exactly two lines — it only needs to make two connections

    System.out.println( "Adding a *two-way* connection between " + roomA.getName() + " and " + roomC.getName() + ":" );
    roomA.biconnect(roomC);
    System.out.println( roomA.toString() );
    System.out.println( roomB.toString() );
    System.out.println( roomC.toString() );

After this code, it is possible to move from roomA to roomC and back. Write at least one more test case, then write this method, and then test your method before proceeding, as always.

Add a Explorer method moveTo. The method takes an int, looks up which adjacent-room indexed by that int, and changes the Explorer's current-room room to be the new room.

// Suppose that e1 is an Explorer whose current Room is roomA,
// and that roomA has two neighboring rooms (roomB and roomC,
//    with indices 0 and 1 respectively).
e1.moveTo(1);
// Now, e1's current room should be roomC.

This method will be similar, in some ways, to grab. It should return a String, with a message somehow indicating that the room has changed.
(I'm going to stop saying that you should write your test cases first, and that you should test before proceeding, since you know that by now.)

Finally, update your explore method to allow somebody playing your game to move the explorer to different Rooms. (Hint: if Room implements Describable, then you already have code that lets the user select a neighboring Room.)
The game can't be fun if there aren't many rooms to explore or many treasures to collect. You'll need to contribute two rooms-or-treasures to a class database. See http://ru-itec120.pbwiki.com/grue-data-2006fall (password: “highlander”).
If you contribute five (or more) rooms/treasures/connetions to the database, this will contribute a bit towards your class-participation grade.
I'll provide some code which (if you download the database) will open a file and create Room instances from it. (It won't be required for you to put this code inside your own program, but it will be worth some extra-credit.)
Optional, but easy and obvious:
As alluded to in #2, you'll have created at least 3-4 other rooms as test cases, with some connetions between them. Write a static method setupRoomConnections, which makes sure you can move from the Room.STARTING_ROOM to other places. (This is just a subset of your room-testing method, so it should be easy.) Then, when somebody makes an explorer, be sure to ² setupRoomConnections.

¹You can make this a static method, if you prefer. The rationale against a regular method is that the two rooms are equally important, so it seems odd to have roomA be considered the “primary” instance, and roomC is a the subsidary input to the action being performed on roomA. For comparison, in the one-way connect method, the asymmetry between the two Rooms is perfectly natural. back

² If you later have multiple explorers occurring, then you'd want to take precautions not to call this room-setup method twice, but that's not an issue for this assignment. back

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