CSSE 220: Object-Oriented Software Development
Crazy Eights

Goals

This exercise will help you gain experience with:

• Pair Programming
• Object-Oriented Design
  • Fields, constructors, methods.
  • Constructing objects by using the new keyword
  • Referencing instance fields and methods by using the this keyword
  • Creating your own classes based on requirements for the application

Grading rubric

Points Layout:

• 24 pts - Functioning Game:
• 24 pts - Object-Oriented Design (use multiple classes, don't put everything in CrazyEights):
• 12 pts - Tests and Fixes for possible issues (4 points each)

As always, use good style and JavaDoc comments, or you'll lose points

• Your score may be reduced by as much as 40% for each stage that uses poor style.
• Control-shift-F is helpful to format the file you are working on!

For any points deducted, the grader will put a CONSIDER tag saying how many points were deducted and why.

Here is a link to the General Instructions for Grading Programs.

Getting started

You will work with a partner, so you'l need a new repository that you both have access to. We've made one for each pair for this project. This document lists the name of the repository you need to connect to (like you did on day 1 of this course, so you may need your password). Find your username and your repo name is to the left, like csse220-201710-crazyeights17. Checkout the CrazyEights project inside.

Overview

You will implement this project from a set of requirements provided below. If you have questions on these requirements, please ask them ASAP to make sure you're implementing the application correctly.

After you have read and understood the requirements, you and your partner should follow the general development phases described below NOTE: You can go back to any phase at any time to make updates if you run into issues, this happens all the time and is normal in software development.

• Design:

  Pull out what you think are the classes and objects that would help solve the given problem.

• Development:

  Implement the classes detailed in the design phase. Update the design as needed for issues found during development (this is totally normal).

• Testing::

  While you should be running the unit tests throughout your development phase, after development is completed we'll have you write some of your own tests to check for edge and errors cases. Also, you should be "ad-hoc" testing (or running and playing with the application) in this stage to make sure it works as you expect.

Rules of the Game

The object of the game is to get rid of all your cards first.

Below are the basic rules of the version of the game Crazy Eights that you'll be implementing. These may be slightly different than the version of the game you're used to, so be sure to read them carefully and implement these rules.

• The game is played with a standard deck of 52 cards. NOTE: Your version will have the option of specifying a deck for testing purposes, this deck may not contain all 52 cards.
• The game supports 2 - 4 players
• Each player begins with 7 cards.
• The remaining cards (called the draw deck after this) are placed so each player may draw cards from the deck.
• At the beginning of the game, the first card from the draw deck is turned over to begin the discard pile.
• Cards may be discarded using the following rules:
  • A card may be discarded if it's rank (number) matches that of the top discard.
  • A card may be discarded if it's suit matches that of the top discard.
  • Eights are wild and may be discarded at any time. When an 8 has been discarded, the suit of the eight becomes the suit that must be matched on the next play.
• Play rotates through each player and they can either play a card, or if they do not have a playable card, they can draw a card until one is playable, and then play that card (see below for the rules for a playable card).
• If the draw deck runs out of cards, the discard pile (minus the top card) should be reshuffled and replace the draw deck.
• Don't worry about the case where all cards are in hand and there is nothing left to draw, this is very unlikely to happen

Requirements

The following are the requirements your application must support:

NOTE: Parts of some of the requirements may already be implemented for you. Before you begin your design phase, be sure to look at what code we've already provided.

• The game shall support command-line input for the following commands:
  • start-game #

    Where # is a number from 2-4 representing the number of players in the game

  • start-game # deck-name shuffle

    Where shuffle is either true or false, indicating whether or not the deck should be shuffled. This is handy for unit and ad-hoc testing.

    start-game should be called only once per run of the application.

  • play-card card-text

    Where card-text is the text of the card to be played for this turn. For example, to play a six of hearts, the command issued would be "play-card 6H".

  • draw-card
  • exit
• The start-game command shall begin a new game with the specified number of players.
• When a start-game command is given with no deck name, the game shall use a standard 52 card deck.
• When a start-game command is given with a non-empty deck-name, the game shall use the specified deck instead of a standard 52 card deck.
• When a start-game command is given with a shuffle flag of true, the game shall randomize the deck order before dealing the cards.
• When a start-game command is given with a shuffle flag of false, the game shall leave the cards in the their original order for dealing.
• When cards are dealt to players, the game shall deal one card to the players in the order Player 1, Player 2, Player 3, Player 4, Player 1, etc., (excluding Player 3 and 4 as needed based on the number of players in the current game).
• When a play-card command is given, the game shall determine if the specified card is held by the current player.
• When the card specified in the play-card command is not a card held by the player, the game shall inform the user that the card specified is invalid.
• When a play-card command is given, the game shall determine if the specified card is valid for play.
• When the card specified in the play-card command is not valid for play, the game shall inform the user that the card specified is not playable by displaying the message "Card was not valid for play. Please try again.".
• When the card specified in the play-card command is valid, the game shall make the card played the top card in the discard pile.
• When the card specified in the play-card command is valid, the game shall switch turns to the next player in line.
• The game shall track whose turn it currently is.

  Note: If there are two players, play goes from Player 1 to Player 2, then back to 1, etc. For 3, it's 1, 2, 3, then back to 1, and so on.

• When the draw-card command is given, the game shall take the top card from the draw deck and add it to the current player's hand.
• When a player is out of cards, the game shall inform the player that they have won.
• When a player has been informed they have won, the game shall NOT end the current application, and be ready for a new start-game command to be issued.
• When the exit command is given, the game shall end the current application.
• The output for each command should match the example game shown here.

  NOTE: the exit command does not need additional output. Also, the variations on the start-game command should have the same amount of output shown here.

Here's an example of the output you're expected to have.

Testing

With your partner, find at least 3 things that could cause errors in your code. For each one, perform the following steps:

1. Identify a possible error condition (such as errors with user input, bad command timing, invalid commands, etc.).
2. Write a test case that exposes this issue. Write the test case first and determine what you would like your code to do when this happens. The message to the user is your choice, but your application should not crash.
3. Run your test case and verify that it fails (since you wrote the test case before you fixed the issue in the code).
4. Fix the code.
5. Run the code again and verify that the test passes.

Turn-In Instructions

Add your files to source control: Right-click on the project, then select Team --> Commit. Be sure to add a brief commit message that describes what you have done. If you choose to commit a single file instead, you can right-click on that file and select Team --> Add to Version Control. However, you must commit that file in order for it to be posted on the SVN server.

Commit your project to your team repository often is strongly encouraged, not only when you are done.