\\ 
<WRAP centeralign bigger><WRAP bigger fgred>Corning Community College</WRAP>
\\ 
<WRAP muchbigger>Data Structures</WRAP> 
\\ 
Eight-Off/Forty Thieves/FreeCell Card Game Implementation
\\ 
</WRAP>
~~NOTOC~~

=====Objective=====
To gain an understanding of linked list-based stack data structures and their use in algorithms.

=====Overview=====
The intent of this project is to explore the use of linked list-based stack data structures through the implementation of a FreeCell-based card game.

If you are not familiar, please reference the Wikipedia article on [[http://en.wikipedia.org/wiki/FreeCell|FreeCell]].
=====Requirements=====
Your task is to implement a specific card game. You must:

  * implement an accurate one player game of one of the above card games
    * it must compile cleanly and without warnings or errors on Lab46
    * it must run and operate in accordance to the expected rules of the implemented game
  * utilize "linked list"-based dynamic stacks (lists of nodes, NOT arrays)
  * comment and organize your source code
  * make use of your repository to store snapshots of the code through its evolution
  * have a minimum of 3 source files (card game functions, card game functions header, card game main())
  * utilize your linked-list and stack libraries created in class

====Game Variations====

  * FreeCell
  * Eight Off
  * Forty Thieves
  * Baker's Game

The reason I have chosen these games is that they involve a level of memory allocation, which has similarity to how the actual computer's hardware works. There may be additional games that fall under this category. If you find one and would like to implement it, let me know and I can ascertain if it is appropriate. Basically, these games utilize stacks as a central operation in gameplay.

=====FreeCell Rules=====
Borrowed from Wikipedia:

====Construction and layout====
  * One standard 52-card deck is used.
  * There are four open cells and four open foundations. Some alternate rules use between one to ten cells.
  * Cards are dealt into eight cascades, four of which comprise seven cards and four of which comprise six. Some alternate rules will use between four to ten cascades.

====Building during play====
  * The top card of each cascade begins a tableau.
  * Tableau must be built down by alternating colors.
  * Foundations are built up by suit.

====Moves====
  * Any cell card or top card of any cascade may be moved to build on a tableau, or moved to an empty cell, an empty cascade, or its foundation.
  * Complete or partial tableaus may be moved to build on existing tableaus, or moved to empty cascades, by recursively placing and removing cards through intermediate locations. While computer implementations often show this motion, players using physical decks typically move the tableau at once.

====Victory====
  * The game is won after all cards are moved to their foundation piles.

=====Stack Operations=====
A card game is an excellent example of stack usage. When moving cards, I want to see push/pop operations taking place with respect to the various "storage locations" the cards can reside (foundations, cells, etc.)

To better understand the impact of stacks on these card games, be sure to play some games. Once you are familiar with the rules, specifically take notice of the functionality the stacks enable for the playing of the game.
=====Code Formatting=====
To facilitate the readability of your code, when preparing your code for submission, I'd like for you to make sure certain qualifications are met:

  * you use consistent indentation
    * multiple levels of code see proper indentation
    * there are no "mostly there" inconsistent indentations
    * no stray statements with 0 indentation
    * all selection, iteration, and function statements receive uniform formatting

If you'd like, I have configured a facility on Lab46 to enable you to conveniently beautify your code to the ANSI/Allman style of coding. This is my preferred coding style, and would help me to better read your code.

So, if you aren't already consistent at code formatting (some have well-established coding habits and their code, although styled slightly different than mine, is still far more readable because it is **consistent**), please go through the following exercise for all your source files.

In this example, I will assume your files are called: **main.c**, **cardgame.c**, and **cardgame.h**

<cli>
lab46:~$ cd src
lab46:~/src$ indent main.c
lab46:~/src$ indent cardgame.c
lab46:~/src$ indent cardgame.h
lab46:~/src$ 
</cli>

You will find that a backup of your original formatted source code is saved in files called **main.c~**, **cardgame.c~**, and **cardgame.h~**. But the plain .c files are now nicely formatted.

If you find yourself tracking down elusive bugs and have experienced an unbalanced curly brace... you may want to consider passing your code through **indent** so as to save yourself some work and time. You'd be amazed what a little code beautification will do for you.

=====Links=====

  * [[http://en.wikipedia.org/wiki/Stack_(data_structure)|Stack Wikipedia Article]]
  * [[http://en.wikipedia.org/wiki/FreeCell|FreeCell Wikipedia Article]]
  * [[http://www.fortythievessolitaire.com/|Web/Flash version of Forty Thieves]]
  * [[http://cslibrary.stanford.edu/104/|Pointer Fun with Binky Educational Video]]
  * [[http://cslibrary.stanford.edu/106/|Pointer Basics]]
  * [[http://cslibrary.stanford.edu/103/|Linked List Basics]]
  * [[http://cslibrary.stanford.edu/101/|Stanford Summary on the C Programming Language]]
  * [[http://cslibrary.stanford.edu/107/|Stanford Introduction of UNIX Programming Tools]]