Java Gomoku Game
1. Basic Features
You are expected to implement a gomoku game in Java. The name "gomoku" is from the Japanese language, in which it is referred to as "gomokunarabe": "go" means five, "moku" is a counter word for pieces and "narabe" means line-up. The game should support the following features:
-
Preliminary Gomoku Game Rules (10 Pts): The logical layer of your program should support the following game rules:
- The game is played on a 15x15 board.
- Two players take turns to place a stone on an empty intersection.
- Black plays first, and the players alternate in placing stones on an empty intersection, i.e. those intersections with a stone on it cannot be placed again.
- The winner is the first player to get an unbroken row of five stones horizontally, vertically, or diagonally.
-
Java GUI (10 Pts):
You are required to implement a GUI for the game. The GUI should be implemented in Java FX (rather than Java Swing). It should support the following features, i.e. the GUI should be able to display:
- The game board and the stones placed on it.
- The current player that has the right to place a stone.
- The winner once the game is finished.
- The game settings, i.e. the size of the board and the player names.
- The game menu, at least with the reset button (i.e. the "start a new game" button, or "reset" for short) and the exit button.
-
Direct Mouse Control (10 Pts): The GUI should support direct mouse control, i.e. the player can place a stone by clicking on the board, rathe than typing in the (row, column) tuple. Rigorously speaking, it's part of the GUI design, but it's so important that we count the scores separately, as it involves event listening. The features are listed below:
- The player can place a stone by clicking some intersection on the board. There should be some tolerance for the mouse click, i.e. the player can click on the intersection or the area around it.
- The player can only place a stone on an empty intersection. If the player clicks on an intersection with a stone on it, the program should at least ignore the click.
2. Advanced Features
Note that you can earn 90% of the scores finishing all three projects with the only basic features.
That is to say, to get a higher score, you may want to consider adding some advanced features:
(Please pick some features from the followings.
The corresponding bonus scores will be added to your final score,
and the upper bound of your final score is 100 pts.
That's to say, you can get at most 100 pts by picking two 5 pts features or one 10 pts feature.)
-
Undo and Redo (5 pts): The GUI can support undo and redo operations via stacking the historical operations. The features are listed below:
- The player can undo the last move by clicking the undo button.
- The player can redo the last move by clicking the redo button.
- The player can undo and redo multiple moves.
-
Save and Load (5 pts): The GUI can support saving and loading the game via serializing the game status. The features are listed below:
- The player can save the current game status by clicking the save button.
- The player can load the game status by clicking the load button.
- The game status should be saved in a file, and the player can choose the file to save or load. The checkpoint file design is up to you, but it'd better be readable rather than binary.
-
Invisible Mode (10 pts): The GUI can support invisible mode, i.e. the player can play the game without seeing the board. The features are listed below:
- Each player now has a limited number of chances for viewing the board, e.g. 3 times.
- The player can view the board by clicking the view button, and the board will be visible at the current round for the current player's turn. It should disappear after the player places a stone successfully.
- Each viewing will cost one chance, and the player can view the board only when he/she has chances left.
- The player will receive a warning when he/she places a stone on an intersection that has been placed before when it's invisible
- There is some limited number of trials for the player to mistakenly place a stone on an intersection that has been placed before when it's invisible, e.g. 3 times. After that, the player will lose the turn of placing a stone immediately, and it would be the other player's turn.
-
Time Limit (5 pts): The GUI can support time limit for each player, i.e. the player can only place a stone within a limited time. The features are listed below:
- Each player now has a limited time for placing a stone, e.g. 30 seconds.
- The player can place a stone within the limited time, otherwise he/she will lose the turn of placing a stone immediately, and it would be the other player's turn.
-
AI Player (10 pts): The GUI can support AI player, i.e. the player can play with the computer. The features are listed below:
- The player can choose to play with the computer or not.
- The AI player should be implemented by some algorithms. It's not required to use some reinforcement learning algorithms like monte carlo tree search, and you are suggested to use some simple heuristic algorithms, e.g. to block the opponent's five stones once the opponent has four stones in one line, or else to place a stone for one of your longest line.
-
User Friendly Interface (5 pts): Do more for the GUI and register more mouse events to make the GUI more user friendly. The features are listed below:
- When the player hovers the mouse over the intersection, the intersection should be highlighted.
- When the player mistakenly places a stone on an intersection that has been placed before, there should be some flashing circle (an animation lasting for a short time) around the stone to indicate that it's invalid.
- Rendering the board and the stones on it with some animations, e.g. fading in and fading out.
3. Submission
Submission should be made at the blackboard system. You need to submit:
- Video: Prepare a presentation for your project by recording a video. The video should record the screen while your code is running on your laptop or desktop.
- Code: Prepare your code for submission. The main functions and classes in the code must have comments in a reader-friendly format.