PasKnight Files

Functionality
PasKnight is a UCI (Universal Chess Interface) chess engine. It does not have a graphical interface of its own; instead, it runs as a console application that communicates via text commands with a GUI (like Arena, CuteChess, or WinBoard).

Sourcode:
PasKnight is written in Pascal code using Lazarus & Free Pascal compiler
 
 
Its core loop:
 

    Listens for UCI commands (uci, isready, position, go, stop).
    Updates its internal board state based on position commands (supporting both startpos and FEN strings, followed by move lists).
    Searches for the best move when it receives the go command, adhering to time controls or depth limits.
    Outputs the chosen move via bestmove and sends intermediate search statistics (info depth ...) to the GUI.

 
Algorithms Used
1. Board Representation
 

    8x8 Array: The board is represented as a 2D array of pieces.
    Incremental State Tracking: It tracks king positions, castling rights, en passant squares, and the half-move clock to avoid recalculating them from scratch every time.

 
2. Move Generation
 

    Pseudo-Legal Generation: It generates all moves that are valid according to piece movement rules, ignoring whether they leave the king in check.
    Legality Filtering: To find legal moves, it makes each pseudo-legal move on the board, checks if the side that just moved is now in check, and undoes the move if it is.

 
3. Search Algorithm
 

    Iterative Deepening: The search runs at depth 1, then depth 2, then depth 3, etc. This ensures the engine always has a move ready if time runs out, and the best move from a shallower depth is used to guide the next deeper search.
    Negamax with Alpha-Beta Pruning: The core search uses the Negamax framework (a variant of Minimax where both players maximize their own scores) combined with Alpha-Beta pruning to cut off branches of the search tree that are proven to be worse than previously explored options.
    Quiescence Search: When the standard search reaches its maximum depth, it doesn't immediately evaluate. Instead, it continues searching only captures, promotions, and check evasions. This prevents the "Horizon Effect" (e.g., thinking a position is good because the engine stops searching right before it loses a queen).
    Check Extensions: If a move puts the opponent in check, the search extends the depth by one ply to ensure tactical sequences aren't cut off prematurely.

 
4. Move Ordering To make Alpha-Beta pruning as efficient as possible, the engine searches the most promising moves first using:
 

    Principal Variation (PV) / Iterative Deepening Move: The best move found at the previous depth is searched first.
    Transposition Table (TT) Move: If the position has been searched before, the best move from the cache is searched first.
    MVV-LVA (Most Valuable Victim - Least Valuable Attacker): Captures are ordered so capturing expensive pieces with cheap pieces (e.g., Pawn takes Queen) is searched first.
    Killer Heuristic: Quiet (non-capturing) moves that caused beta cutoffs at the same depth in sibling nodes are prioritized.

 
5. Evaluation Function
 

    Material: Standard piece values (Pawn=100, Knight=320, Bishop=330, Rook=500, Queen=900).
    Piece-Square Tables (PST): Positional bonuses/penalties based on where a piece stands (e.g., Knights in the center are good, pawns advancing are good).
    King Safety / Endgame Transition: If queens are on the board, the king is penalized for leaving its starting rank and rewarded for castling. If no queens are on the board (endgame), the king is rewarded for moving to the center.

 
6. Caching & Draw Detection
 

    Zobrist Hashing: The board state is converted into a unique 64-bit integer using XOR operations, allowing for fast position comparisons.
    Transposition Table: A hash table that stores previously searched positions (score, depth, best move, and bound type) so the engine doesn't re-evaluate the same position multiple times.
    Repetition Detection: Tracks game history hashes to detect three-fold repetition, and uses the half-move clock for the 50-move rule.

 
7. Time Management
 

    Dynamically allocates time per move based on remaining time, increment, and estimated moves left, calculating safety margins so it never loses on time.