CSC 101 Programming Assignment 5
Preparation for Card Game Programming

Overview

This is a two week programming assignment. It is due on or before 9PM Monday May 24 via UNIX turnin. The name of the assignment is program5. The name of the program to turn in is program5.cpp. It is worth 11% of the total class grade (which is the combined value totals for assignments 6 and 7 as originally given in the syllabus).

As with program 4, there is a design component to this assignment. The design is due on paper, turned in to the drop box outside of the computer science office, by the same time as the electronic turn in.

The purpose of this assignment is write some functions that will be used in the final programming assignment, where you will write a program to play a card game of your choosing. This assignment also includes a high-level design of the card game program.

The card games to be played will use a standard deck of 52 cards, where each card has a face value and suit. The face value is one of "Ace", "King", "Queen", "Jack", or a number between 2 and 10. The suit is one of "Spades", "Hearts", "Diamonds", or "Clubs".

Specification

The specification of this assignment covers three areas:

• the external representation of cards as input by and output to the user who is playing the card game;
• the specification of some functions that will be used in the game program;
• the specification of the high level program design.

External Representation of Cards

A human player is going to communicate with the computer when the card game is played. To do so, the human will view and input card values on the terminal. The following external representation is used for card input and output:

The face value of the card is represented as follows:

Face              External
Value          Representation
-------------+----------------
Ace          |       A
King         |       K
Queen        |       Q
Jack         |       J
10 through 2 |   the number
             |     itself

Suit          External
Name       Representation
---------+----------------
Spades   |       S
Hearts   |       H
Diamonds |       D
Clubs    |       C

Design and implement a function to shuffle a deck of cards. The function takes an unshuffled deck of 52 cards as input and returns the shuffled deck as output. The meaning of shuffled is that the cards are in random order in the deck.

Design and implement a function, with subfunctions as necessary, to deal two hands from a deck of cards. The function takes as input the deck of cards and the number of cards to be dealt to each player. The function returns the hands of cards dealt to each player, and a modified deck with the dealt cards somehow marked as removed. The hands are dealt one card at a time, starting from the top of the deck. If there are not enough cards in the deck to deal both hands, the function returns some indication of this condition.

Design and implement a Boolean function that compares two cards and returns true if the first card "beats" the second card, in the normal rules of ace-high card ordering. Specifically,

1. Ace beats king beats queen beats jack beats any numbered card.
2. A numbered card beats another numbered card with a lower value. E.g., a 10 beats a 3.
3. When two cards are of the same face value, the suit of the card is used to determine order. Specifically, spades beats hearts beats diamonds beats clubs.

Write a function that reads card-game instructions from a text file and outputs them a page at a time to the terminal. Input to the function is the number of lines per page. When the function outputs the contents of the file to the terminal, it does so in groups of N lines at a time, where N is the number of lines per page. Between each page of output, the terminal prompts the user with the following line

Enter 'n' to see the next page, 'p' to see the previous page, 'q' to quit:

Write driver functions to test each of the functions specified above. The driver functions perform a series of calls to the implemented functions, with enough test data to demonstrate that the functions operate correctly.

As noted in the overview, the next programming assignment (no. 6) involves the implementation of a card game program. The specific game to be played is up to you, within the following constraints:

• the game is played between two opponents, which are the program and the human user;
• the program plays as the dealer in the game;
• the program must employ some reasonable strategy of play;
• the program knows the rules of the game, and decides when appropriate who wins and who looses.

For this assignment (no. 5), you must choose which game you will implement, define the basic strategy the computer will use to play the game, and give a high-level design for the game-playing program.

The specific deliverables for the design component of this assignment are:

1. the selection of the game to be played and the description of the program's playing strategy, in one typewritten page or less;
2. the high-level design of the program, in a design diagram.

The definition of a "reasonable" playing strategy is one in which the program plays the game to win in some basic way. The program certainly does not have to play as well as a skilled human, but must use some form of potentially winning strategy.

Design and Implementation Issues

One of the key design issues for a card game program is to determine an appropriate data representation for the deck of cards. The basic data representation will need to be an array (or arrays) of some form. There are a number of possibilities, the most straightforward of which is an array of strings, where each array element is the external representation of a card. The advantage of this array of strings representation is that it holds each card directly as it comes and goes from the user. The disadvantage of this representation is that internally it's somewhat more difficult to perform card operations, such as order comparison.

Another possible representation is an array of named integer constants between 1 and 52, or an enumeration of 52 elements. Each constant (or enumeration literal) represents one of the cards. The advantage of this representation is that some card operations, such as comparison, are easy to perform. The disadvantages are that the program must convert between the internal and external card representations for input and output, and the suit of card may be more difficult to determine.

Yet a third possible representation is two parallel arrays, one containing a character for the suit and the other containing an integer or string for the face value.

For both decks and hands of cards, you will need to represent how cards are removed. Two approaches are marking and an integer position variable. Marking involves putting some empty value in the deck, in the place previously occupied by a card. The position-variable approach involves decrementing an integer variable each time a card is removed from the deck.

If you chose a position-variable representation, then the functions above that refer to "a" deck actually refer to two parameters, one for the deck itself and the other for the integer position index. The same applies for a deck represented as two parallel arrays. I.e., "a" deck refers to the pair of arrays.

Making these kinds of data representation decisions is a very common part of program design. The decision process is often referred to as comparing the "trade offs" between different designs. A trade off refers to the fact that in one design you trade some operations being easier against other operations being harder.