Programming Assignment 1a - Solitaire, Part 1

Due Date

See the assignment turn-in page (last modified on 14 February 2008) for instructions on turning in your assignment.

The Problem

For convenience, here’s the list of games; un-linked-to games are unavailable. Solitaire Games has detailed descriptions of the games and a glossary.

Aces and Kings Aces Up Acquaintance Agnes Bernauer Agnes Three Alaska Alliance Antares Apophis Auld lang Syne Australian Patience Baker’s Dozen Baker’s Game Beleaguered Castle Black Hole Busy Aces Canfield Cruel Demons and Thieves Diavolo Double Klondike Eagle’s Wing

East Haven Eight Off Family Plot Forty Thieves Fourteen Out Freecell Duplex Freecell Gaps Gold Rush Golf Great Wheel Interchange Josephine King Albert Klondike La Belle Lucie Lady Jane Monte Carlo Moving Left Mrs. Mop Osmosis Penguin

Pyramid Rank and File Rouge et Noir Russian Solitaire Scorpion Sea Towers Spiderette Spider Spotlight Storehouse Tarantella Terrace Thirteens Three’s Company Three Shuffles and a Draw Triple Klondike Vertical Virginia Reel Windmill Yukon Zerline

Your code should be essentially be a game referee. It should set up and conduct the game, making sure the rules are followed, and determine when the game is lost or won, keeping score as required by the game. Your code should not actually play the game.

You are developing a back end for a solitaire game. The technical term for what you’ll be developing is the model part of the model-view-controller pattern.

You may assume the player is knows how to play the game but isn’t necessarily fair. Instances of game misplay should be detected and handled appropriately by, for example, ending the game. You should not assume that the player will be human.

Player Public Classes

It must be possible to implement a front-end to your game entirely through the public entities in the playerAPI package, passing requests to the back-end and getting repsonses back. Your back-end implementation must not perform GUI- or terminal-based I-O. You may use such I-O to develop and test your code, but it must be possible to use your back-end without having it perform any GUI- or terminal-based I-O.

Code Structure

Documentation

Your code should be fully documented using JavaDoc. In particular, it should be possible to figure out how to play your game by reading the documentation created from the contents of your playerAPI package. Your documentation should include overview and package documentation. The overview documentation should be in a file called overview.html and may be in any of the package directories you submit (for some reason having to do with frames (?), javadoc won’t show your overview documentation if you have less than two packages). The package documentation should be in a file called package.html in each package directory. You can review Documentation Comments starting on page 162 in Horstmann and Cornell to pick up on the details.

The example documentation is the HTML documentation transmogrified into PostScript; the HTML documentation looks different from the example.

This documentation is part of the writing requirement for this class.