Chess Game

Authors

• Vignesh Balaji – https://github.com/vig997
• Yohannes Zerihun – https://github.com/yohazerihun
• Ricky Vo – https://github.com/tvo104-cmyk
• Mathews Boban – https://github.com/mboba004

Project Description

We decided to do this project because all of us played chess while growing up, and we still play today. We believe that chess is a simple game in concept, but it also challenges us to code the intricate rules that can occur during gameplay. For now, we plan to use C++ since it is a high-level language that everyone on the team is familiar with, with further discussions of integrating other languages as the project progresses.

User Interface Specification

Our application is a console-based chess game. Users interact with the program entirely through the terminal using text menus and commands. The following sections describe the layout and behavior of each logical screen in the application. The layouts shown are representative examples of the text output and may vary slightly in formatting in the final implementation.

---

Screen Layouts

Screen 1: Main Menu

The Main Menu serves as the entry point of the application. It allows the user to start a new game, load an existing game, or exit the program.

Layout

    HIGHLANDERS CHESS

[1] New Game
[2] Exit

Select an option: _

User Interaction

• The user enters a number corresponding to one of the menu options.
• Invalid input results in an error message and the menu is displayed again.
• Selecting:
  • 1 starts the new game setup process.
  • 2 prompts the user to confirm exiting the program.

Screen: New Game Setup

Purpose
This screen collects basic information needed to initialize a new chess game, such as player names and optional game settings.

Layout

     NEW GAME SETUP

Player 1 name (White): _______
Player 2 name (Black): _______

Type in File(A-H): Type in Rank(1-8):

Type Old Coords or Z to return to main menu [Z] Back to Main Menu

Select an option: _

User Interaction

• The user enters player names with either the black or white pieces.
• Selecting Start Game initializes a new game and proceeds to gameplay.
• Selecting Back to Main Menu by clicking z discards the setup and returns to the main menu.
• Invalid moves occur if there are errors with the coordianates that the users have put.

Screen: Exit Confirmation

Purpose
This screen confirms whether the user intends to exit the application, preventing accidental termination.

Layout

   EXIT CONFIRMATION

Are you sure you want to exit? Unsaved progress will be lost.

[1] Yes, exit
[2] No, go back

Select an option: _

Game Over Screen

GAME OVER

Result: White Wins

It clearly indicates the winner and provides post-game options.

User Interaction

• Selecting Yes terminates the program.
• Selecting No returns the user to the previous screen.

Navigation Diagram

This diagram represents all the various screens of the chess game that the user will be able to reach. This ranges from screens such as the game screen to the game history screen whcih will allow users to see various screens that represent the diagrams that they wish to see.

We are going to go over the description for the class diagram. The composition of the game will be ChessGame will be owning the board. The Board will own a number of piece objects. This means if anything happens to the board such as if the board is deleted, all the pieces will also disappear. This is the original board and classes/

Inheritance: Piece will be an abstract class which can also be inherited by Pawn, Rook, Queen, Knight, Bishop, King. Each of these subclasses will have specific movement rules but will inherit traits from piece as well.

Associations: The assocation will be player will interact with the board to make multiple moves while the pieces will query the board for validation for moves.

Below is the Class Diagram using Solid principles

The Single Responsibility Principle is followed in this updated class diagram because each class in the project is responsible for one main task. For example, the piece classes only represent chess pieces and their properties, while the move and rules logic handles validating and executing moves. This separation keeps the code easier to maintain and prevents one class from doing too many unrelated things.

The open closed principle is now followed as the program design allows new behavior to be added without modifying existing code. New chess pieces or rules could be added by extending the current structure instead of rewriting the core system. This makes the program easier to expand in the future.

The Liskov Substitution Principle is followed as all piece types such as King, Queen, Rook, Bishop, Knight, and Pawn inherit from the Piece base class. Because of this, any of these objects can be used wherever a Piece is expected, allowing the game logic to treat all pieces consistently.

The interface Segregation Principle has also been followed as the project separates functionality into smaller modules like rules, move handling, and stalemate detection. Each part of the program only uses the functions it needs, which keeps the code more organized and prevents unnecessary dependencies.

The Dependency Inversion Principle is followed as higher level logic such as move validation interacts with general structures like the Piece base class and the Game state rather than depending on specific piece implementations. This reduces coupling between parts of the program and makes the system easier to modify.

=

Screenshots

This screenshot shows the main menu of the chess game and will allow users to choose to start the game or exit instead.

This is the new game setup screen which allows the users to input their names with the corrresponding white or black pieces.

Below is a screenshot showing the game detecting a checkmate.

This is the exit confirmation screen which takes us to the exit screen.

This is the exit screen when we have left the game.

Follow these steps to build and run the chess application.

1. Download the Project(Linux Terminal)

Clone the repository or download the project files into your chess directory.

git clone https://github.com/your-repo/chess-project.git cd chess-project

2. Build the Project with CMake

Create a build directory and compile the project using the provided CMakeLists.txt.

mkdir build

cd build

cmake ..

make

Run the Chess Game

After the build finishes successfully, run the executable:

./chess_game

Usage

1. We will first start the game and both players will get to enter the name and choose whether they will be the black or white side.
2. We will then get to enter the coordinates of the piece that we will want to move.
3. Then we will enter the coordinates of where we want to move the piece afterwards.
4. We will keep playing until there is a winner or else we can return to the main menu at any time.
5. Once we return to the main menu we can exit out of the program and return to folder before the game was started.

Testing: We used Google Test as our testing framework to verify that different components of our chess program work correctly. Google Test allows us to write automated test cases and use assertions like EXPECT_EQ, EXPECT_TRUE, and EXPECT_FALSEto compare the expected output with the actual result from our code.

First, we tested object creation and piece properties. We created objects for different chess pieces such as King, Queen, Rook, Bishop, Knight, and Pawn. Then we checked whether their attributes were initialized correctly. For example, we verified that each piece returns the correct symbol like "WK" for a white king and "BQ" for a black queen, and we also checked that their point values match standard chess rules.

Second, we tested game logic functions to make sure the program behaves correctly during gameplay. For example, we tested the function that switches turns between players to confirm that the turn changes from white to black and back correctly. We also tested the board setup function to verify that all pieces are placed in their correct starting positions on the chessboard and that the middle squares are empty when the game begins.

Finally, some functions in our program require user input, such as selecting menu options or entering board coordinates. Since automated tests cannot wait for real keyboard input, we simulated user input using std::stringstream. We redirected cin’s input buffer using rdbuf, which temporarily makes cin read from our predefined string instead of the keyboard. This allowed us to automatically test functions like menu selection and coordinate parsing without manual interaction.