- Email your assignment to email@example.com.
- Attach the source code of your Java application. Send me only the source code (.java files); do not include the .class or any other files. Do not zip or otherwise bundle the .java files. Send me all the files needed to run your program.
- Include a fully-qualified URL to your working applet on the Web. (Include the http://... part.)
Except for the requirements listed in the Grading section below and on Nickles's assignment page, I am flexible on how you implement this program. You may use Nickles's GUI code or his other code examples however you see fit.
Game board modeling and mechanics
The most difficult part of this assignment is probably determining how best to model the game board so that you can determine all the other information you need. Assuming you use the ColumnCanvas class, there are a number of design possibilities for implementing the interface:
- You could simply have each ColumnCanvas report to your GameBoard when another pieces has been added. The difficult part here is how to determine which ColumnCanvas is reporting that it has a new piece.
- You could keep your ColumnCanvas and GameBoard very separate. Remember that you can register more than one listener for an event. It would be possible to have a ColumnCanvas listen for clicks in order to start animating the pieces and also have the GameBoard listening for clicks on the canvases to add a piece to its own internal representation.
- You could make the GameBoard a collection of ColumnCanvases and actually have each ColumnCanvas keep track of its own pieces.
- There are probably other design options...
Related to this is how to model the board in your GameBoard class: a two dimensional array is probably a good idea, but of what? ints? booleans? Colors? Chips? An array of ColumnCanvases which in turn each contain an array of Chips? You may want to use a different data structure instead. That's fine. There are many options. Some may be easier to build as pieces are added, but may be harder to use when it comes to the win algorithm.
Keep in mind that only the most recently added chip can result in a win situation. (Otherwise the game would already have finished.) And that most-recently-played chip must be part of a straight line of 4 pieces. That straight line must be N-S (vertical), E-W (horizontal), NE-SW, or NW-SE (diagonal).
Remember when you're checking that you need to avoid running off the edge of the board or into an empty space.
If you write a recursive algorithm, it is very likely to naturally include backtracking. For example, if you recursively check for a N-S win situation from the current chip, and don't find one, the recursive calls will return unsuccessfully. You can then try to recursively check for a E-W win situation. This is backtracking--some of the recursive calls return unsuccessfully, so you make further recursive calls in the hopes of finding some other path. If all possible paths return unsuccessfully, you know this is not a winning move.
Out of 10 points:
- 1.5 - Complete and valid submission.
- Includes all the needed files. Compiles and runs. Includes a link to a working version of the applet on the web.
- 2.0 - Documentation and coding standards.
- 2.0 - Working Connect Four game mechanics
- Your game needs to model the game board somehow. The current player color needs to switch each turn. [Already provided: Pieces should be added to the board by clicking on a column, with pieces falling and stacking up in that column.]
- 0.5 - Modularized design
- You should certainly have more than one or two classes. Model the different parts or elements of the game in different classes. Which classes you use (GameBoard, Chip, Turn, etc.) is up to you.
- 2.0 - Determines when the game has been won
- Checks for a win after each play and reports when a player has won. This checking should use a recursive algorithm (with backtracking).
- 1.5 - Records move information
- Using a queue, record the details of each move. Move details include: the player's color/name, the move (either the column or the column x row position where the chip was played), and the time elapsed since the last move. Display these details at the end of the game. (You may also display them during the game if you like, but you must still use a queue.)
- 0.5 - Records the total number of wins for each player
- Display how many games each player has won since the applet was loaded. (If you want, you may also list how many games each player has lost.)