CSci A201/A597
Frequently Asked Questions on Lab #8

• Questions About Eliminate.java

1. The hints mention that an array will probably be useful. What kind of array?

   I used an array of type boolean to represent the pegboard. There are a total of ten holes on the board, so my array contains ten boolean variables, one for each hole. I use false to mean that the hole is not yet filled, so initially all elements of my array must be false when the game starts. Happily, this is the "default" value for boolean, so I needn't actually need to do anything special to initialize the board.

   You may find it more convenient to declare your array to be of length 11. This way there is a direct correlation between the number labeling the peghole and the index into the array (if you just ignore the zero element.)

2. How do I know when the player wins?

   The player wins when all pegholes on the board have been filled. This happens when 10 pegs have been placed successfully.

   Naturally, you want to avoid sprinkling the constant 10 throughout your program. What if you later decide to use 9 or 11 pegholes in your game? In run, I make the following declaration:

   int numHoles = 10;
   

   Then, I use numHoles whenever I need to refer to the size of my pegboard.

3. What do I do if the player clicks on the restart button?

   You need to "abort" the current game, resetting all the pegholes in the board to be "unfilled", and then start playing a new game. This may necessitate stopping one or more loops.

   I detect a click on the restart button inside my getClick function. This function handles all the mouse reads, ignoring all "bad clicks". If a legal, unfilled peg is clicked, then getClick returns the peg number (1, 2, 3, ... or 10). If the restart button is clicked, getClick returns a -1. This way the calling function can detect whether or not the restart button was pressed.

4. Exactly what are the "bad clicks"?

   The bad clicks can be determined by the x-coordinate of the click. These are all "bad clicks" and should be ignored:

   1. The x-coordinate is too small or too big, indicating that the click occured to the left of hole 1 or to the right of hole 10, respectively.

   2. The x-coordinate is too far away from the center of the "nearest" (see question 5) hole. That is, the length of the line between the center of the "nearest" hole and the click is larger than the hole's radius.

   3. The hole corresponding to the x-coordinate is already pegged.

   4. This hole corresponding to the x-coordinate is unpegged, but it is too big for the amount left on the current roll.

5. How do I know what hole is "nearest" to the user click?

   All I can say is that if you choose a good coordinate system, then this check can be done arithmetically. That is, it is not necessary to keep an array of the circles used to draw the holes. You should be able to compute the center point of the "nearest" circle based on the x-coordinate of the clicked point.

6. If you have just one unfilled peghole left and its number is lower than the next dice roll, can you put a peg in it and thus win the game?

   Sure, I'd call that a win...