CPSC 1430 Programming and Problem Solving IIProgramming Assignment #4: “Card Game”This assignment focuses on using Stack and Queue ADTs.Project LoreSilly Little Gameshas come up with a new card game...

CPSC 1430 Programming and Problem Solving II

Programming Assignment #4: “Card Game”

This assignment focuses on using Stack and Queue ADTs.

---

Project Lore

Silly Little Gameshas come up with a new card game for you to simulate. Using astackandqueueimplementation, implement a program which can evaluate this game an arbitrary number off times.

---

Stack and Queue Implementation

Thestackandqueueimplementation used can either be yourstackandqueueimplementation from P3, or a stock implementation provided for this assignment which implements the same features.

To copy the stock implementation into your current directory (your location in filesystem, as shown by the terminal) run the following command:

cp /home/fac/bcuneo/class/cs1430/p4/* .

This will also copy over aMakefilewhich works with this stock implementation. ThisMakefileis mostly the same, except it does not include rules to compile over the object filesstack.oandqueue.o, which is important if you have your own versions ofstack.cppand queue.cpp in your directory.

---

The Rules of the Game

1. The game is played with a deck cards. These cards are each labeled with a number between 1 and 13.


2. 
   For a game with N players:
   
   
   
   1. Each player is assigned a unique number between1andN.
   
   
   2. Exactly2*Nof each value from 1 to 13 should be present in the card deck.
   
   
   3. Each player has a unique queue of cards called theirplayer queue.
   
   
   
   


3. 
   At the start of each game:
   
   
   
   1. The cards are shuffled and placed into a stack calledthe deal stack.
   
   
   2. Eachplayer queueis dealt 7 cards fromthe deal stackin around-robin order. Prior to this first dealing, eachplayer queueis empty.
   
   
   3. After all players have been dealt their cards, the next card inthe deal stackis placed in another stack calledthe discard stack.
   
   
   
   


4. Game-play is broken into turns, with players performing their turn in around-robin order.
   


5. During each turn:
   
   
   
   1. The active player checks the top card inthe discard stack,X, and places the next card in theirplayer queue,Y, on top ofXinthe discard stack.
   
   
   2. The active player then performs an action based on the value of X, relative to the value of Y:
      
      
      
      1. If X < y:="" nothing="" is="">
      
      
      2. If X == Y: The active player takes the next card fromthe deal stackand places it into theirplayer queue.
      
      
      3. If X > Y: The active player takes the next two cards fromthe deal stackand places it into theirplayer queuein the order they were received.
      
      
      
      
   
   
   3. Once this action is performed, the player's turn is over.
   
   
   
   


6. Ifthe deal stackruns out of cards, all cards inthe discard stackare transferred to the deal stack without changing their order. If boththe deal stackandthe discard stackare empty, the game ends as a tie.


7. If the active player'splayer queueis empty at the end of their turn, they have won the game, and the game ends.

Implementation Requirements

1. The card game described above must be implemented for 2 players.


2. 
   The deal stackandthe discard stackmust be implemented as a stack ofintvalues.


3. Eachplayer queuemust be implemented as a queue ofintvalues.


4. 
   This game is fully deterministic:Given a starting order for the cards inthe deal stack, a program should be able to consistently reproduce the same outcome, based upon the rules of the game.
   
   
   
   1. At the start of the program, the first full gameis automatically evaluated to completion.
   
   
   2. Once a game has been evaluated, the program should prompt the user to either end the program or evaluate another full game to completion, and then perform the action indicated by the user.
   
   
   
   


5. During the start of each game, before any dealing has occurred, the state ofthe deal stackmust be displayed as a comma-separated list of integers - showing the content of the stack from the bottom to the top. This list should be on its own line and should not have any newlines or spaces between integers.


6. During each turn, the card used by the active player must be clearly displayed.


7. At the end of each game, the winner should be displayed or (if it is a tie) a draw should be announced.


8. If a game ends with a winner, the state ofthe deal stackafter the final turn should be printed out as a comma-separated list of integers - showing the content of the stack from the top to the bottom. This list should be on its own line and should not have any newlines or spaces between integers.


9. Theround-robin orderingused when evaluating the game iterates over each player in ascending order, according to their assigned number, starting atplayer 1and looping fromplayer Nback toplayer 1. In other words, if the cards dealt at the beginning of the game were numbered starting at zero and counting upwards by one each iteration, theKthcard would be dealt toplayer (K%N)+1. Likewise, if turns were labelled under the same numbering scheme, the active player for theKthturn should beplayer (K%N)+1.

---

Testing for Memory Bugs

The programvalgrindcan tell if another program has leaks memory or performs improper memory accesses.

You can testp4by running the commandvalgrind --leak-check=full ./p4. The program will behave normally until it finishes, at which pointvalgrindwill print diagnostic information about how your P4 executable used memory.

Your program has no memory leaks ifvalgrindprints the messageAll heap blocks were freed -- no leaks are possible.

If other memory errors occurred during execution,valgrindwill report them to you as they occur.

Building the Project

This program must build with a Makefile.

To use a Makefile, place it in your project directory (with the file nameMakefile) and runmake.Here is a default Makefile for P4, which should be usedif and only if you plan to use your own ADT implementations. You may edit it if you choose.

The content of this Makefile should look like the block below. If you copy/paste from this block, ensure that the indentation is still a single tab character after pasting.

Makefile Contents:

p4 : stack.o queue.o p4.cppg++ p4.cpp stack.o queue.o -std=c++11 -Wall -g -o p4stack.o : stack.h stack.cppg++ stack.cpp -std=c++11 -Wall -g -cqueue.o : queue.h queue.cppg++ queue.cpp -std=c++11 -Wall -g -c

---

Submitting the Project ( with your own stack/queue implementations )

The source code files must be namedMakefile,stack.h,stack.cpp,queue.h,queue.cppandp4.cpp. To submit, type the following command from the directory where the file is located:

/home/fac/bcuneo/submit/cpsc1430/p4_runme

All six files will be automatically copied to your submission directory and compiled. The script will let you know that the submission was received, or if there was an error. You may submit as many times as you want until the due date/time has passed.

---

Submitting the Project ( with the stock stack/queue implementations )

The files must be named makefile,stack.h,stack.o,queue.h,queue.oandp4.cpp.

For extra credit

Instead of starting the first game with 2 players, the user chooses the number of players before the start of each game.

This program is an addition to the standard P4 requirements. All that is needed to receive extra credit is to include these additional features in your P4 submission.

Rubric

Stack/Queue Card Game Rubric

Stack/Queue Card Game Rubric

Criteria	Ratings	Pts
This criterion is linked to a Learning OutcomeDescriptive identifiers and constants, used appropriately Non-constant names are descriptive and done in camelCase style. Constants are named in SCREAMING_SNAKE case and used as appropriate.		5pts
This criterion is linked to a Learning OutcomeProper indenting, spacing, and grouping of code Four spaces for each level of indent. Curly braces for class/struct declarations and function definitions are lined up in the same column. The opening curly brace following the conditions of control structures are on the same line. Related lines of code are grouped for easy reading. All lines have no more than 120 characters.		10pts
This criterion is linked to a Learning OutcomeProper program and function documentation Program documentation follows the course code formatting/style guide.		15pts
This criterion is linked to a Learning OutcomeCards shuffled appropriately "Cards" numbered 1 to 13, with 2 copies for each player, are randomly placed in a stack at the start of the game. The ordering of these cards don't need to be TRUELY random, but there should be no obvious patterns to their ordering and the probability of duplicate initial stack states between games should be very low.		10pts
This criterion is linked to a Learning OutcomeStack & Queue classes used appropriately The deal stack and discard stack are implemented as stacks of integers. Player queues are implemented as queues of integers.		10pts
This criterion is linked to a Learning OutcomeGame played correctly Each game is evaluated according to the rules in the assignment description.		25pts
This criterion is linked to a Learning OutcomeWell-designed user interface The prompts required by the assignment description are given by the submitted program. Additionally, the submitted program should appropriately react to the input provided by users. The initial and final state of the deal stack should be displayed as described in the assignment description. The card used by the active player during each turn should be displayed as described in the assignment description.		15pts
This criterion is linked to a Learning OutcomeCorrect Memory Usage When run with valgrind, the submitted program does not report any improper memory usage and does not report any memory leaks if it exits normally.		10pts
Total Points:100