Computer Science 15-100 (APEA Section E), Summer 2008
Homework 6
Due:  Tue 29-Jul-2008 at 5:30pm (online submission and physical copy)
(no late submissions accepted).

• Be sure to include your name, your Andrew ID, and your section clearly on the top of each file in your assignment.
• Name your programs and your methods exactly as indicated.
  • You will have exactly one program:
    1. Tetris.java -- this will contain all the questions
• Use well-named variables, proper indenting, reasonable commenting, etc.  Do not use magic numbers!
• Provide complete (but concise) test cases!
• Provide the UI exactly as indicated.  File-based UI should not include prompts.
• Submit printed solutions in your recitation.  Your printed solutions must be identical copies of your emailed solutions!

1. Write Tetris.
   Note:  We did this in class (twice now!), completely, starting from a blank compiler.  You are advised, though not required, to follow our design from class.  In particular, you may start from PreTetrisConnect4.java, which we wrote in class, and which demonstrates many important preliminary concepts for Tetris, including:  creating JFrames (windows); using a custom component; using mouse, keyboard, and timer events; using instance variables; and using 2d arrays.
   
   Grading
   
   C-Level: Falling pieces, left/right/down keys, space key, a timer, all 7 different shapes, and stacking.
   
   B-Level: C-Level plus score, an end of game, and removal of full lines.
   
   A-Level: B-Level plus rotation of blocks (and other assorted niceties to be defined by you -- be sure to include a clear description of these in a comment at the top of your file, to be sure you get credit where it is due!).
   
   Also: Style is worth 10% of the overall grade.  See below for more details.
   
   5-pts bonus: correctly implement the rotation of blocks about the midpoint instead of the end.
   
   Extra 10 points bonus: To the #1 overall Tetris program submitted, as determined by whoever I can convince to be a judge of such things.
   
   Style

   Here is a non-exhaustive list of style issues you should deal with:

   * Use top-down design, writing well-chosen helper methods where appropriate.

   * Do not duplicate code.

   * Use test methods and test particularly for boundary cases.  For Tetris, it would be easy to do this.  For example, set up a piece by hand, make it rotate, then confirm that the resultant piece matches expectations.  Or, set up a board manually (I’d suggest making the board smaller than the 22x10 used in the “real” game), and call the various doLeft, doRight, etc, methods, confirming after each one that the piece’s resultant location is correct.  In any case, you must test, test, test your code!

   * Use appropriate instance vs. local variables.  Instance variables should be limited to those variables that must be instance variables because their values simply must persist beyond a method call.  The classic example:  setting instance variables in response to timer, keyboard, and mouse events so that the ensuing paint methods can refer to them.

   * Use well-named variables, methods, and classes.  Besides the obvious (eg, someone named a variable “rowCount” even though it had nothing to do with counting rows – bad name!), it is also true that smaller details matter.  For example, class names should all start with an Uppercase letter and variable and method names should not.

   * Use proper indenting and spacing.  No triple-spaced lines (double-spaced at most, and then sparsely).  Single space after “if”, “for”, “while” and before the parenthesis.  Single space after closing parenthesis and ensuing the left-brace.  Etc.

   * Use reasonable commenting.  Not too much, not too little.  Comment anything that may be confusing or unexpected to an experienced programmer reading your code for the first time.  Do not overcomment.  Be brief and to the point.

   * Do not use magic numbers!  Our safe rule-of-thumb:  any number except -2, -1, 0, +1, +2 belongs in a well-named variable.  As we discussed in class, there are some reasonable exceptions to this rule, but to be safe, you can always follow the rule strictly and you’ll be fine. 

   There are more style rules we have discussed, but these cover most of the bases.

Carpe diem!