Project 0: Checkers61b

1. Background

We all love the classic game of Checkers. In this project, we add a twist by introducing two new pieces: Bomb Pieces and Shield Pieces. For details on how these pieces differ, see Rules of Checkers61b. Starting from scratch, you will implement your own GUI-supported version of this game. You should use the provided StdDraw library to implement the GUI.

2. Rules of Checkers61b

Both players start with the same setup as checkers, as shown in this image:

The board is an 8x8 board, with water and fire pieces on the top and bottom. Each player starts with pieces in the three rows closest to them. The front, middle-most row consists of Bomb Pieces, the second row consists of Shield Pieces, and the back, edge-most row consists of normal pieces. Only every other space on the Board is used, and all pieces can only move and capture diagonally. If a capture move is available, the player is not required to capture. The bottom left corner should have a "black" square, and should contain a normal fire piece.

Movement of pieces are the same as classic Checkers. In all new games, fire team makes the first move. Besides king pieces, fire pieces always move upwards (like flames) and water pieces always move diagonally downwards (like rain). Upon reaching the topmost row, fire pieces become "kinged" and are allowed to move not only diagonally forwards, but also diagonally backwards. The same can be said for water pieces that reach the bottommost row. Capturing a piece works exactly the same as in classic Checkers. You may perform multi-captures like in classic Checkers.

Normal Piece

Moves diagonally, and captures diagonally. Normal pieces can multi-capture, meaning if performing a capture lands the piece in a position ready to perform another capture, that piece may choose to do perform another capture in the same turn.

Shield Piece

A normal checkers piece, except that it cannot be killed by bomb explosions. However, they can still be normally captured by any piece (including bombs).

Bomb Piece

A normal Checkers piece with a twist. Performing a capture with a bomb piece causes an explosion in the destination landing. Explosions kill all pieces adjacent to the landing (all non-shield pieces within a 3x3 block centered at the bomb's final position), as well as the exploding bomb. If a fire bomb explodes, it will kill all fire and water non-shield pieces in range. Chain reaction explosions do not occur. If one bomb destroys another bomb via explosion, a second explosion does not occur. Bomb pieces cannot perform multi-captures, because they explode after the first capture. See the below images for an example of an explosion:

Explosion Example

The three images below is an example of an explosion example. Suppose that the blue player is Anusha, and the red player is Leo. In the first image, Anusha ponders her move. In the second image, Anusha has selected the blue piece (highlighted). She’s about to perform a capture. In the third image, Anusha’s water bomb piece has captured a fire bomb and caused an explosion that effectively killed two additional fire bombs. Notice that Leo’s fire shield has survived the explosion. It is now Leo’s turn (after spacebar is pressed).

King Piece

Any piece can become "Kinged" upon reaching the furthest row. King pieces can move and capture in four directions instead of only two. For testing purposes, it is advised to place pieces on the penultimate row and crown them via a game move (as opposed to placing them on the final row directly). A piece may capture, promote to a king, and capture again in the same turn if the orientation of the Board permits.

3. The GUI

This spec will begin by explaining how the system should work as a whole. When it comes to implementation, you should consult the recommended order (below). While this section makes for nice narration, it's not the order in which you should work.

You will be provided a, with all the methods you’ll need for creating a functional GUI. Do not modify any methods in In your Board class, the main method starts a new game of Checkers61b in GUI mode and doesn’t return until the game is over. For optimal visual appeal, we recommend having red/gray (instead of red/black) squares, though you're welcome to use whatever colors you'd like. The GUI coordinate system should work as follows: A piece on (0,0) lies on the bottom left corner. A piece on (7, 7) lies on the top right corner. A piece on (0,7) lies on the top left corner. A piece on (7,0) lies on the bottom right corner.

When a user clicks on a square:

When a user presses spacebar:

Here are some methods you will find useful for creating your GUI. These methods should be preceded by "StdDrawPlus." if you wish to call them in another class.

The GUI will not be tested by the release ag tests. It may (or may not) be tested by the secret tests.

4. Required Methods / API

In addition the methods described below, you are strongly encouraged to create additional variables and helper methods as necessary. You are not allowed to create additional public methods. The Autograder will be very upset with you. You may only add new private methods and private variables.

5. Advice

Start early! Don't underestimate the project. Playing checkers is easy. Making it is harder than it seems. We will provide a staff version of the game for you to understand how your program should behave. Make your method calls consistent. Calling canSelect on the same piece multiple times in a row should return the same answer. Advice steps after #4 are likely to undergo modification.

Running the Given Staff Solution

We have provided a staff solution for you to get a feel for the rules. In order to run this, you should first ensure that your skeleton repo is up-to-date and on your CLASSPATH, as taught in lab 1c. (You may update your skeleton by calling git pull origin master from within the folder. You want to make sure you have a skeleton/lib/staffp0_obf.jar file). You should also ensure that you are in a directory that is parallel with an img/ directory (if you ls, you can see img/) so that the program can use the images of the pieces. This may be either from skeleton, or even better, inside your own aaa/proj0/ folder. From a correct directory, run the staff solution by using:

java staffp0.StaffBoard

If you get a "Could not find or load...", your CLASSPATH is probably set up incorrectly. You should fix that. Inappropriately, a temporary workaround is to manually include the staffp0_obf.jar in your class path. Assuming both img/ and staffp0_obf.jar are visible in an ls command, run:

java -cp staffp0_obf.jar staffp0.StaffBoard

Remember to look at the GUI tips if you find yourself stuck.

  1. Read the spec and understand the overall picture. Try out the example solution.
  2. Write JUnit tests for the Piece class for all methods except the move() method. Create the Piece class and implement its methods, starting from the simple and working your way to the more complicated. Do not add new public methods. Don't implement move() yet.
  3. Create so that when you type java Board, it displays a blank 8x8 board. (You will be implementing parts of your board as you go along). See for inspiration. You do not need to cite this assistance in your source files.
  4. Modify Board so that it starts up with the correct initial configuration of the board (first image in this spec). We do not recommend JUnit tests for this task, since it is likely to be easier for you to visually verify the correctness compared to writing a test. You should only do testing when you think it will save you time.
  5. Work through the Board methods. pieceAt and place are probably a good place (ha ha) to start. For the more complicated methods, it is highly recommended that you test these using JUnit instead of using your GUI and clicking around like mad to test. This will make you become insane. Don't forget about the false option in the Board constructor. It may be particularly handy for testing.
  6. Handle canSelect and select. (First check if it's the right player's turn, then check other conditions.)
  7. Implement canEndTurn and endTurn methods.
  8. Handle piece movement, regular piece capturing, and finally bomb piece capturing.
  9. Polish up your JUnit tests to make sure you've handled edge cases.

Bonus for Bosses

6. Submission

Project 0 is due Friday, February 13th at 11:59:59pm. Submit to your three letter repo on GitHub. Make sure to push your final submission to a submit/proj0 branch. (It's recommended you finish all of your testing and revisions before submitting to the submit branch.)