hw10
gRUe pt. IV: conclusion

Due Dec.08 (Fri) 17:00; accepted late only unti midnight

The last essential step to our Grand Repository of Underground Entertainment (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 unit-tests for Room.

You may use the hw09-soln if you want (in part or whole; Apr.25 15:00 An if statement added to the select methods, so that they don't loop forever on an empty list).

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.
alert:
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: use the names and perhaps descriptions of the neighboring rooms; your roomListToString already does this.

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,

  /** A static test method for Room.
   *  (See comments below, for how to make a unit test for this, rather
   *  a static method which prints to the console and you look over the 
   *  output yourself.
   */
  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() );

    /* If you do this as a unit-test method instead of a static method,
     * then you won't use System.out.println,
     * and instead you will type something like  roomA.getNhbrs().contains(roomB)
     * in the code pad; then you can go into the khaki-green unit-test class,
     * see that line, and assertequals false before making the connection, and true after.
     */
    }

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: you've already written and tested selectRoom from hw09.)
You already have created some other rooms as test cases, on the bench. But we'll want to have some Rooms which exist when we're running our program (playing the game), and not just testing. To this end, write a static method called something like setupRoomConnections, which creates several additional Rooms, and makes connects between them. Then, when somebody makes an explorer, be sure to ² setupRoomConnections, so that the new Explorer has somewhere to go!
The more Rooms (and Treasures) there are, the better. Contribute two rooms to the class database See http://ru-itec120.pbwiki.com/grue-data-2007spring (password: “highlander”). Exact details and examples are on the wiki. Encouraged: specify some connections between rooms, too, on the wiki.. Be sure to follow those instructions exactly, so that other people can write programs using the wiki.

Provided is a class which will open the wiki page and a file and create Room instances from it. It won't be required for you to include this code inside your own program, but it should require minimal work, if you have used the constructors exactly as described.

¹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. ↩

² 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. If you want to make sure this method isn't performed twice, you can make a static boolean haveAlreadyInitializedRoomConnections, and use that to make sure that the method doesn't re-initialize things. (A more appropriate solution is to read about static initialization blocks.) ↩

home—info—exams—lectures—labs—hws
Recipe—Laws—lies—syntax—java.lang docs—java.util docs

©2007, Ian Barland, Radford University
Last modified 2007.Aug.27 (Mon) Please mail any suggestions
(incl. typos, broken links)
to iba�rlandrad�ford.edu

hw10gRUe pt. IV: conclusion

Due Dec.08 (Fri) 17:00; accepted late only unti midnight

hw10
gRUe pt. IV: conclusion