Executive Summary

You will implement a fully functioning game of Blackjack. No
prior knowledge of the game is needed. However, you will need
to know what cards appear in a standard deck of playing cards.
See your instructor if you have any questions on that account.

Blackjack (also called "21") is basically a game between an
individual player and a dealer. There's a gambling side to the
game that this project does not address. The project simply
plays the game with the user as "Player" and program as
"Dealer", and determines the winner and loser.

Honor:
The
course policy
and the instructions it references,
most pertinently
COMPSCIDEPTINST 1531.1C,
spell out
what kinds of assistance are permissible for programming
projects. The instructor can give explicit permission for
things that would otherwise not be allowed.
For this project, you have explicit permission

to get help from othee current IC210 instructors as
well as your own and from current IC210 MGSP leaders (any
assistance must be documented though), and

to use general purpose C++ resources online (though such
use must be documented).
Resources that might specifically address this project,
say looking through code that implements blackjack or other card games, are
not allowed. You are very specifically not
allowed to look at previous semesters' IC210 programming
project or lab solutions that may have addressed similar issues.

Combining the instructions referenced in the course policy and the
explicit permissions above, and what you get is summarized as:

The only help you may receive on
a project is from your instructor or the other IC210
instructors and IC210 MGSP leader, and that help must be clearly cited. In turn, you
cannot provide help to any IC210 students on this
project.

In no circumstance - project, homework or lab - may you copy
code and submit it as your own work. That is the definition
of plagiarism.

For projects, you may not look at other
people's project code nor may you show your own code to
others.

You can look at online (or other electronic or print) resources for general purpose C++
programming, but not for help writing card game programs
or anything else that is specific to the functionality
required of your project. So, for example, you may not look
at code for a program that plays a card game.

Part 1 [Up to 15pts] - Name your source code file part1.cpp

A part 1 solution will create and optionally shuffle a deck of
cards, printing out the cards (one per line) represented as
integers, as described below. Here are specifications:

The user is presented with message:
Shuffle: [n | s | u <seed>]:
If they enter n, no shuffling will take place.
Otherwise, we'll shuffle using a random number generator, which of course
needs to be seeded. If
they enter s then time(0) is used
as the seed, as in part
2 of lab 6. Otherwise, the user must've given
the u option followed by a number; this number is then
used as the seed.

The unshuffled deck (i.e. prior to shuffling, if shuffling
is to occur) must be ordered by suit — clubs, then diamonds,
then hearts, then spades — and cards of the same suit
must be ordered from smallest (2) to largest (A).

Shuffling must be done exactly as follows: assuming the
cards are ordered as described above, and indexed from zero
to 51:

for i from 0 up to 51 do Disclaimer: This is not a good enough shuffling algorithm for
set j to rand() % 52 "real" applications. Some shuffled orders are
swap the index i element of the deck with the index j element more likely than others.

Sample runs: red text represents
user input,
brown text is explanatory and
not part of the output

Part 2 [Up to 30pts] - Name your source code file part2.cpp

A part 2 solution should be exactly like the part 1 solution
except that instead of printing the integer "cardvalues," you
will print proper cards, e.g.
instead of the integer 310 you'll print out the card 10♥.
Here's how to do that:

Our Unix terminal program understands
"UTF-8" character encodings, which means we can
print card suits to the screen. Each suit symbol is
represented by a string.
Here are the suits and the corresponding string for
printing them in unicode.
♣ ← "\u2663",
♦ ← "\u2666",
♥ ← "\u2665",
♠ ← "\u2660".

The only catch is that what you print out needs to be right
justified, i.e. all the suit values (which come second)
have to line up in the same column.

Sample runs: red text represents
user input,
brown text is explanatory and
not part of the output

Part 3 [Up to 50pts] - Name your source code file part3.cpp

A correct part 3 solution will create and shuffle a deck as in
Parts 1 & 2 (but not print the deck), and then
simulate dealing cards to a
"Player" and a "Dealer" in the following order:
deal one card to "Player," one to "Dealer", one to "Player", and
one to Dealer (so both have two cards). Then display
(as shown below). Then three rounds of dealing first one card
to "Player," then one card to "Dealer," then displaying the hands (once again as
shown below). Note that the "top" of the deck is the first card
as printed out by your Part 1 & Part 2 solutions, and you must
deal from the top of the deck (in the Old West, people got shot for violating this rule!).
Thus, your program's output really must match what is shown
below for the given examples.

Note: You really want to have your program simulate
dealing a card to a hand. You should be able to point to few
variables and say "those represent the player's hand," and
point to a few more and say "those represent the dealer's hand."

Sample runs: red text represents
user input,
brown text is explanatory and
not part of the output

Part 4 [Up to 70pts] - Name your source code file part4.cpp

A correct part 4 solution will start to play something that
actually looks like a game. Player and Dealer will both be
dealt two cards (as in part 3). But then the program will
proceed to ask the Player and Dealer in turns whether they want
to "hit" (in which case they get dealt another card into their
hand), or to "stand" in which case their hand stays the same.
[Note: In this project, the player or dealer can "stand"
one round, then "hit" the next — which is not allowed in
real blackjack.]
The player goes first, and the program should go through three
rounds (i.e. the Player and the Dealer both get three turns).
In between rounds (i.e. just before printing out the current
hands), make the call system("clear"); to clear the
terminal window, so that only the current state of the game is
showing at any given time.
Below is an example of how a game might play out. Your output
and the way you get input from the user must match what's
shown here.

Note: In the submit system, each call to
system("clear") shows up as the character sequence:
[H[2J

Part 5 [Up to 85pts] - Name your source code file part5.cpp

A correct part 5 solution should behave exactly like a correct
part 4 solution, except that in each round the current "best
scores" for both Player and Dealer hands should be shown.
The "best score" for a hand is computed according to the
following rules. Add up points for each card in the hand,
where aces are worth one point, kings, queens and jacks are
worth 10 points, and numbered cards (i.e. 2 though 10) are worth
their number in points.
Call this number total.
If the hand has no aces, total is
the "best score" for the hand. If there are aces in the
hand, and total + 10 is not greater than 21, the "best
score" is total + 10. Otherwise, "best score" is simply
total.

Part 6 [Up to 95pts] - Name your source code file part6.cpp

A part 6 solution functions just like a part 5 solution with the
following two exceptions:

Instead of being read in from the user, the dealer choice of
whether to hit or stand is made by the program following the
simple rule that the dealer always hits when his current
"best score" is less than 17, and always stands otherwise.
In terms of program output, the program will output the
dealer decision as if it had been input by the user,
and make the call sleep(2) (this will require
#include <unistd.h>)
to pause the game for two seconds so that the user has a
chance to see what the Dealer is doing before being
presented with the updated screen.

The game proceeds until either the Player or the Dealer
"busts", which means having a "best score" greater than 21,
both Player and Dealer are tied at 21,
or the
Player and Dealer both stand in consecutive turns
(i.e. Player stands then Dealer stands or Dealer stands then
Player stands).

Note: The game stops
because the Player
"busts". Hitting on
18 was crazy!

Part 7 [Up to 100pts] - Name your source code file part7.cpp

A part 7 solution functions like a part 6 solution with the
following modifications:

The Player and Dealer "best scores" are not printed out at
any point.

The Dealer's top (first) card is only shown
as ** until the end of the game. This way, the
Player has some uncertainty about what to do.

If there is a tie at the end, i.e. both the Player and the
Dealer have the same "best score", a new game is
automatically played. Note: the random number
generator is not reseeded. I.e. do not call srand
again! However, a new deck is created and reshuffled.

If there is not a tie, the program reports who won with one
of the following messages as appropriate:
"Dealer busts, player wins", "Player busts, dealer wins",
"Player wins", or "Dealer wins".

Extra Credit [Up to 110pts] - Name your source code file partX.cpp

The extra credit solution will not even be considered
unless the Part 7 Full credit solution functions correctly.

Your extra credit solution should play the game over and over
again. Each time the player finishes a game, the program should
ask whether the player wants to play again or quit. Each play
the player must make a $5 bet. If the player wins, the player
gets the bet plus some amount of winnings back. You may decide
what the payouts are (could be as simple as getting your bet plus
$5 back). You must report the players winnings / losses at the
end of each round. The player must have the option of
withdrawing from a game (not the table, just that game) after
the initial two cards are dealt to player and dealer, but before
any other play has taken place. Withdrawing means half the bet
is returned to the player, but the other half goes to the house.

When to submit

Part 1 of Project 2 must be submitted electronically, and
pass all Part 1 tests, by 1530 on Tuesday, October 25th. There
is no paper submission at that point. You will submit with:

~/bin/submit -c=IC210 -p=proj02 part1.cpp

The full Project 2 submission is due by COB on Monday,
October 31st, according to
the course's particular definition of "COB". Late projects
incur a penalty of 3N points, where
N is the number of days late. So, a project that is not turned
in by COB Monday, 31 October, but which is turned in by COB
Tuesday receives a 3 point penalty.
A project that is not turned in by COB Tuesday, but which is
turned in by COB Wednesday receives a 9 point penalty. And so on.
You will submit with:

What to submit

You will submit the furthest properly functioning solution.
So, if your Part 7 solution works, submit the Part 7 solution.
If you don't have a properly functioning Part 7 solution,
but your Part 6 solution works fine, submit a Part 6 solution.
And so on.
Note that what you submit must work, and absolutely must compile!
What gets submitted is:

Your source code (i.e the .cpp file).
You will submit a printout of this (use codeprint) and an
electronic copy (how to do the electronic submission will be
explained later).

How projects are graded / how to maximize your points

Make sure the form of your output matches the form of the
example output in all
ways. Of course the cards you see and decisions dealer and
player make will vary from the examples you see.

Make sure you follow
the IC210
Style Guide.
This means proper indentation, use of whitespace within
lines of code, logical organization of chunks of code,

Make sure you do a good job of putting things in functions.
One monolithic main function is not OK, even if it works!
The quality of your overall design will play a role, and
a large part of that boils down to using functions well.