|
Algorithm Development – CS239 |
|
|
Software Requirements Specification
Programming Assignment 4
Gold Duke Game
|
Due
Date |
Deliverable |
Where
|
|
|
Stubs for each of the Player classes (Dealer, GoldDukeDealer, Player, GoldDukePlayer). Your test driver(s). These should have code to test each method in each of the classes that you are making. Your test plan. What conditions will you be sure you look for and insure are working? This should be in a Word document. See detailed specifications. |
To the Blackboard Assignment PA4-Stubs |
|
|
Your fully functional programs, tested with the supplied driver and meeting all style guide requirements as well as all specifications of this application. (Note: this is not the only test that will be run.) |
Harris: to the submit assignment (will not test). |
|
|
||
|
|
Harris: Hardcopy printout of your pdf report. |
In class |
|
|
Introduction
Purpose: In
an attempt to make up for recent budget shortfalls, JMU is about to start a
virtual casino. Several "games of chance" are being developed,
including several card games. Your job is to develop many of the classes needed
for the game GoldDuke.
Background
General Information: GoldDuke is a variant of the game blackjack.
Participants in the Game: A game
of GoldDuke involves a single dealer and one or more players.
Winning the Game: Each
player is competing only with the dealer (i.e., players do not compete with
each other). The player wins if the total point value of her/his cards is less
than or equal to 24 and closer to 24 than the total point value of the dealer's
cards. (24 is used because pure gold is known as 24 carat gold.)
Point Value of Cards: The
point value of a card does not depend on its suit. The numbered cards (i.e.,
"2" through "10") have a point value equal to their number
(i.e., a "2" is worth 2 points, a "3" is worth 3 points,
etc...). The "Jack"s, "Queen"s, and "King"s are
each worth 10 points. The "Ace"s are each worth 11 points. (Note that
unlike blackjack, an "Ace" is NOT worth either 1 or 11. It is
always worth 11.)
Rules of Play: The game is played as follows:
1. The dealer gives one card (face up) to every player.
2. The dealer gives another card (face up) to every player.
3. The dealer gives one card (face down) to himself/herself.
4. The dealer gives one card (face up) to himself/herself.
5. The dealer repeatedly asks the first player if he/she would like a card. If the player says yes, he/she is given one card (face up). If the total point value of the player's cards is less than 24, this step is repeated for this player.
6. The dealer performs the previous step for each player.
7. The dealer calculates the total point value of his/her cards. If the total point value is less than or equal to 19, then the dealer gives himself/herself another card and repeats this step.
A player wins
if his/her total point value is less than or equal to 24 and one of the
following conditions is satisfied:
The dealer's total point value is greater than 24.
The player's total is closer to 24 than the dealer's total.
|
Existing Components: Several classes related to card games have
already been written, including: Card.class |
Javadocs for these classes can be found at this link: PA4_javadocs
New Components: You must develop the following
classes:
|
Dealer |
|
GoldDukeDealer |
|
Player |
|
HumanGoldDukePlayer |
|
GoldDukeDriver |
These classes must not be in a package (and, when submitted, must be in the root directory of your diskette). Detailed requirements for each of these classes are given below. Details Overview: The Card, Deckand Tableclasses are illustrated in UML below:
An overview of
the "participant" hierarchy is illustrated in UML below:
The Player Class:
The Player class must:
1. Contain a one-parameter constructor that is passed the player's name.
2. Contain a toString() method that returns the player's name.
3. Contain an abstract method howManyCardsDoYouWant() that returns an int.
This class may contain other methods and attributes as well.
The
HumanGoldDukePlayer Class:
This class must extend the Player class and must:
1. Contain a one-parameter constructor that is passed the player's name.
2. Implement the method howManyCardsDoYouWant().
This method must output (to the console) the cards held by this player and the "face up" card helpd by the dealer. It may also output (to the console) the cards held by other players at the table. [This information helps the user decide what to do.] It must then ask the user if he/she wants a card and return 1 if he/she does and 0 otherwise. [Note: In GoldDuke, 1 and 0 are the only legal return values for this method.]
This class may contain other methods and attributes as well.
The Dealer Class:
The Dealer class must:
1.
Contain a
one-parameter constructor that is passed a Deck.
2.
Contain a dealToPlayer() method (that is passed a Player and either FACE_DOWN or FACE_UP) that gets the next card from the Deck and tells the Player to takeThisCard().
3.
Contains a dealToAllPlayers() method (that is passed either FACE_DOWN or FACE_UP) that calls dealToPlayer() for every player at the table. (The dealer can find
the players by asking himself/herself whoAreThePlayersAtYourTable().)
4.
Contains a dealToSelf() method (that is passed either FACE_DOWN or FACE_UP) that gets the next card from the Deck and tells himself/herself to takeThisCard().
5.
Contains a shuffle() method that tells the Deck to shuffle() itself.
6.
Contain an
abstract method dealHand().
This class may contain other methods and attributes as well.
The GoldDukeDealer Class:
This class must extend the Dealerclass and must:
1.
Contain a
one-parameter constructor that is passed a Deck.
2.
Implement the
method dealHand(). This method
must follow the "Rules of Play" discussed above.
3.
Overrides the showMeDownCard() method so that it always returns null (to prevent cheating by Player objects).
This class may contain other methods and attributes as well.
A Driver:
At a mininum, your classes must run correctly with the following driver: GoldDuke.java.
Your Test Drivers:
You should build test drivers that will at a minimum test
each of your new classes. We would also
suggest building a test driver to get to know the supplied classes better
before you begin your design.
Hints:
This application is reasonably large.
Hence, it will be easier to complete if you divide it into pieces. You should
stub-out all of your classes before beginning (though it is not required)
and build your test driver(s). Then, you should:
1.
Implement and
test the Player class.
2.
Implement part of
the HumanGoldDukePlayer
class. Specifically, implement the constructor but stub-out the howManyCardsDoYouWant()
method so that it always returns 0.
3.
Implement the Dealer class.
4.
Stub-out the GoldDukeDealer class. Include a simple dealHand method that can be used to test the Dealer class.
5.
Implement and
test the complete dealHand method
in the GoldDukeDealer class.
6. Implement
and test the howManyCardsDoYouWant()
method in the HumanGoldDukePlayer.
(You may want to construct a Scanner in the constructor of the HumanGoldDukePlayer class that you
will use in the howManyCardsDoYouWant()
method.)
Copyright © 2005