Project 1: Checkers61bl

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 from normal pieces, see Rules of Checkers61bl. You will be implementing your own GUI-supported version of this game. You should use the provided StdDrawPlus library to implement the GUI.

Warning: This project is time consuming and significantly more challenging than anything that you have seen so far in this course. It is also an individual project. Do not share code with other students. You can find the (bare-bone) starter code here.

2. Rules of Checkers61bl

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

initconfig

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, pieces can only move one square diagonally. 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 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, by jumping over an opponent's piece. 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.

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 (pieces within a 3x3 block centered at the bomb's final position), as well as the exploding bomb. Howevever shield pieces will not be killed by a bomb explosion. Bombs do not discriminate; all non-shield pieces in the blast zone, regardless of if they are water or fire, are killed in a bomb explosion.

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.

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).

Explosion Example

The three images below is an example of an explosion example. Suppose that the blue player is Ross, and the red player is Armani. In the first image, Ross ponders his move. In the second image, Ross has selected the blue piece (highlighted). He’s about to perform a capture. In the third image, Ross’s water bomb piece has captured a fire bomb by moving diagonally down to the right and caused an explosion that effectively killed two additional fire bombs. Notice that Armani's fire shield has survived the explosion. Also notice how there is no chain reaction. Just because a bomb has been destroyed in an explosion does not mean it goes off and causes its own explosion. It is now Armani's turn (after spacebar is pressed).

King Piece

Any piece can become "Kinged" upon reaching the furthest row from its origin side. King pieces can move and capture in four directions instead of only two. 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 StdDrawPlus.java, with all the methods you’ll need for creating a functional GUI. Do not modify any methods in StdDrawPlus.java. In your Board class, the main method starts a new game of Checkers61bl 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. In fact, you may even use your own pictures if you so wish. 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:

Introducing StdDrawPlus

StdDraw is an library that was orginally from Princeton. We have slightly altered it for the purposes of this project, resulting in StdDrawPlus. The StdDrawPlus library is full of methods that will aid you in creating your GUI. Here are some methods you will find probably useful. These are static methods and thus to call them should be preceded by "StdDrawPlus". See DemoBoard.java for a more concrete example on how to use this library.

4. Required Methods / API

There methods/files are provided in the skeleton code and must be implemented. In addition to these methods, you are strongly encouraged to create additional variables and helper methods as necessary. Methods can be public, though try your best to make as many private as possible. Variables should not be public.

Board.java

Piece.java

ShieldPiece.java

BombPiece.java

5. Advice

Start early! Don't underestimate the project. Playing checkers is easy. Making it is harder than it seems. 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.

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

  1. Read the spec and understand the overall picture. Understand how inheritance works in this system. Go through the different Pieces and understand what makes each Piece special.
  2. Create Board.java 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 DemoBoard.java for inspiration. You do not need to cite this assistance in your source files.
  3. 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.
  4. 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.
  5. Handle canSelect and select. (First check if it's the right player's turn, then check other conditions. These methods can be harder than you expect) Remember to make the selected square white.
  6. Implement canEndTurn and endTurn methods.
  7. Handle piece movement, regular piece capturing, and finally figuring out explode() and getBlownUp().
  8. Polish up your JUnit tests to make sure you've handled edge cases.

Bonus for Bosses

6. Submission

Project 1 is due Tuesday, July 7th at 11:59:59pm. Submit Board.java, Piece.java, BombPiece.java, and ShieldPiece.java as proj1.