Monte Carlo Solitaire

Objectives

• To gain experience designing, coding, and testing classes including accessors, mutators, constructors, constants, and proper declaration of public/private methods and instance variables
• To gain experience using composition
• To gain experience using classes designed and implemented by someone else
• To gain experience using objects and object references in a simple application
• To appreciate the value of writing reusable and easily modifiable code
• To become familiar with standard Java documentation

You can play a competitor's version of Monte Carlo Solitaire here. Our version of the game is, of course, far superior, since it includes more functionality, such as help. Also note that the rules for our competitor's game are slightly different than ours. Here is a sample screenshot of our GUI.

1. How is the game number chosen and how is it used?
   The game number is chosen by the GUI. The first game played is #12345. The game number is used to initialize the random number generator used to shuffle the cards.
2. What does the "Hint" button do?
   When the "Hint" is pushed, a pair of cards that may be removed are highlighted (their borders turn red). If no pair of cards can be removed, a beep is sounded. (+5 points extra credit if implemented)
3. What does the "Help" button do?
   The "Help" button displays a pop-up window that briefly explains the rules of the game.
4. What does the "New Deal" button do?
   The "New Deal" button abandons the current game and starts a new game.
5. What does the "Replay" button do?
   The "Replay" button restarts the current game from the beginning.
6. How do I win the game?
   By removing all the cards from the tableau, hence earning a score of 52.
7. What's the tableau?
   The cards that are face up in a rectangular arrangement (usually 5 x 5).
8. How do I remove cards from the tableau?
   Clicking on a card highlights that card by changing its border to red. If the next card clicked is touching the first card and is of the same rank, the cards are removed. If the second card is not touching the first card or is not of the same rank, a beep is sounded. Suits are not relevant when choosing cards to remove.
9. When are two cards touching?
   Two cards are touching if they are next to each other horizontally, vertically, or diagonally. Cards at the top and bottom of a column, or the ends of a row, or the opposite corners of the diagonal are NOT considered touching. That is, the columns, rows, and diagonal do not wrap. Note that this is different from the competitor's implementation in some ways.
10. What do I do when I can't remove any more cards?
    Push the "Consolidate" button. This button always moves all cards in the tableau left and up towards the top of the tableau. If there are any cards left in the deck, then this button also deals cards from the deck to refill the bottom of the tableau.
11. What if there aren't enough cards in the deck to fill the bottom of the tableau when I push the "Consolidate" button?
    If there are too few cards in the deck to complete the tableau, the remaining cards are dealt to complete as much of the tableau as possible.
12. How does my score change?
    One point is awarded for each card removed from the tableau.

This project is considered an OPEN project. Please review the open project policy on the course website.

Our application consists of many classes. Some of the classes have already been written by other team members. Some of the classes will be written by you. Some classes must support a specific API, and still others may be designed and implemented as you see fit.

1. Ms. Mitchell's public directory for this project is /afs/umbc.edu/users/s/m/smitchel/pub/202/Proj2/.
2. A directory named cards that contains card images to be used for this project can be found in Ms. Mitchell's public directory. Copy this directory into your Eclipse project so that the cards directory is at the same level as the src directory. The cards directory is also available in tar and zip formats.
3. You must write main in the Coordinates class, the Game class, and any class you design and implement as a means of unit testing. As discussed in class, each main should instantiate an object and invoke all public methods defined for the class, printing the results to System.out.
4. The screenshot of our GUI shows the tableau for game #12345. Your application should duplicate this tableau when the first game is played.
5. The algorithm below, which shuffles an array of integers, must be adapted and implemented to shuffle the cards to start a new game of solitaire. This algorithm is known as the Fisher-Yates algorithm, was first designed for computers by Richard Durstenfeld, and popularized by Donald Knuth.
   1. A[0], A[1]... A[n-1] is an array of integers
   2. Let N = n-1
   3. Pick a random index, k, between 0 and N (inclusive).
   4. Swap the values of A[k] and A[N].
   5. Decrease N by one.
   6. Repeat from step (c) until N is less than 1.
   To choose a random index (step c), use the nextInt method of the Random class found in the Java library. (Note: Read the description of the nextInt method carefully!)
6. Per the course standards, all class comments must contain the class invariant and all method comments must include pre- and post-conditions.
7. Make all .java files part of package "proj2".
8. In order to duplicate game #12345 as required above, it is necessary that the deck of cards be initialized appropriately before shuffling. Initialize the deck of cards in the order Ac, 2c, 3c, ..., Qc, Kc, Ad, 2d, ..., Qd, Kd, Ah, 2h, ..., Qh, Kh, As, 2s, ..., Qs, Ks.

• Your code may assume we are using a standard 52-card deck.
• Develop your classes slowly. As you write new methods, write code in your class' main to test them.
• Write the toString method for each class. If it's not required, it can be used as a debugging tool to print the values of instance variables or other important information.
• Add precondition checking to each of your methods last. Save, compile.
• DO NOT try and implement an ENTIRE class at once.
• Use incremental development. Develop one method at a time, write code that will thoroughly test it, run and test it, then move on to another method.
• TEST your program thoroughly.
• Do not cheat -- you WILL be caught. Do not look at another student's code -- it is very tempting to "borrow" an algorithm. Do not show your code to another student. Use the tutors, TA's, and instructors.
• This is a GUI-based project. Therefore, to test your code once you've moved it to your GL account, you must use a Linux machine in one of the labs to run it. You will not be able to run your program on GL from home using PuTTY or TeraTerm.

1. submit Game.java, Coordinates.java and the .java files for any class(es) you design and implement.
2. DO NOT submit any .java files you copy from Ms. Mitchell's public directory. These files should not be changed by you and so need not be submitted. If you submit these files, they will be removed from your submittal directory.
3. submitls cs202 Proj2 to verify that your files are in your submittal directory.

You can check to see what files you have submitted by typing

Remember -- if you make any change to your program, no matter how insignificant it may seem, you should recompile and retest your program before submitting it. Even the smallest typo can cause compiler errors and a reduction in your grade.

Avoid unpleasant surprises!