User Tools

Site Tools


Sidebar

projects

wcp1 (due 20240124)
pct0 (bonus; due 20240125)
pct1 (bonus; due 20240125)
abc0 (due 20240131)
btt0 (due 20240131)
pct2 (due 20240131)
wcp2 (due 20240131)
mpg0 (due 20240207)
pct3 (bonus; due 20240207)
wcp3 (due 20240207)
mpg1 (due 20240214)
pct4 (due 20240214)
wcp4 (due 20240214)
bwp1 (bonus; due 20240228)
mpg2 (due 20240228)
pct5 (bonus; due 20240228)
wcp5 (due 20240228)
cgf0 (due 20240306)
gfo0 (due 20240306)
pct6 (due 20240306)
wcp6 (due 20240306)
cgf1 (due 20240313)
pct7 (bonus; due 20240313)
wcp7 (due 20240313)
cgf2 (due 20240320)
pct8 (due 20240320)
wcp8 (due 20240320)
pct9 (bonus; due 20240327)
wcp9 (due 20240327)
bwp2 (bonus; due 20240410)
cgf3 (due 20240410)
gfo1 (due 20240410)
pctA (due 20240410)
wcpA (due 20240410)
pctB (bonus; due 20240417)
waq0 (due 20240417)
wcpB (due 20240417)
pctC (due 20240424)
waq1 (due 20240424)
wcpC (due 20240424)
pctD (bonus; due 20240501)
wcpD (bonus; due 20240501)
gfo2 (due 20240508)
pctE (bonus; due 20240508)
wcpE (bonus; due 20240508)
EoCE (due 20240516)
haas:spring2024:data:projects:cgf3

Corning Community College

CSCS2320 Data Structures

PROJECT: Card Game Fun 2, continued (CGF3)

OBJECTIVE

Have another week to fully complete all the specifications.

cgf2: core doubly-linked stack functionality cgf3: freecell-esque game completed

documentation page links to cgf2 page.

EDIT

You will want to go here to edit and fill in the various sections of the document:

cgf2

doubly linked stack

Stack Struct

The following is a simple struct for a stack. It includes a pointer to a deck class, a pointer to the top card in a stack, and the size of a stack.

struct stack {
    deck* deckPtr;   // Pointer to the deck structure
    cardnode* top;   // Pointer to the top card in the stack
    int size;        // Size of the stack
};
Function to Create Stack

After Making your struct stack you can choose to make a function that you can call every time you make a new stack. You'll want to do this considering how many stacks you need for creating FreeCell.

//Creates a stack when called
stack* createStack(deck* d) {
    stack* newStack = (stack*)malloc(sizeof(stack));
    newStack->deckPtr = d;
    newStack->top = NULL;
    newStack->size = 0;
    return newStack;
}

LIFO/FILO

LIFO stands for last in, first out. In a LIFO system, the last item added to the structure is the first one to be removed. It's similar to a stack data structure, where you can think of items being stacked on top of each other, and the most recently added item is the first to be taken off the stack. FILO stands for first in, last out. In the FILO structure, the first item to get added to a list is the last one to get taken out. You can think of this as a queue where the item that has been in queue the longest is the one that gets taken out next.

size: bounded vs unbounded

top

push

The following is a function that grabs a card from the deck list and pushes it onto the specified stack.

void push(stack* s, cardnode* card) {
    card->next = s->top;  // Link the new card to the previous top
    s->top = card;        // Set the new card as the top
    s->size++;            // Increase the size of the stack
}
stack overflow

pop

This is an example of what your pop function might look like.

void pop(stack* s, Cardnode* card) {
    s->top = card->prev;
    card->next->prev = card->prev;
    card->prev->next = card->next;
    if(s->size!=0){
      s->size--;
    }
}
stack underflow

peek

card game: freecell

foundations

The foundations in Freecell are 4 piles of cards in the upper-right. You're only able to place cards in foundations in a specific order, and you cannot take them back out. The order in which cards are placed in foundations goes from Ace to King, and each foundation represents one of the four suits.

At the start of the game, all the foundations are empty. To win Freecell, all four foundations must be filled up with the entire deck of cards.

Foundation logic

To accomplish this functionality you can create the following bool function:

// Funtion for checking a valid placment of a card in the final destination
bool isMoveValid(stack* upperStack, cardnode* card)
{
     // If the stack is empty, only Ace can be placed
    if (upperStack->size == 0)
    {
        return card->value == 1;
    }
 
    cardnode* topCard = upperStack->top;
 
    // Checks if suits are the same and the card being added is one higher than the current card
    return (topCard->suit == card->suit) && (topCard->value + 1 == card->value);
}

This function checks if the current card in your hand can be placed onto one of the final stacks (NOTE: This also takes into account that the current card you have matches the suit you are trying to place it on)

Here is a possible example of calling the function:

// Checks if the card can be dropped with the isMoveValid funtion and drops if so
if (isMoveValid(currentStack, Hand->top))
{
    cardnode* topCard = pop(Hand);
    push(currentStack, topCard);
}

Note: hand→top Refers to the card you are moving.

storage

There are four Storage piles in the top-left of the board. Unlike the foundations, the each storage slot can only hold one card at a time.

Like the foundations, these start empty at the start of the game. The player may choose to take a card from any tableau and place it within a storage slot, and they can take it back at any time. If all the storage slots are filled, no more cards can be placed into the Storage piles.

tableau

The tableaus are the eight piles of cards below the storage piles and foundation piles.

At the start of the game, the tableaus are filled up with all 52 cards in a shuffled manner (It can be purely random, or placed strategically, it doesn't matter. The tableaus don't need to be a specific size.) The player is only able to interact with the top-most card of the tableau. The player has the option to move that card from one tableau into another tableau. However, a card can only be placed onto a tableau if:

  1. The card being placed has a value of exactly one less than the card it's being placed onto.
  2. The card being placed has a color opposite than the card it's being placed onto.

The strategy for the player is to try to line up tableaus into positions going from King to Ace. This makes it much easier to place the cards into the foundations.

Note: When coding the tableaus, a max size for each stack may be desirable so that cards do not go off-screen.

pile
 

SUBMISSION

To be successful in this project, the following criteria (or their equivalent) must be met:

  • Project must be submit on time, by the deadline.
    • Late submissions will lose 33% credit per day, with the submission window closing on the 3rd day following the deadline.
  • Executed programs must display in a manner similar to provided output
    • output formatted, where applicable, must match that of project requirements
  • Processing must be correct based on input given and output requested
  • Output, if applicable, must be correct based on values input
  • Code must be nicely and consistently indented
  • Code must be consistently written, to strive for readability from having a consistent style throughout
  • Code must be commented
    • Any “to be implemented” comments MUST be removed
      • these “to be implemented” comments, if still present at evaluation time, will result in points being deducted.
      • Sufficient comments explaining the point of provided logic MUST be present
  • No global variables (without instructor approval), no goto statements, no calling of main()!
  • Track/version the source code in your lab46 semester repository
  • Submit a copy of your source code to me using the submit tool by the deadline.

Submit Tool Usage

Let's say you have completed work on the project, and are ready to submit, you would do the following:

lab46:~/src/SEMESTER/DESIG/PROJECT$ submit DESIG PROJECT file1 file2 file3 ... fileN

You should get some sort of confirmation indicating successful submission if all went according to plan. If not, check for typos and or locational mismatches.

RUBRIC

I'll be evaluating the project based on the following criteria:

208:cgf3:final tally of results (208/208)
*:cgf3:doubly linked stack implemented and used [104/104]
*:cgf3:functioning freecell type card game [104/104]

Pertaining to the collaborative authoring of project documentation

  • each class member is to participate in the contribution of relevant information and formatting of the documentation
    • minimal member contributions consist of:
      • near the class average edits (a value of at least four productive edits)
      • near the average class content change average (a value of at least 1024 bytes (absolute value of data content change))
      • near the class content contribution average (a value of at least 1kiB)
      • no zero-sum commits (adding in one commit then later removing in its entirety for the sake of satisfying edit requirements)
    • adding and formatting data in an organized fashion, aiming to create an informative and readable document that anyone in the class can reference
    • content contributions will be factored into a documentation coefficient, a value multiplied against your actual project submission to influence the end result:
      • no contributions, co-efficient is 0.50
      • less than minimum contributions is 0.75
      • met minimum contribution threshold is 1.00

Additionally

  • Solutions not abiding by spirit of project will be subject to a 50% overall deduction
  • Solutions not utilizing descriptive why and how comments will be subject to a 25% overall deduction
  • Solutions not utilizing indentation to promote scope and clarity or otherwise maintaining consistency in code style and presentation will be subject to a 25% overall deduction
  • Solutions not organized and easy to read (assume a terminal at least 90 characters wide, 40 characters tall) are subject to a 25% overall deduction
haas/spring2024/data/projects/cgf3.txt · Last modified: 2023/10/21 16:38 by 127.0.0.1