ITEC 120 2007spring ibarland, jpittges

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

hw09
hw09
gRUe Input/Output

Due Apr.16 (Mon)18 (Wed) 17:00
(but accepted by start of class Thu, due to the tragedy at Tech)

1. Copy your hw08 to a new project, to work on this homework. (Or, you may also use the posted hw08 solution (.jar) (coming Saturday eve); be sure to modify the comments in each file to include your name, as well as cite the original author, briefly mentioning which author wrote what.)
2. Make sure your Treasure and Room classes have the methods getName and getDescription, using precisely those method-names. (You may already have used these names, in which case you're set.) Also, be sure that Explorer uses exactly the command-names “look”, “grab”, (and unless you have done the extra credit backpack) “dropLeft”, “dropRight”.
3. Write the method treasureListToString, which takes in a LinkedList<Treasure> and returns a String of the following form:

   (1) a small nugget -- Upon close inspection, the nugget glints of gold! (2) a fancy pen -- This pen can write in purple, green, and plaid. (3) chocolate egg -- The size of an ostrich egg, but made entirely of dark chocolate.

   Note that if there are three items in the list, there will be three newline characters in the result.
   (Should this method be static? What class should it live in?)
4. Write roomListToString, which behaves analogously to treasureListToString. (That is, it takes in a LinkedList<Room>.)
   (You are allowed to mutter under your breath, about the practically-repeated code. Not until we mention interfaces and/or inheritance, in the last week of class, will we be able to rid ourselves of this repetition.)

5. We will write a class TextIO, which will help communicate between the gRUe world, and somebody playing the game.

   lack of automated tests:: Because there is no return value, there is nothing to assertEquals, in unit tests, so you don't need to turn in any unit tests for TextIO methods. (However, it's possible to still make unit tests which read input from a fixed String, and you can inspect the terminal window manually.)

   1. A TextIO instance will have one private field (with no getters or setters): a Scanner, which it uses to read all its input from.
      1. Make a constructor which takes no arguments. this version will use a Scanner created from System.in (the keyboard).
         The TextIO objects you make with this constructor are great for using interactively, but aren't helpful for testing (since every time you (re)run a test, you'll have to type at the keyboard).
      2. Make a second (overloaded) constructor, which takes one argument — the Scanner this TextIO will read from.
         This variant will be very handy for testing -- you can make a new TextIO( new Scanner( "here are 7 words of test input" ) ), and then test the methods below without having to type input from the keyboard every time.¹
   2. Write the following method, for TextIO:

      /** Display game info to the player. * @param msg The message to display. */ void display( String msg )

   3. Write the following method, for TextIO:

      /** Print a message to the screen, and get a response. * @param msg A message to print to the screen, * for example "What month is your birthday? ". * @return The response -- just one word, which is taken * from this TextIO's internal Scanner. (If that Scanner happens * to be reading from System.in, then this function is getting * an answer interactively.) */ String prompt( String msg );

   4. Write the following method, for TextIO:

      /** Have the user select an item from a list. * @param instruction A message describing what is being selected, e.g. "Choose your favorite treasure:" * @param items The list of Treasures to have the user choose from. The list will not be modified. * @return an index into items, or the sentinel value -1, for no-choice-made. * (The -1 might indicate that the user entered an invalid choice, or * maybe the changed their mind and cancelled the selecting.) * The input is taken from the scanner. */ int select( String instruction, LinkedList<Treasure> items )

      A helpful partial outline of select which you may want to include (but don't have to), which reads an input, and makes sure it's a number. This assumes that this object's internal Scanner is named “in”. (It is possible do write this so that it calls prompt, but you don't need to.)

      if (!in.hasNextInt()) { // We reach this if a non-number was entered. // We call in.next(), which clears that non-number from the input stream. System.out.println( "I don't understand \"" + in.next() + "\"." ); // ...do something?... } else { // We have a number: read it, and... answer = in.nextInt(); // ...check whether 'answer' is a valid index, perhaps printing // a message if it isn't. }

      Return -1 to represent “nothing selected after all”. Do not return anything other than a valid index, or -1. Anybody calling this method will need to specially check for a return value of -1.
   5. Write another version of select which takes a LinkedList<Room>.

6. Now for the fun part: We want to have the user give commands interactively. Write a method which prompts the player for a String, and runs an appropriate command. It should do this repeatedly, until the user types quit.

   More precisely: write a method explore inside of class Explorer. This method will

   1. make a new TextIO, and
   2. Repeatedly:
      • prompt for a command, and
      • call the appropriate Explorer function. (It may need to first have the user select a particular Treasure from the current Room, in the case of “grab”.) Your loop will presumably include code along the lines of:

        if (actionToDo.equals("look")) { myIO.display( this.look() ); } else if (actionToDo.equals("grab")) { /* ... now have the user select one of the treasures in the * room, and then call this.grab(...), passing it * the selected treasure. */ } else if (actionToDo.equals(…)

        (You don't need to follow the above code precisely, but it gives you a flavor of how to do it. The variables used in this snippet are only suggestive names; you'll need to figure out exactly what types of variables you need, and how to get values for them.)

   Once you get your program to accept input like “look” and “grab”, extend your if-else-if statement to let the user type in other commands: “drop-left”, “drop-right”, “inventory”. You might want to add a command “help”, which prints out all the (other) valid commands. Note that the similarity between what the user types (“look”) and the name of your method “look” is quasi-coincidental; in general they don't have to be the same at all.

   After getting this method working, you can have your friends play your gRUe program, just reading the console window and typing text into that window. (They won't type anything into BlueJ's code pad.) The game will look similar to the sample dialogues from on previous homeworks. Admittedly, the game won't be very interesting, until we add connections between Rooms

   This method should only communicate with the user via methods in IO; this method must not call System.out.println directly.

For fun: Later, we will provide a class GuiIO, which has exactly these same methods, but gets its answers in different ways. But your gRUe program should run equally well if you use the GuiIO in place of the TextIO. That is why your explore method doesn't interact directly with the keyboard or screen: I can write an entirely different interface, which can interact entirely with your Explorer methods!

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