keshavraj7/chess-game

1. Overall shape

This is a single-process, desktop chess application in C++ with SFML handling the window, input, and drawing. The code is organized around a clear split between:

- chess domain logic,

- game/session orchestration,

- rendering/UI,

- AI move selection.

2. Entry point and runtime loop

main.cpp is the application bootstrap. It likely creates the top-level Game object and hands off control to the main loop. The runtime is event-driven: SFML provides input events and window lifecycle, while the game loop repeatedly processes input, updates game state, and renders the board.

3. Game/session coordinator

Game.cpp/.h appears to be the central controller. It likely owns the current mode, turn state, selected piece, game-over status, and the transition between human turns and AI turns. This is the layer that connects user actions, rule enforcement, and rendering.

4. Board and rules engine

Board.cpp/.h is the core rules subsystem. It likely stores the board state, piece placement, turn information, move history, and special-state flags such as castling rights or en passant eligibility. It is also the natural boundary for legality checks, check/checkmate/stalemate detection, and applying/undoing moves.

5. Piece hierarchy

Piece.h defines the abstraction for all pieces, and Pawn.cpp, Knight.cpp, Bishop.cpp, Rook.cpp, Queen.cpp, and King.cpp implement piece-specific movement rules. This is the main polymorphic domain model: the board asks a piece for legal moves, and each subclass contributes its own movement and special-case behavior.

6. Move representation

Move.h is the shared data contract for actions in the system. It likely carries source/destination squares and any extra metadata needed for chess rules such as captures, promotions, castling, or en passant. This object is probably used by both the rules engine and the AI search tree.

7. AI subsystem

AI.cpp/.h encapsulates the computer opponent. The README confirms a minimax search with alpha-beta pruning, so this module is likely responsible for:

- generating candidate moves from board state,

- evaluating positions,

- choosing the best move for the computer side.

It depends on the board/rules layer but should remain independent from rendering and input.

8. Rendering and user interface

Renderer.cpp/.h is the presentation layer. It likely loads SFML textures from assets/, draws the board and pieces, highlights legal moves and last move, and renders end-state overlays like checkmate or promotion selection. This layer should consume game state but not implement chess rules itself.

9. Data flow between subsystems

The main flow is:

user input from SFML → Game interprets selection/action → Board validates and applies move → Game updates turn/game-state flags → Renderer redraws the result.

In human-vs-computer mode, the flow branches after a human turn: Game asks AI for a move, AI queries board state and returns a move, then Board applies it.

10. Special chess mechanics

The repository explicitly supports castling, en passant, promotion, check, checkmate, and stalemate. Architecturally, these are not separate subsystems; they are cross-cutting rule behaviors implemented primarily in Board and the piece classes, with Game coordinating prompts or state transitions when promotion or game-over occurs.

11. Game modes and state boundaries

The application supports both human-vs-human and human-vs-computer play. The important boundary here is turn ownership: Game decides whether the active side is controlled by a local player or by AI, while Board remains the authority for whether a move is legal regardless of who proposes it.

12. Assets and external dependency

The assets/ directory is a required runtime dependency containing piece images and other visual resources. SFML is the only major external framework, and it materially defines the UI architecture: window management, event handling, texture loading, and drawing are all delegated to it.

13. Why this architecture is maintainable

The design follows a classic object-oriented chess split: Piece subclasses encode movement behavior, Board encodes game rules and state, Game coordinates sessions, AI reasons over moves, and Renderer handles presentation. That separation makes it straightforward to diagram the system as four major layers: input/control, rules/state, AI, and rendering.