Objectives
- an introduction to creating GUI applications using Java Swing
- review implementing Java classes
- separate model and view in an object oriented design
Specifications
Your solution must include ALL of the following requirements.
- Remember that it is critical to separate the Model and View. For this
project, you should have a model class that keeps track of the score,
the current state of the game, and validates each scoring category.
There should be several public and private methods implemented for this
class.
- Design and implement a GUI game board that has five cards, a JComboBox
for the player to select 1 - 5 credits, a JLabel to display the current
credits, and two buttons for the Deal and Draw.
- Use the GVcard and GVpile classes from the GV
Java Component Library
- Create an attractive interface
- Strive to limit the player's confusion by clearly labeling buttons,
enforcing game rules, and providing clear error messages
- provide a clever window title to personalize your solution
- make sure that none of the rules can be broken such as dealing more
than twice. All error messages should be displayed using JOptionPanes
- Warning: This game is intended for education and entertainment purposes
only. It can be quite addictive!
Rules of the Game
- players begin with a balance of twenty credits
- each round begins with a freshly shuffled deck of 52 cards
- the player selects an amount to wager (1 - 5 credits)
- the player presses DEAL and five cards are dealt face up, the player's
balance decreases by the amount of the wager. Provide a popup warning
message using JOptionPane if the amount of the wager is less than the
current balance.
- the player chooses to hold zero or more cards by clicking on each
card
- the player presses DRAW and the unselected cards are replaced with
fresh cards
- the game determines the highest payout based on the five cards and
the size of the bet
- the updated balance is displayed on the screen
- play continues until 1) player runs out of credits, 2) player selects
quit for the file menu, 3) or player selects New Game from the file
menu and starts over with twenty credits.
Pay Schedule
The following amounts are paid assuming a one credit wager. Higher wagers
are multiplied accordingly.
- a pair of jacks or higher (1)
- two pairs (2)
- three of a kind (3)
- straight (4)
- flush (6)
- full house (9)
- four of a kind (25)
- straight flush (50)
- royal straight flush (250)
Extra Challenges
If you have extra time or extra motivation, consider implementing the
following feature(s). No extra credit is available other than the pride
you will feel.
- Keep track of the highest score along with the player's initials.
Prompt the player for her initials if her score is the new high. No
bonus points are available for this extra challenge.
- Automatically highlight the cards for the player if a scoring category
is obtained after the initial deal.
- Play sound when the player wins a hand.
Phase I Requirements
It is important that a professional programmer begins by designing a
solution instead of writing code right away. Completing the following
documents will require you to think about your solution thoroughly before
coding. I will be grading not only the content of this document but the
presentation. This means you should pay attention to spelling, grammar,
and page layout. Your documentation should include the following pieces
(in this order):
- attractive cover page with your name (graphics add a certain flair
but are optional)
- Preliminary Development Journal - document each work session including
date, amount of time, and the activity. Explain design decisions and
any problems you solve. XP team members must maintain their own development
journal.
- a printout of the GUI prototype
- Use "dia" to draw a class diagram that includes all classes
in your design. Do not overlook JFrame, JButton and other GUI component
classes. The class diagram should have at least six classes. Remember
to provide your name.
- the design document should include preliminary code with Javadoc comments.
Documentation should include class definitions, instance variables,
and 'stubs' for each method. This approach is discussed in chapter 4
of your textbook.
- a testing plan: a specific plan of how you will ensure that "everything"
works; a sequence of acceptance test cases that have a rationale, description
of inputs, and expected results.
Phase II Requirements
Your final document should include the following information (in this
order):
- attractive cover page with your name (graphics add a flair but are
not required)
- Final Development Journal - document each work session from phase
1 and phase 2 including date, amount of time, and the activity. Explain
design decisions and any problems you solve. XP team members must maintain
their own development journal.
- Revised Class Diagram - redraw the diagram to accurately reflect the
final implementation
- Source Code - printout of your elegant code for each class that you
write
- Demo - be prepared to demo your program in the EOS lab
- insert your partially completed Grade Sheet from Phase I inside the
cover. Please do not staple it.
Grading Criteria
|