haas:fall2014:common:data:cardgame

Corning Community College

Data Structures

Eight-Off/Forty Thieves/FreeCell Card Game Implementation

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 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

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

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.