Programming Assignment 1a - Solitaire, Part 1

Object-Oriented Programming with Java, Spring 2008

Due Date

This assignment is due by 11:30 p.m. on Tuesday, 4 March.

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

The Problem

Go to Solitaire Games and pick one of the 17 listed solitaire games to implement. One you've picked, e-mail me (rclayton@monmouth.edu) your choice so I can keep track. Everybody has to implement a different game.

For convenience, here's the list of games; crossed-out games have already been picked. Go to Solitaire Games for detailed descriptions.

  1. Baker's Dozen
  2. Black Hole
  3. Eagle Wing
  4. EastHaven
  5. Forty Thieves
  6. FreeCell
  7. Golf
  8. Great Wheel
  9. Klondike
  10. Pyramid
  11. Rouge et Noir
  12. Scorpion
  13. Windmill (link seems to be dead; try this one.)
  14. Aces and Kings
  15. Demons and Thieves
  16. Tarantella (link seems to be dead; try this one.)
  17. Three's Company

Your program 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 program 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 Interface

Your program should offer one public interface in the package called playerAPI (the case is exact). It should be possible to play your game through the methods exported from the playerAPI package.

It must be possible to play the game entirely through method calls in your player-API, passing requests to the game and getting repsonses back. Your implementation must not require a GUI- or terminal-based interface. You may create such an interface to develop and test your code, but it must be possible to play your game without a visual or interactive interface.

Program Structure

Your source configuration should have a top-level player-API package directory and should not have a top-level package directory called “doc”. Other than those two requirements, you may structure your program source as you see fit.

Documentation

Your program 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. You can review Documentation Comments starting on page 144 in Horstmann and Cornell to pick up on the details.

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

This page last modified on 4 April 2008.