CSE 373 Winter 2005 (DRAFT -- files not available)

Homework #3B

Towers Game (II)

Files  Turn-in form   Mixmatcher tool

Due Dates

Objectives

• Complete and extend the first part of Homework 3
  
• Implement non-trivial algorithms recursively.
  

Description

Overview

• All features of the original Homework 3 requirements must be working.  Any missing features must be completed (backup, number of towers != 3, etc.)
• <>The controller must be able to solve the puzzle automatically in a couple of ways. 
• <>Upon user request, the controller must be able to "mass-move" any number of disks from one tower to another, without moving any other disks.  This is to be done through a series of legal, individual moves, since the model interface for moving disks has not changed.  The controller should refuse this mass-move request if a) the largest disk to be moved is larger than the disk currently on top of the target tower and b) if, aside from the source and target towers, there is no tower which the largest disk to be moved can be placed on. 
• <>The controller must be able to "collect" all the disks automatically onto one tower, regardless of their current (legal) position. 
• <>Signatures for methods to do these things are defined in the new ITowerController interface. 
• <>For either type of group move, the controller should display a running count of the number of inidividual moves made (restarting the count at 0 each time).
• Put a short pause (Thread.sleep) between individual moves so the user can see that something is happening.
  
• The controller can now accept external restart-game requests.<>
• <>The view should at all times indicate what the most recent move was (i.e., the source tower, destination tower, and moved disk should be indicated).  To support this, three informational methods are added to the model (see the interface).

Structure

Getting Started

• Read all these instructions on this page -- again, carefully.  Go back and review the original Homework 3 instructions, too.
  
• You can continue with the same partner, if you had one, or you can "divorce" by mutual consent.  You cannot take a new partner.
  
• Browse the files, especially the interfaces, as they contain a number of important details not covered in these instructions. 
• Set up a project on your local machine with the required package structure.  This time we are not supplying starter code for the three classes.   Start from what you implemented already.
  
• Update the three main classes, implementing the new required methods as stubs if necessary.
  
• At this point, the new TowerStarter program should compile.
• And now, TowerStarter should run!  What you see should look much like your old Homework 3 version.
• If your Homework 3 was missing some features, get them working.
• Determine what the user input will be for the new operations.  Decide how the view and controller panels will change appearance.  A "mock-up"  is recommended but not required.
  
• Figure out the "mass move" algorithm first.  A hint is in the textbook problem database, and it is widely known otherwise (you can find it in many programming textbooks).  Understand the algorithm at the pseudocode level.  To test your understanding, manually execute the steps (for small N) on your own Towers game.
• Postpone the "collect" algorithm until the "mass move" is done.
  
• Take it from here...
  

Contest?

Turn in:

• Any difficulties you had in general; the list of possibilities is longer this time than last! 
  
• For each of the three modules, a statement as to what required features work and what ones didn't work.  This could be as simple as "everything works" (if that's the case!)
• Instructions to the user (game player), if they are not obvious once the program starts.
• The "timing" results of your "collect" algorithm on a set of test configurations (which we will specify).
  
• A discussion of the data structures you used (this might be an expansion of what you wrote for Homework 3A.)  A statement about how the data structures were implemented (i.e, by using standard Java classes, textbook code, code you wrote from scratch, etc.)
  
• A discussion of a couple of the key algorithms you implemented and their complexity.  In particular, describe your "collect" algorithm in English and/or pseudocode.
  
• All of the above should be done with your partner if you have one.  If you do, then in addition, each partner should individually prepare a short confidential report on the partner experience.  In this short report, describe briefly your personal contribution to the project, and estimate what percentage of the total was done by you.  Turn this in, folded and stapled for confidentiality, separate from the other paperwork.
  

• Correct structuring of the packaging.
  
• Appropriate choice of data structures
• Correctness and efficiency of the "collect" algorithm.
  
• Appropriate and efficient other algorithms
• Correct operation of your three modules, run together
• Correct operation of each of your modules, when run with any correct implementations of the other two
• Robust and reasonable operation of each of your modules, when run with possibly incorrect implementations of the other two.
• Following instructions and specifications (including what materials are to be turned in, deadlines, etc. etc.)
• Programming practice (style, comments, etc.)
• The report