，Java SwingGUI。
Software Expectations
The project this term is an implementation of the game Mancala (the African Stone Game). If you aren’t familiar with this game, game play rules follow.
The Mancala board is illustrated here. The game starts with 48 stones, 12 bines, and 2 Mancalas.
Rules of the Game
- Player’s bins are in the lowest row (circles numbered 1-6). The computer’s bins are those numbered 7-12.
- Start by placing 4 stones in each of the bins numbered 1 through 12.
- Either the player or computer is randomly chosen to start the game. The entity chosen will be referred to as A.
- A selects one of their bins and removes all of the stones. A then proceeds to place one stone at a time in each of the bins counterclockwise (this is 1 through 6) around the board in bins and in your Mancala but never in the opponent’s Mancala. If the last stone is placed in their Mancala then A will play another turn.
- If the original bin has enough stones that placing them actually “laps” the board, then the original bin is skipped.
- For any turn, the original bin is always empty at the end of the turn.
- Note that you never place a stone in your opponent’s Mancala, it is skipped, and the remaining stone(s) are placed in the following bin(s).
- If the last stone in a play is placed in an empty bin on that player’s side of the board, then you take all of the stones in your opponent’s bin that is directly opposite as well as the single stone placed in the last bin. You place all the captured stones in your Mancala.
- Play ends when one player’s six bins are empty. The other player then places all remaining stones from their side of the board into their own Mancala. The player with the most stones in their Mancala is the winner.
Project Requirements
You are required to use the programming language Java, the graphics library Swing for your GUI, and the IDE Eclipse. You are not allowed to use other libraries or packages. Each team will be provided with a Google drive folder to be used for team code development and for submission of your source code on the due date of the project. All components of your software must be self-contained, in that when grading your implementation, the source code shall be built using the CEC computing image available on our laboratory PCs. The grader will be building your project using Eclipse from scratch. It is your responsibility to ensure that an executable can be easily built. Those projects that can not be built will receive a failing grade Identify the project folder in the Eclipse workspace found on the Google Drive as Mancala and have your main class called MancalaMain. Please do not use packages!!!
Several deliverables are associated with this project and are noted in the syllabus with their due date and grade weight. While different team members may be assigned different roles that contribute towards satisfying the software expectations, all team members must be able to talk intelligently about the project goals, development approach, and architecture. Such knowledge must be demonstrated during status reports and project presentations. Each team member will be asked to evaluate the percent of overall contribution by each team members and these evaluations will be used to adjust individual team member grades.
Here are some specific requirements of your implementation of Mancala.
- The composition of a stone is quite attractive; however, we don’t want to get caught up in how to render 1,2,3,4,5,. stones in a bin/Mancala. I suggest you just use an integer to represent the number of stones in a bin/Mancala.
- A player’s turn can cause many movements of stones. You will need to animate the changes to the number of stones in a bin/Mancala in their order of occurrence.
- The user should be allowed to play multiple games. Upon quitting the session, a tally is to be displayed of the winning stats.
- Note that the computer should not make random, legal moves. The team is expected to document and implement the winning strategy employed for the computer’s moves.
- Note that not all user moves are legal - illegal moves should be identified and disallowed or rectified.
- The user should be able to give up gracefully (i.e. without having to close the game).
Grading the Implementation
This game, while simple in concept, will be challenging to complete in a term. A team may choose the sophistication of their implementation based on the game’s functionality.
Grade levels:
- F - Inability to build an executable of the game. Game play throws exceptions.
- D - no F behavior and random computer moves with no check of legality of user moves. Single user moves only. Single game play only. No automation. Multiple game play with a tally at the end of the session.
- C - D level functionality and random computer moves, note of illegal user moves, multiple user moves, and the ability to give up gracefully. Automation of player moves.
- B - C level functionality and winning strategy based on making a move given the current board layout.
- A - B level functionality and winning strategy based on eventual board layouts given several moves in advance (see discussions of expert play). You must demonstrate this advanced play.