Compsci 108, Fall 2005, Freecell

gui code which is also snarfable via the 108 snarf page http://www.cs.duke.edu/courses/cps108/fall05/snarf.

Add cardimages.jar to your classpath to make it work.

To submit, please turn in everything you've done: all source code, a README file in which you have all group members listed, the total number of hours spent, and the group's perception of the project. You should submit all documentation you've developed. The README is done separately for each group member. The group will create a web page on which all group responsibilities are delineated and on which the group's game will be accessible.

The rules for the card solitaire game Freecell can be found at Solitaire Central. See also freecell.org for information about the game and implementations.

You are to develop a suite/framework of classes and code in Java to allow the user to play a text-based version of Freecell. All interaction with the program should be done via the command line, i.e., process data using System.in in Java. However, you will be porting your program to use a GUI, so you should isolate the text-based control so that it doesn't worm its way into all parts of the program you develop. This is essential --- you'll be provided a GUI and you'll need to make your code work with the GUI in a small amount of time. Additionally, you'll port another group's code to the GUI using their documentation and code.

Design Guidelines

Your program will be graded 30% on usability, 30% on the design and implementation of the framework you develop, 20% on the testing harnesses you develop, and 20% on another group's evaluation of your code [see below]. For usability, the key issues are how easy is it to play a game and how well does your program adhere to the rules of Freecell. For design, we'll look out how well-designed each class is, how well-designed the collection of classes is, and how extensible the framework is. One excellent way to prove extensibility is to implement more than one solitaire game, e.g., Klondike or another game. For testing we'll look at unit testing of each class/method and integration testing of your framework.

Gui/Code Sharing

After you've submitted your code and documentation you'll be given a GUI framework to develop a GUI version of Freecell. However, in addition to porting your code to use the GUI you'll also use another group's design/code to implement a Freecell game using the GUI. You'll be graded on the success of your GUI program and you'll evaluation the design and framework of the code you get.

Requirements

In the text version of a game, moves will be designated by specfying the pile from which a card will be moved and the pile to which the card will be moved. According to the freecell.org site you'll see foundation piles (Ace piles), cells (from which the game gets its name) and tableau piles (to which the cards are dealt). You'll designate these, respectively, as "f1, f2, f3, f4" and "c1, c2, c3, c4," and "t1, t2, ... t7, t8".

Thus a move could be entered as

    t7 f4

In an ideal world one group's text-based controller/view could be hooked up to another group's model if certain conventions are maintained. You won't have to do this, but the program should be able to process a sequence of moves as described, one move (two piles) on each line.

Deliverables

Each group will create a website for the project. You must have responsibilities as follows, the roles played by each group member must be on the website. The entire group should run by consensus as much as possible, but there may be group meetings across groups of the different positions. All positions should also be planning, developing, and writing code.

CEO Chief Executive Officer: in charge of overall group moral, vision, mission, and work. Makes the group work.
CTO Chief Technology Officer: in charge of CVS, Eclipse, Flash, CSS, making sure technology works for the group, not against it.
CSA Chief Software Architect: in charge of the overall architecture used in the program. Ensures proper design and testing are developed and maintained.
CIO Chief Information Officer: in charge of disseminating information, e.g., via the web, through group presentations.

October 17: Group Website up and functional. This should include information about the group (name and responsibilities) and a link to preliminary javadoc for classes you'll be developing. The javadoc should be kept up-to-date on a daily basis (refresh it from your source once-per-day).
October 19: Display the state of a game with ASCII art (art isn't necessary, ASCII is).
October 21: Game functional (beta)
October 24: Text version 1.0 submitted.
October 28: GUI version submitted for your code
October 31: GUI version submitted for other group's code.

Owen L. Astrachan

Last modified: Thu Oct 27 02:16:56 EDT 2005