SWE 2410 Lab 1: Checkers Pieces

In this lab, you will explore a maintenance task that does not take advantage of patterns. While we will study design patterns that are useful to this maintenance task later in this course, do NOT apply design patterns while working this lab. The goals of this lab include refreshing skills with Java and JavaFX. You should also think about how you might restructure the code we give you to make it easier to understand.

This is an individual lab. Consult with your instructor, not other students while working on the lab. In addition, follow your instructor’s directions on the version of Java and JavaFX to be used in this lab. If your instructor provides a starting version of the project (such as with GitHub Classroom), be sure to check that the project uses the correct versions of Java and JavaFX. This may require you to visit the project’s structure and the run configuration. If your instructor does not have alternative instructions, follow the directions at tayorial.com to create a new Java project. Create a subdirectory checkers under src and download and unpack the files in checkers.zip to this folder.

Build the project to see a six by six checkers board as shown in this image. The provided version of the game allows you to move pieces towards the other side of the board and to capture pieces by jumping them. It does not support multi-capture moves. It also does not support pieces being “kinged”; this is something you will change.

In checkers, pieces move diagonally, staying on the same color squares. Each move is to an empty square. When that square is adjacent, the piece moves just one square. If an adjacent square is occupied by an opponent’s piece and the square past that (in a straight line) is unoccupied, the piece can capture the opponent’s piece by jumping it. Pieces are either regular or kings; regular pieces only move forwards towards the opponent’s side, kings can move both directions. All pieces are regular at the start of the game, and a piece becomes a king when it reaches the far side of the board. For the full rules, and to get experience playing the game, you might check out cardgames.io/checkers/.

In this lab you will add support for kings. That is, once a piece reaches the far side of the board, the piece is “kinged” by placing a second checker on it. This signals the piece can move both forwards and backwards. As for regular pieces, kings must stay on the same colored squares, and they can only move to an adjacent square or jump one opponent piece.

Note there are many rules you will not implement. For instance, standard checkers allows you to make multiple jumps on the same move and requires that you jump a piece if there is at least one opponent piece available to jump. Your version of the game will only allow one single jump of an opponent piece and will have no constraint that you must jump oponents if possible.

Detailed steps

The following steps add king pieces to the game. All changes in this lab should be to the file Piece.java. If you feel you need to change other files, talk to your instructor to identify an alternative approach.

An example of a king is shown in this image – it is the piece with two ellipses.

  1. Identify the place in the code where the type of a piece is defined.
  2. Add a boolean at that place to track whether a piece is a “king”.
  3. Add an optional parameter to the Piece constructor that allows clients to create pieces as kings from the start. By default, pieces are not kings. As you do this, keep the DRY principle in mind!
  4. Identify the place in the code where it determines that a black piece has reached the last row of the board.
  5. Modify this code to identify when a red piece has reached the last row as it moves in the opposite direction across the board.
  6. When a piece reaches one of these positions, update the piece’s state to indicate it now represents a king.
  7. Identify the place in the code which creates the ellipse and places it on the screen. (See also step 9.)
  8. Modify this code to draw two ellipses instead of one for kings. Place the second ellipse (known as the “crown”) ten pixels above the first ellipse. To implement this, note the createEllipse method can be called twice. Alternatively, you might find it useful to introduce a Pane object to treat the pair of ellipses as a single item. One trick you might find useful is to create graphics objects but set them “invisible” so they do not show when drawn, then setting them “visible” later. No matter how you implement your solution, both ellipses must be selectable and both must be highlighted when selected. Be careful to match details. For example, the lower ellipse must be partially occluded by the upper and there needs to be an appropriate separation between the ellipses.
  9. Identify the code which places the ellipse at the correct location on the screen.
  10. Modify the code to place the “crown” piece in the correct place on the screen.
  11. Identify the place in the code where it determines if an ordinary move is valid.
  12. Update this code to work for kings; that is, so that kings can move diagonally towards either side.
  13. Identify the place in the code where it determines if a capture move is valid.
  14. Update this code to work for kings. As for regular pieces, a king must jump a single piece (on the diagonal) to capture it, but the jump can be towards either side of the board. In addition, add code to ensure a piece does not jump a piece of the same color.
  15. Identify the place in the code where a piece is visually removed from the board.
  16. Update this code to work for kings; both ellipses need to be removed when a king is captured.

The intent is that you would leave the general structure of Piece.java in place. However, you can rename methods and variables, introduce new methods and variables, split long methods, and add comments that help you understand the code.

A major portion of this lab is determining where to edit the code. Consult with your instructor if you are not confident about where to edit.

Submission instructions

If you are using a Git repository (for example, GitHub Classroom), be sure you have pushed a working version of your solution.

  1. If you are using Git from within IntelliJ, go to the Commit tab and ensure all changes have been committed and pushed. If you are using command line Git, type git status inside the repository folder to check everything has been pushed.

  2. Now that your local repository matches that on the Git server, build, run, and test your solution to make sure it is completely working. Fix any issues and go back to step 1.

  3. Test your solution thoroughly, including that both regular and king pieces can move appropriately and that the game does not allow illegal moves. For example, see what happens if kings revisit the row where they are crowned. There are a surprising number of elements in this code, and it is very easy to add code that breaks existing functionality.

  4. Visit your repository on the web (as opposed to using git or IntelliJ) and confirm that your code has been committed and pushed. Failing to push your code results in significant deductions, possibly even a zero.

See Canvas for additional directions on submitting solutions.