CIT 591 Assignment 10: Lines of Action
Fall 2005, David Matuszek

Purposes of this assignment:

General idea of the assignment:

Lines of Action is a game for two players, played with checkers on an ordinary checkerboard. Although it isn't well known, Lines of Action is actually a very good game.

With your partner, you are to write code to allow two players to play the game against each other. This involves setting up the game, allowing players to alternative moves, checking that the moves are legal, and determining when the game is over and someone has won. You will also need to write a simple GUI with a few buttons, and an area in which to display the board.

I will provide a graphical API that you can use to display the board.

Finally, you and your partner each, separately, write a Player class to play the game. Then have your two Players play against each other.

Details:

The Game

You can find an excellent description of Lines of Action at http://www.boardspace.net/loa/english/index.html.

You will need a class LinesOfAction to set up and control the game. More specifically, it should have these responsibilities:

The Players

You will need an abstract class (or possibly an interface) named Player. The primary responsibility of a Player is to decide what move to make.

There will be two classes that extend Player: one created by you, and the other created by your partner. Name your player class after yourself (for example, if I were to write one, it would be named DavidMatuszek). These two computer players will play against each other.

I suggest that Player be an abstract class rather than an interface because I think that you will want some utility routines to be used by each player; for example, a method to check whether a given move is legal, or perhaps one to return a list of legal moves for a given piece. Or you could decide you don't need any such methods, or you could put them in a separate utility class.

I'm leaving much of the design up to you and your partner. I strongly recommend that the two of you work out a good preliminary design before getting too much into the details.

The GUI

You will need a GUI. You should include controls that allow you to start a new game, to single-step through a game (allowing one player at a time to move), or to let the game run without interruption. Please also include a "speed" control for running the game automatically.

I am providing an API that I wrote for displaying board games, BoardGame.zip. You will need to explore this API in some detail, but here's what you need to get started:

There is a Board class for creating a game board. Board subclasses JPanel, so you can put a Board object directly in your GUI. This class will automatically display all the pieces you put on it, and will animate their movements from one board location to another.

There is an abstract Piece class for creating playing pieces. It is abstract because it declares an abstract draw method for drawing a particular playing piece. (However, there is also a concrete RoundPiece class which extends Piece, and this is good enough for the current assignment.) There are methods to place pieces on the board, move them around, and remove them.

There are methods you can use to easily find out what pieces are in what board locations, so you don't need to keep track of this information yourself. The entire game state (except for whose turn it is) is maintained by the game board API.

Notes

In class I discussed the Model-View-Controller (MVC) pattern. This assignment uses a different design pattern. But don't worry; there will be one more (small) assignment that does use MVC.

You will need to check when the game is over. This is more difficult than you might expect. Notice that a move by one player could result in a win for either player.

Grading:

Your grade will be based partly on the game as a whole, and partly on the Player subclass that you write. Your Player subclass must make only legal moves, but there is no requirement that it make good moves. If you want to get competitive and write a better player than your partner does, that's fine; but grading will not be based on whose player plays better.

Due date:

Thursday, December 1, before midnight. As usual, please submit one zip file containing everything to Blackboard.

Note that this gives you two weeks, but there is a Thanksgiving break in the middle.