Checkers Game with AI UML Diagrams

All program code files and PlantUML code are in the repository(https://github.com/b0re3b/projectchechkers)

This program implements a simple checkers game with an AI player using the Minimax algorithm. The game is developed using the SFML (Simple and Fast Multimedia Library) for graphical rendering. The main components of the program are the Board, Piece, Player, Move, MoveNode, Menu, and Game classes.

Components

Board

The Board class is responsible for managing the game state, including the positions of pieces, handling user input, drawing the board and pieces, and implementing the game logic such as move validation, highlighting possible moves, and checking for the endgame condition. It also contains methods for evaluating the board state and generating possible moves for the AI.

Key Methods

• InitializeGame: Sets up the initial positions of the pieces on the board.
• validarity: Checks if a move is valid.
• inputdata: Handles user input for selecting and moving pieces.
• highlight: Highlights possible moves for a selected piece.
• numberofmoves: Returns the number of possible moves for a player.
• endgame: Checks if the game has ended.
• draw: Draws the board and pieces on the window.
• evaluateBoard: Evaluates the board state for the AI.
• MinMaxTree: Generates the Minimax tree for the AI.
• BestMove: Finds the best move for the AI using the Minimax algorithm.
• opponentPiece: Checks if a piece belongs to the opponent.
• generateMoves: Generates all possible moves for the current player.
• minimax: Minimax algorithm implementation.
• ComputerMove: Makes a move for the computer player.
• MousePosition: Gets the index of a piece based on mouse position.
• makeMove: Makes a move on the board.

Piece

The Piece class represents a single piece on the board. It includes attributes like isAlive, isKing, color, x, and y to store the piece's state and position. The Draw method renders the piece on the window.

Player

The Player class represents a player in the game. It has attributes for the player's color and type (human or computer).

Move

The Move class represents a move in the game, storing the start and end positions of a piece.

MoveNode

The MoveNode class is used in the Minimax algorithm to represent nodes in the Minimax tree. Each node contains a move, a score, and a list of child nodes.

Menu

The Menu class handles the user interface for choosing the player's color at the beginning of the game. It displays text options for "Red" and "Black" and returns the selected color.

Game

The Game class manages the main game loop, initializing the board and players, and running the game until it ends.

How It Works

1. Initialization:
2. Menu: The Menu class displays a menu for the player to choose their color.
3. Game Loop: The Game class runs the main game loop, which handles drawing the board, processing user input, and making moves.
4. User Input: The inputdata method in the Board class processes user input for selecting and moving pieces. It highlights possible moves and validates the selected move.
5. AI Move: When it's the computer's turn, the ComputerMove method in the Board class generates the best move using the Minimax algorithm and makes the move.
6. Endgame: The game continues until an endgame condition is met (one player has no pieces left or no valid moves).

Building and Running

To build and run the program, ensure you have SFML installed and set up correctly. Use a build system like CMake to compile the code.

Testing

The program contains unit tests that cover part of the functionality, namely checking the validity of the move, algorithm and computer moves and input data

UML

UML stands for Unified Modeling Language. It's a standardized general-purpose modeling language in the field of software engineering. UML provides a way to visualize a system's design through a variety of diagrams such as class diagrams, sequence diagrams, use case diagrams, and more.

Use case

This diagram illustrates the interaction flow between a human player, a computer player, and the game system in a checkers-like game. It outlines the sequence of actions and decisions taken by both players during gameplay. Each use case represents a specific action or event within the game, such as starting the game, choosing colors, selecting pieces, making moves, and checking for game over conditions. Overall, the diagram provides a structured overview of the game's main interactions and processes.

Class diagram

This diagram depicts the structure and interactions within a checkers-like game software system. It consists of several classes representing different components of the game, such as the game itself, the menu, the board, player, pieces, moves, and move nodes.The "Game" class manages the core gameplay loop and interactions between the players and the board. It contains references to the board, human player, computer player, and the SFML render window. The "Menu" class handles the menu interface for player color selection.The "Board" class represents the game board and contains the pieces. It provides functions for selecting and validating moves, updating the board, checking for game over conditions, generating moves, and more. The "Piece" class represents individual pieces on the board and provides functionality to draw them on the screen.The "Player" class defines players in the game, specifying their color and type (human or computer). The "Move" class represents a move in the game, storing starting and ending coordinates. The "MoveNode" class is used in the minimax algorithm for move evaluation.The diagram shows the relationships between these classes, such as how the game uses the menu and board, how the board contains pieces and uses moves, and how players make moves.

Component diagram

This diagram represents the components of a checkers game software system. It includes various modules such as the game application itself, menu, board, player, piece, move, and move node.

The "Game Application" artifact serves as the main application of the checkers game. It utilizes the "Menu" module for managing user interface interactions, the "Board" module for controlling the game board, and the "Player" module for managing player actions.

The "Board" module contains the game board and interacts with the "Piece" module, which represents individual pieces on the board. Additionally, the "Board" module utilizes the "Move" module for managing moves made during the game.

The "Player" module controls the actions of the players in the game and utilizes the "Move" module for making moves on the board.

Lastly, the "Move" module interacts with the "MoveNode" module, which is used for move evaluation and decision-making processes within the game.

Overall, this diagram provides an overview of the components and their interactions within the checkers game software system.

Object

The diagram depicts the structural composition and interconnections among different components within a game software system. It outlines the relationships between key entities such as the Game, Board, HumanPlayer, ComputerPlayer, Piece, Menu, and RenderWindow. These entities interact and collaborate to facilitate the functionality and operation of the game application.

Composite Structure

This diagram illustrates the internal structure of a game system, organized into a package named "Game." Within this package, there are several components: Game, Board, Players, Menu, and RenderWindow. The Board component contains a sub-component Square, which represents the grid of squares on the game board. The Players component further contains two sub-components: HumanPlayer and ComputerPlayer. The Game component interacts with the RenderWindow component for displaying the game interface.

Deployment

This diagram depicts a software architecture where the "Game Application" artifact resides on the "User Machine" node. Within the "Game Application," there are several components: Game, Menu, Board, Player, Piece, Move, and MoveNode. The relationships between these components are shown with arrows indicating their interactions. For instance, Game uses Menu and Board, while Board contains Piece and uses Move. Similarly, Piece involves Move, and Player makes Move, and Move uses MoveNode.

Package diagram

This diagram illustrates the component structure of a game application. It's organized into different packages: "Game," "Components," and "Players."

The "Components" package includes classes such as Game, Board, Piece, Move, and MoveNode, representing various elements of the game logic.

The "Players" package contains the Player class and the PlayerType enumeration, distinguishing between human and computer players.

Outside the packages, there are two standalone classes: Menu and RenderWindow.

The arrows indicate dependencies and relationships between the components. For example, the Game component depends on both Components and Players, while Game.Components encompasses all the internal components. Additionally, the Game component uses Menu and interacts with the RenderWindow class.

Sequence diagram

It shows the sequence of interactions and message exchanges between different components or actors within the system during a specific scenario or use case. This includes how various elements of the system collaborate to achieve a particular functionality or behavior. The goal is to provide a clear understanding of the flow of control and data within the system, highlighting the order in which actions are performed and how they affect the system's state.

Activity diagram

The activity diagram illustrates the sequential flow of actions within a game application, guiding from initialization to completion. It commences with the game initialization, proceeds through player interaction, and concludes upon game termination.

At the outset, the game initializes its components, displaying the menu for player interaction. Upon selection of a preferred color, the game enters the main loop, alternating between the human player's turn and the computer player's turn.

Interaction Overview diagram

The diagram depicts the interaction flow in a checkers game. It begins with the human player choosing a color. The game initializes, and a loop starts, handling player turns and moves. The process repeats until the game ends. After each move, the results are displayed.

State diagram

This diagram illustrates the states and transitions in a checkers game. It begins in the "Idle" state, waiting for players. When the game starts, it initializes and transitions to the "PlayerTurn" state. In this state, the human player takes their turn, validates their move, updates the board, and checks if the game is over. If not, it switches to the computer player's turn. The computer generates and executes its move, followed by updating the board and checking for game over. The process continues until the game ends, leading to the "GameOver" state.

Changes

Some changes have already been implemented here regarding the project in the first semester, but as I continue to work with this project, I plan to break the board class into simpler ones, make more unit tests and improve the operation of the program.