Computer Science APEA 15-100, Summer 2009
Homework 13
Due:  Mon 27-Jul-2009 at 11pm (email copy only)
(no late submissions accepted).

Read these instructions first!

• Now you are not given a file to start from!  Based on previous hw's, create your own Hw13.java file.  Be sure to name it exactly correctly, to include a main method that calls checkAssertsAreEnabled and testAll, and to have testAll call suitable test methods for all the methods you create.  Also, be sure that every method you write has exactly the right name and the right signature.
   
• Be sure to include your name, your Andrew ID, and your section clearly on the top of each file in your assignment.
   
• For non-programming problems:
  • Place all your solutions to the non-programming problems in a single file named Hw13 (with whatever extension is appropriate for the format you choose, such as Hw13.txt or Hw13.html, etc).  You must use one of these file formats: plain text (txt), or RTF, or HTML, or Word (doc, not docx), or PDF.  No other file formats will be accepted.
  • Show your work.  Correct answers without supporting calculations will not receive full credit.
     
• For programming problems:
  • Try to use well-named variables, proper indenting, reasonable commenting, etc.
  • Note:  You may use any/all Java concepts now!
     
• What to submit
  • Create a submission directory like this:  "koz-hw13"  (replace "koz" with your andrew id)
  • Place all the files you are submitting in that directory, zip that directory, and submit the zipped directory
     
• How to submit
  • Send an email with the zipped submission directory as an attachment to your CA by the submission deadline.  Do not miss the deadline, even by one minute!  Email problems are not a valid excuse for late submissions.
  • It is recommended that you "cc" yourself in that email, too, just to confirm that you properly sent the email.
     
• Note:
  • Improper submissions will be penalized up to 10 points and may be rejected.
  • Late submissions will be rejected.

1. Reading
2. AdventureDemo Reflections
3. AdventureDemo Improvements (Your Own Text Adventure)

1. Reading
   Finish reading Chapter 4 carefully (though you may just skim the portion on graphics and GUI's). Note that the next quiz will cover Chapter 4 (and then some!).  Be sure you have completed this reading assignment by then!
    
2. AdventureDemo Reflections
   Do this question under lab conditions (that is, you may collaborate in small groups).  You must work alone on the other questions in this assignment!
   Answer (in plain English, not in Java code!) the following questions regarding the AdventureDemo and related classes we wrote in class (see AdventureDemo.java).  Your answers should be very brief and to-the-point.
   1. Why did we name a class Thing and not Object?
   2. Why is it a problem for a noun in our game to have a space in its name?  What challenge would this present, given the simple way we wrote the program?
   3. What is an ArrayList?
   4. Explain how the next 2 lines are similar and how they are different:
         Thing[] a = new Thing[10];
      and
         ArrayList<Thing> a = new ArrayList<Thing>();
   5. How do you get the length of a String?  Of an ArrayList? Of a 1-d array?   Of the outer-dimension ("rows") of a 2d array?  Of the inner dimension ("cols") of a 2d array?
   6. What is the API (public methods) of the Adventure class?
   7. Why does doCommand use split?  How else might it accomplish the same task (just describe, don't actually write the code)?
   8. What does this expression accomplish in the doCommand method?
          (cmdWords.length < 2 ? "" : cmdWords[1])
      What would go wrong if we omitted it?
   9. Why is everything in the Dir class static?
   10. Why did we number the directions (NORTH, SOUTH, ...) starting from 0?  This helped us in more than one way...
   11. And why did we include a constant, DIRS, which is the total number of directions?
   12. What does "final" mean in the declaration of the directions (NORTH, SOUTH,...)?  What could happen if we did not declare these to be final, and why would that be a bad thing?
   13. Why does the Dir class include an array of Strings, the dirNames?  (It is used in two similar, but different, situations.)
   14. The getDir method in the Dir class uses toLowerCase.  Why?
   15. The getDir method in the Dir class also uses the "equals" method.  Say we used "==" instead of "equals" there.  Would the code compile?  Would it run correctly?  What, precisely, would happen (from the user's experience)?
   16. Why don't we have a mutator in the Thing class?
   17. Why did we use an ArrayList for the "things" in the Room class?
   18. Why did we not use an ArrayList for the "exits" in the Room class?
   19. We returned an ArrayList<Thing> in the getThings method of the Room class.  This is actually dangerous, because it allows the caller to modify (or "mutate") that list, adding or removing Things without our game's knowledge!  Suggest (but do not implement) a way around this (say, by not having a getThings method, but instead having two methods that together accomplish the same result, but without returning the entire ArrayList).
   20. Which of the following are used by our program?  In each case, be sure to understand why each variable/method is public/private, final/mutable, and class/instance:
       1. public instance variables
       2. private instance variables
       3. public class ("static") variables
       4. private class ("static" variables
       5. final instance variables
       6. final class variables
       7. public constructors
       8. private constructors
       9. public instance methods
       10. private instance methods
       11. public class ("static") methods
       12. private class ("static" methods
            
3. AdventureDemo Improvements (Your Own Text Adventure)
   Copy the file AdventureDemo.java to the file Hw13AdventureDemo.java, then in that file add the following extensions or improvements to the code:
   1. Standard Extensions
      1. Add a "drop" method, with "put" as an alias for the same command, which allows the user to put down a thing that has been picked up.  The thing should then reside in the current room.  Of course, if the user is not carrying the thing, a helpful message should instead be printed.
          
      2. Add "immobility" to things, so that some things cannot be picked up with the "get" command. You will want to add an instance variable to the Thing class to help implement this.  Include some things that are mobile and some that are immobile, and print a helpful message if the user tries to get an immobile object.
          
      3. Add a "door", which opens somehow (you decide how).  When the door is opened, you should modify each adjoining room's exits to include the other, thus allowing the user to pass through the open door.  The door should be close-able, in which case you should remove the rooms from each other's exits.
          
   2. Custom Extensions
      Now you should write your own text adventure by extending the one we wrote together.  You do not have much time for this, so keep your story very simple.  But there should be a story or a problem to solve.  Basically, there should be a way to win and a way to lose, and winning should require at least a few steps in a specific order (that is, a problem to solve).  Again, though, keep it simple.  The point here is for you to understand the mechanics of writing a simple text adventure and not to actually write a full-scale (or even half-scale) working game.
      
      You must include at least 3 new rooms, 3 new things, 3 new verbs, and 2 new properties (like "immobility" of things).  Try to make it challenging and fun but doable.

Carpe diem!