ITEC 120 2007fall ibarland, jdymacek

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

hw13
gRUe pt. IV

All parts due 2007.Nov.30 (Fri) 17:00. You only need turn in files which have changed since your hw13.

1. Declare and initialize a plausible “so-far” (accumulator) variable for a loop which...
   1. counts the number of space characters in a String
   2. determines whether or not a String contains any newline characters.
   3. finds the heaviest Treasure in a non-empty list of Treasures ts.
2. What lines does the following print out?
   (Hint: walk through the code by hand, keeping track of what each variable is.)

   int ssf = 0; for ( int i=2; i < 10; i = i+3 ) { ssf = ssf + i; System.out.println( "i=" + i + "; ssf = " + ssf ); }

3. The following loop is probably not at all what the author intended, for several reasons. What lines does the following print out?

   int ssf = 0; int i = 0; for ( int i = 2; i < 10; i = i+3 ) { int ssf = 0; ssf = ssf + i; System.out.println( "i=" + i + "; ssf=" + ssf ); i = i + 3; }

4. For this and the following problems, assume that deadlines is of type java.util.LinkedList<Date>, and refers to a non-empty list.

   Date mysterySoFar = deadlines.get(0); int i = 0; while (i < deadlines.size() ) { Date d = deadlines.get(i); if (d.comesBefore(mysterySoFar)) { mysterySoFar = d; } i = i+1; }

   1. Suppose that deadlines contained four Dates in the following order: new Date( 2007, 1, 1), new Date( 2008, 1, 15), new Date( 1988, 9, 10), new Date( 2008, 1, 15). After the loop runs, what will mysterySoFar be equals to?

   2. In general, what does the loop compute? (4-5 words of English.) What would be a more descriptive name for mysterySoFar?

   3. Rewrite the fragment to use a for-each loop.

   4. Rewrite the fragment to use a for loop.
5. Write a loop which computes 1³+2³+3³+...+1000³.
   You can use any sort of loop, although a for loop is particularly natural when counting 1...1000. (This is simpler than computing the number of oranges in any sort of pyramid.)
6. Use a for loop to write the following function.

   /** Return a String concatenated to itself mutliple times. * @param n the number of copies to make. * @param word the String to copy. * @param a String containing `n` copies of `word`. * Examples: * Linguistics.stringTimes( 3, "ho" ) = "hohoho" * Linguistics.stringTimes( 1, "unary" ) = "unary" * Linguistics.stringTimes( 0, "turkey" ) =                  * Linguistics.stringTimes( 4, "" ) =                  */ public static String stringTimes( int n, String word ) { }

   You can use any sort of loop, although a for loop is particularly natural when counting 1...n.
   Hint, for figuring out your accumulator variable: If somebody calls stringTimes( 1000, "hi" ), what partial result will you have built up after going through the loop 500 times? (It should be the same type as the final answer you're trying to compute!) How will you update that value the 501st time through?

parts (b),(c)

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. Note that each method below requires 2-5 lines of code, no more.

1. Write a method explore, which calls exploreOnce repeatedly, until a command like “quit” is entered.

   Note: Clearly, exploreOnce will know when the user has indicated they want to stop. But how will explore know that? Easy -- modify exploreOnce so that it returns this bit of information, and explore uses that returned value. (Do not create an entire field, just to have one method communicate with another; fields are meant to hold state about an Explorer, whereas parameters and return values are the way methods pass information back and forth.)

   Hint : Ask yourself the usual questions:

   • What “so-far” variable are we keeping track of?
     A: It's an unusually tiny bit of info: simply, whether or not the player wants to continue exploring.¹
   • Declare a local variable to hold this so-far value. What is its initial value, before we ever enter the loop?
   • As we go through the loop one more time, how will we update our so-far variable?

   No test cases or drawings are needed for this method, as it is solely interactive.

2. 

   Update Rooms so that they have one more field, which holds all the adjacent Rooms (zero or more).

   Newly-created Rooms will have no other adjacent Rooms.

   Complete the provided picture, showing what things look like if there are four Rooms A,B,C,D such that:

   • A is connected to B and C (already drawn for you),
   • B is connected to C,
   • C is connected to B,
   and
   • D is connected to no other Rooms.
   (Note how we don't know what fields are inside a LinkedList, so our drawing acknowledges this vagueness. Also, this drawing actually shows that Strings are objects, something we usually gloss over in drawings.)

   Your test case will make a brand new Room, and be sure that it has initially no neighbors. There are different ways of doing this; two that spring to mind are:

   // If you write your own static test-driver method, you might include: Room roomA = new Room( /* ... details omitted */ ) System.out.println( "roomA should have 0 neighbors: " + roomA.getAdjacents().size() );

   or

   // If you use a unit-test case, you can manually add a test case: assertEquals( 0, roomA.getAdjacents().size() ); // (Presuming roomA was one of the rooms declared in the test-fixture.)

   Of course, the exact names of your fields and/or getters might be different.

   Caution:

   Important: your Room's toString method, when processing the list of adjacent rooms, should not call toString of any of its adjacent rooms. (This includes not call the list's default toString, since the LinkeList's toString is programmed to call the toString of everything inside the list.)

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

   Instead: A Rooms toString might well mention the names of all its neighboring rooms, just not its neighbor's neighbors.

3. Add a Room method connectTo (use that exact name!), which takes one input (the adjacent Room to connect to), and adds that Room to the list of adjacent Rooms.

   What changes in your drawing above correspond to roomD.connectTo(roomC)? (Either make a whole new “after” drawing, or add to it using a different color of ink.)
   Hint: the number of changes in your drawing will correspond to the number of lines of code this method will require.

   A plausible test case would assert that (after calling roomD.connectTo(roomC)) it's the case that roomD.getAdjacents().contains(roomC) is true, but roomC.getAdjacents().contains(roomD) and roomC.getAdjacents().contains(roomB) are false. Note that we're using the List method “contains”.

   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?)

4. Add a method biconnectTo (use that exact name, please), which makes a two-way connection between Rooms.

   Draw a picture of what things look like after calling roomD.biconnectTo(roomB). ² Write reasonable test-method.

   Don't repeat code (duh).
   Hint: Remember, this is an ordinary local-variable which you can use just like any other local-variable/parameter. (The only thing special about this is how java automatically declares and initializes it for you in every (non-static) method.)

   After this code, it is possible to move from roomD to roomB and back.

5. 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. (Think to yourself: Should this method be static?)

   // 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 before you write the code, and that after you write the code you will run your test cases before proceeding; you know all that by now.)

   Of course, we can use local variables to name sub-results of this one line, if it helps:

   Room curr = this.getCurrentRoom(); java.util.LinkedList<Room> nhbrs = curr.getNeighbors(); Room dest = nhbrs.get(i); this.setCurrentRoom( dest );

6. Update your exploreOnce method to allow somebody playing your game to move the explorer to different Rooms. (Hint: in hw12, you've already written and tested a version of select which takes a list of Rooms.
7. 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 method called something like setupRoomConnections, which creates several additional Rooms, and makes connects between them. (Think to yourself: Should this method be static?) Then, when somebody makes an explorer, be sure to³ setupRoomConnections, so that the new Explorer has somewhere to go!
8. In preparation for the next step, we'll make two small changes to our Room.java. You don't need to make test cases for these.
   1. Make a Room constructor which takes only two arguments (a name and description -- but no Treasure). It creates a new Room holding no Treasures, naturally enough.
   2. Optional: modify your three-argument Room constructor to call your two-argument constructor, yielding something along the lines of

      Room( String _name, String _description, Treasure _t ) { this( _name, _description ); // One constructor calls another. this.treasures.add(_t); }

      This way we retain a single point of control for initializing a Room's name and description. Note how “this(…)” is a new form of syntax, different from other method calls or constructor calls.
   3. Write a Room method addItem(Treasure), which inserts another Treasure into the Room.
      Update your drop method(s) to use this method.
   Why did we make these changes? So that when creating Rooms from the wiki, it's possible to create rooms without Treasures, and also to add a whole bunch of Treasures to a Room (without needing some Explorer to drop anything).

9. Finally, write a method which lets you explore using the rooms from the Wiki. Use the provided class Entry (slightly modified Nov.28 17:15, to give a better error message when a wiki entry has a Treasure with a non-numeric weight).

   See the comments at the start of Entry.java, but the gist is simple: You'll call a Entry.buildWorld, which returns a Room (which presumably has connections to other Room/s). Entry.buildWorld actually calls methods you've written:

   • the constructor Treasure(String, String, double, String)
   • the constructor Room(String,String),
   • The Room method addItem(Treasure)
   • The Room method connectTo(Room)
   • The Room method biconnectTo(Room)
   If your signature for any of these methods differs from what Entry.java expects, you'll have to fix one or the other so they match.

   It's worth realizing that by providing just these five methods, your code is interoperable with code written by somebody else entirely, regardless of what fields you have and how you implement your methods.

   You might find that there are errors on the wiki page, where people's items don't exactly follow the wiki instructions, and therefore the provided code can't parse the wiki. Fix the wiki page as needed.

   You shouldn't need to make any changes to Entry.java, but you are welcome to. Note that you have learned enough to understand everything that file does, with the exception of using a particular class (java.util.Map), which you'll learn about if you take ITEC220. In fact, everything you need to know about about Map is explained in comments inside the method Entry.buildWorld.

extra credit: standalone program

hw-ec05 is due 2007.Dec.07 (Fri) 17:00, the last day of classes.
Note: Some of the following may actually become part of hw14, rather than extra credit. (Particularly, the first three or four items.)

• Add some rooms and connections to the wiki, http://ru-itec120.pbwiki.com/grue-data-2007fall (password: “highlander”). Instructions are on that wiki page; be sure to follow the instructions exactly.

  Specify connections only from your Rooms (to anywhere), and from the nexus to (at least one of) your Rooms.

• We want our friends to be able to run this program, just by double-clicking on an icon. This involves two steps:

  1. Modify your program to use the provided GuiIO class, instead of TextIO ⁴.

     This should require changing only two words of your program (change your declaration and initialization of your TextIO object to just use the type “GuiIO” instead). We carefully made sure that GuiIO has methods named display, promptForString, etc., so it can be easily swapped in -- “Plug'n'Play”. This explains why calling display was equivalent to calling System.out.println, but that layer of indirection has bought us flexibility.

     This means that if you didn't follow the instructions on hw10, and you had your Explorer read/write the console/keyboard directly (without going through TextIO, then you have to go back and fix that in order to get your program to work.

  2. We need a static method to get everyting going: create a method public static void main( String[] args ) which creates an Explorer and starts it exploring.
     Note that your main method will ignore its parameter, the array-of-Strings.⁵
  3. From the BlueJ project window, choose Create Jar File..., and then when it lets you specify the Main Class, choose Explorer. You can leave the other options unchecked. (Eclipse has a similar way to create jar files.)

• Allow Explorers to carry any number of Treasures, instead of exactly two.

  You'll find that this actually makes several methods of your code shorter and simpler. (There is no more need for Lint, nor code which specific to the right pocket followed by essentially-repeated code deadling with the left pocket.)
  A hallmark of good design is that not only does it make the program more flexible, it simultaneously makes the code simpler.

• Make passageways their own object, with their own names and descriptions. Thus you might just see that a room has "stairs going up" and "a teleport chamber"; not until an Explorer moves into the passage will they find out where it leads.

• Add chests, which require a key to be opened.

  One simple way is to have “red chest” be openable if the if the Explorer happens to contain “red key” in their inventory.

  Alternately, each chest might require some specific object to open (using ==). Note that this object might happen to be called “a chocolate egg”, and players might not know that it is also a key!

• Make things appear differently, when certain tasks are completed.

  For example, you might have it so that whenever an Explorer enters a certain room ("drawbridge control center"), it adds a new connection is created somewhere else in the world.

  Alternately, each explorer might have a list of accomplishments; certain connections (or treasures) are displayed only to explorers who have certain accomplishments.

• Figure out how to play sounds in Java. Have each Room have its own sound file.

• Allow multiple explorers (each with their own TextIO) who take turns exploring. (Each explorer might be off in their own different room entirely.) Let explorers who are in the same room interact.

  (This would be a precursor to actually running your program in a distributed fashion -- with most of the program running on a server computer, but with TextIO or GuiIOs which are running each on a different client. Because we have divided the problem up effectively -- Rooms, Explorers, and IO are all different classes -- this might require some fancy networking to get started, but most of our code would be unchanged.)

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

©2007, Ian Barland, Radford University Last modified 2007.Dec.14 (Fri)

Please mail any suggestions (incl. typos, broken links) to iba�rlandrad�ford.edu