GitHub Classroom URL: https://classroom.github.com/g/v_fSmXGK

Objectives:

• Use two-dimensional arrays
• Use the Model-View-Controller design pattern
• Modify a Java Swing GUI
• Examine how inheritance and polymorphism are used in the Java Swing library
• Additional practice writing unit tests
• Provide experience developing challenging algorithms
• Provide experience writing a complex Java class

Due Dates:

• Demonstrate that the dice can roll: Wednesday, 3 June 2020, 8:00 am
• All automated tests pass: Monday, 15 June 2020, 8:00 am
• Final submission: Monday, 22 June 2020, 8:00 am

Problem Statement

You will implement and thoroughly test a program that allows users to play a single-player game of the Qwixx dice game.

You are strongly encouraged to work on this project in pairs.

Preliminaries

• Begin by learning the rules of Qwixx. This video demonstrates a completed project and highlights the rules of a single-player game. You may also want to review the formal rules for a traditional multi-player game.
• Next, clone the starter code and make sure you understand how it works. In particular, make sure you understand:
  • What Controller code runs when buttons and boxes in the view are clicked (and why).
  • How the View works (e.g., how the components are organized and updated).
  • How QwixxModel and ReadOnlyQwixxModel are related, and why the View uses ReadOnlyQwixxModel.
• Make sure understand what each QwixxModel and ReadOnlyQwixxModel method should do. (If you don't your method may not pass my tests.)

Rules

• You are strongly encouraged to work on this project in pairs.
• Your View may only read the Model. It may not directly manipulate the model. Do not add a QwixxModel variable to your view. Do not add any mutator methods to ReadOnlyQwixxModel.
• Do not change the signatures of any existing QwixxModel methods. (Doing so will break my tests.)
• Your model's die values and score values should be stored as integers, not Strings.
• Your code must follow good coding style and practice including:
  • inner explanatory comments where appropriate,
  • use of descriptive variable and method names,
  • use of constant where appropriate, and
  • use of private "helper" methods where necessary to avoid duplicate code.

Workflow

You should follow a test-driven development workflow. However, instead of writing all the tests for the entire project, just write them one feature at a time. I suggest you test and implement features in this order:

1. Roll the dice: Write tests for, then implement QwixxModel#rollDice and QwixxModel#scoreValues. When complete, pressing the Roll button should cause new die values to appear in the view. This should be complete by Wednesday, 3 June 2020, 8:00 am
2. Select a number: Write tests for, then implement QwixxModel#numberSelected and QwixxModel#numberValues. At this point, pressing a number box should cause the View to display an 'X'. At this stage, don't worry about implementing the rules: Allow any number box to be selected. (Also, don't write too many tests, since you will have to update them soon.)
3. Only allow number boxes to be selected if they correspond to the current values of the white dice.
4. Only allow number boxes to be selected if they correspond to the current values of the white dice and no boxes to the right have been selected. (Now is a good time to write some more thorough tests.)
5. After selecting number box based on the white dice, the next number box selected should be based on the colored dice.
6. After selecting a number box, update the score. The score for a row is the summation of the number of boxes selected (1 box => 1 pt; 2 boxes => 3 points; 3 boxes -> 6 points, etc.)
7. Implement the "can" methods (canSelect, canPassWhite, etc.) and only allow operations to occur in the correct order (dice must be rolled before selecting white dice, white dice must be used before colored dice, colored dice must be used before rolling again, etc.). To enforce the play order, have QwixxView#update enable/disable buttons based on the "can" methods.
8. Implement QwixxModel#passWhite and QwixxModel#passColor so that users can elect not to select number boxes.
9. Implement the penalty for not selecting any number boxes during a roll.
10. Implement game over. (The game is over when either (a) all four penalty boxes are checked, or (b) the rightmost column in each row is crossed out.)

"Bonus" Features

Implementing the basic game only covers 90 of the 100 points in the rubric below. To get the full 100 points, you need to add one or more "bonus" features of your choice. You can choose from one of the options below, or propose something else. (Notice that not all the features below are worth exactly 10 points.)

Potential bonus features:

• (3 pts) Change the label on boxes that may no longer be selected to a '-'. (Remember, the logic for this should go in the model.)
• (5 pts) Display the dice with pips instead of numbers.
• (10 pts) Highlight the current valid moves. (E.g., change the border color on the number boxes that may be chosen.)
• (10 pts) Prevent users from selecting the rightmost box unless five other boxes have already been selected.
• (20 pts) Implement a two-player game. (You will need to show two boards at once. An quick and easy approach is to instantiate two separate View objects which will create two separate windows. A better approach is to create a additional class so you can display two boards in the same frame.) Make sure you fully understand the rules of a two player game. (Yes, completing this is worth extra credit.)

It is possible that your bonus feature will cause my tests to fail. Before beginning work on the bonus feature:

1. Make sure your code passes all of the automated tests.
2. Create a new branch named baseline (run git branch baseline). This will make it easy for me to re-run the instructor tests on the "base" project if necessary.
3. Take a screen snapshot of your passing tests.

In other words: Make sure your code passes the automated tests, and save that passing code somewhere before making changes that are potentially incompatible with my tests.

Grading Rubric

Note: Points will be deducted for insufficient testing and/or not following a TDD workflow as discussed in class.

Timeliness is based on when your code passes the automated tests:

Submitting your Project

To submit your project:

1. Make sure your name(s) appears in a comment at the top of each .java file.
2. Double check that your bonus feature has been thoroughly tested. (Remember, the auto-grader does not check these features.)
3. Clean up your code (check for proper indention, long lines, etc.)
4. Make sure your code meets the standards given at the end of the "Rules" section above.
5. Fill out checklist.txt and add it to your repository.
6. Include a video/screencast demonstrating your project. This screencast should
   1. Demonstrate all the baseline features/rules of the game,
   2. Demonstrate your bonus feature, and
   3. Highlight / show off the features of the project you are most proud of.
7. Commit/push with "[Grade me]" in the commit message.

Updated Monday, 17 May 2021, 3:25 PM