Programming Assignment 1b - Solitaire, Part 2

Object-Oriented Programming with Java, Spring 2008

Due Date

This assignment is due by 11:30 p.m. on Thursday, 20 March.

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

The Problem

Design a program that plays a solitaire game. The program should play autonomously, without expecting or receiving outside help.

The player program should accept a non-negative integer as the single mandatory command-line argument giving the number of games to play. The program should expect no other input of any kind; in particular, no kibitzing.

The player program should write a single line of output to std-out indicating the number of games won and lost. The program should produce no other output of any kind in normal execution; in particular, it should not display any information about games it is playing. If it detects an error, the program should print an informative error message to std-err and exit with no further processing.

Examples:

$ java DeamonsAndThieves 100
won: 37, lost: 64

$ java DeamonsAndThieves -1
! The number of games to play should be non-negative.

$ java DeamonsAndThieves 
! The number of games to play should be given as a command-line argument.

$ java DeamonsAndThieves 0
won: 0, lost: 0

$

Game-program designers have been assigned games as shown in the two leftmost columns of the following table:

Player Game API

designer API Implementer

Alpaugh East Haven Wallerstein

Bacon Windmill Alpaugh

Banks Black Hole Bacon

Betancourth Bakers Dozen Banks

Carpouzis Pyramid Betancourth

Codd Klondike Carpouzis

Guardascione Golf Codd

Karpodinis Tarentella Guardascione

Kaufman Aces and Kings Karpodinis

Lee Forty Thieves Kaufman

Perriello Scorpion Lee

Rinaldi Freecell Perriello

Wallerstein Spider Rinaldi

Player	Game	API
designer	API	Implementer
Alpaugh	East Haven	Wallerstein
Bacon	Windmill	Alpaugh
Banks	Black Hole	Bacon
Betancourth	Bakers Dozen	Banks
Carpouzis	Pyramid	Betancourth
Codd	Klondike	Carpouzis
Guardascione	Golf	Codd
Karpodinis	Tarentella	Guardascione
Kaufman	Aces and Kings	Karpodinis
Lee	Forty Thieves	Kaufman
Perriello	Scorpion	Lee
Rinaldi	Freecell	Perriello
Wallerstein	Spider	Rinaldi

A game designer having questions about a game's API should get in touch with the game API's implementer to discuss the matter further.

Game APIs

The player program plays a solitaire game using the features provided by the game's player API; most likely by creating class instances and calling methods. The game's player API is available as a jar file in the class directory /export/home/class/cs-310/a1b/1b under the appropriately-named directory. For example, the player API for East Haven can be found in

/export/home/class/cs-310/1b/east-haven/east-havenAPI.jar

The easiest way to use the jar file is add it to your classpath variable:

$ CLASSPATH=/export/home/class/cs-310/1b/east-haven/east-havenAPI.jar:$CLASSPATH

The compiler and the JVM will then search the jar file as they look for information on the various packages and features used in the player program.

Note: Some of the assignments didn't compile to completion, which means the associated jar file won't contain the full set of classes. If that's the case for the game you're designing, you should contact the game API's implementer to discuss the matter further. Because this assignment calls for a design and not an implementation, having access to working code isn't as important as having access to correct and complete documentation. However, some may prefer to design (and perhaps get a head start on implementation) with access to the code.

Documentation

The Javadoc for the game's player API can be found in the class directory /export/home/class/cs-310/a1b/1b under doc in the appropriately-named directory. For example, the player API for East Haven can be found in

/export/home/class/cs-310/1b/east-haven/doc

Point your browser at doc/index.html to start browsing. The file doc/doc.ps contains a printed version of the documentation.

Note: Some of the assignments didn't generate complete documentation, or any documentation at all. If that's the case for the game you're designing, you should contact the game API's implementer and work out a solution.

Turn-In

There are two possible turn-ins for this assignment: a mandatory design document and an optional re-implementation of the first assignment.

For game designers: each game designer must turn in a design document, which should be a single html document called design.html. Use send-files to turn the document in under the assignment number 1b.design, giving the document name on the command line:

$ send-files -a1b.design -s design.html

$

The design document's quality is based on mainly two features:

Completeness: There should be an almost complete one-to-one correspondence between the features described in the design document and the features present in the eventual implementation. “Features” in this case means packages, classes, and both instance and class methods.
Rational: It should be possible to point to any implementation feature described in the design document and ask “why”, and find the answer by reading the design document.

For game-API implementers: If, while dealing with questions from a game designer, you discover that your implementation or documentation can be improved, you may make those changes and turn your implementation in again. Make sure you turn-in your new API implementation to assignment 1b, for example

$ send-files -a1b -s impl playerAPI

$

If you turn-in the game-API implementation, and it compiles successfully, it will replace the game-API files available in the class directory. If the turn-in fails, or if game-API implementation is just being tested, the game-API files available in the class directory are left untouched.

Some Advice

It's a good idea to keep a recorded trail when working with other people who are important to your project. In addition to providing a handy indicator of the amount of progress that's occured, it serves as a convenient place to note previous details and keep track of expected details as well as when they're expected.

This page last modified on 4 April 2008.