CSE 373 Winter 2005

Homework #3B

Towers Game (II)

Files  Turn-in form   Mixmatcher tool

Due Dates

Objectives

• Complete and extend the first part of Homework 3
  
• Implement some non-trivial algorithms, possibly using recursion.
  

Basic 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.  Let's call this feature "auto-stack".
  
• Signatures for methods to do these things are defined in the new ITowerController interface.  Please implement these methods to work as documented, even if you don't need to call them from your own code.  This is because we may use them to test your program externally.
  
• For either type of group move, display a count of the number of individual moves made (restarting the count at 0 each time).
• You may be tempted to put a short pause (Thread.sleep) between individual moves of a mass move so the user can see that something is happening.  This is a great idea, but won't work unless the moves and the pause are done in a separate thread.  I can help you add this if you are interested, but it might be best to wait until after the basic code is working.
  
• 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 the above item, three informational methods are added to the model (see the interface).  Furthermore, there are some additional model methods which you should find useful in implementing the mass move.
  

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.  If you did not have a partner before, and want to form a team, please contact me for authorization before the end of this week!
  
• Browse the files, especially the interfaces, as they contain a number of important details not covered in these instructions.   This time we are not supplying starter code for the three main classes.  
• Set up a project on your local machine with the required package structure. Start from what you implemented already.
  
• Update the three main classes, changing the package and import names,  implementing the new required methods as stubs if necessary.
  
<>At this point, the new TowerStarter program should compile and 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.  Try to avoid the necessity for separate instructions.  (If you bought a commercial video game, you wouldn't like having to read a manual before starting to play!)
  
• 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 a copy or 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