Engine core
RustCore engine, board state and move encoding.- CargoWorkspace split across rules, search, UCI and tooling.
- Bitboards64-bit board representation for fast attack masks.
Back to registry01 02 03 04
main5ac41aaWorking
Chess Engine
Pure-Rust chess engine and analysis platform.
A UCI-compatible engine built around fast bitboards, perft-validated legal move generation, alpha-beta search and an NNUE evaluation pipeline inspired by modern engines.
Private repository
evaluation+0.42
- depth
- 18
- nodes
- 2.4M
- pv
- e4 c5 Nf3 d6
Stack
Search
- Alpha-BetaIterative search with move ordering and pruning.
- NNUEEvaluation target for stronger positional scoring.
- UCIProtocol layer for GUI compatibility and analysis.
Validation
- PerftLegal move generation checked with node counts.
- ZobristFast position hashing for repetition and tables.
- CLILocal analysis workflows around FEN and PGN.
Why I built this
I wanted a project where Rust's ownership model, data layout and performance profile matter on every line.
A chess engine is a tight engineering loop: correctness first, then move ordering, pruning, memory layout and evaluation quality.
How it works
The workspace is split into core rules, search, analysis, UCI, CLI and training crates so each layer can be tested independently.
The hot path relies on compact move encoding, bitboards, Zobrist hashing and make/unmake move state to avoid unnecessary allocations.
Key decisions
- 01
Separate chess-core from search
Move generation and board state stay dependency-light, which makes perft testing and future consumers easier to reason about.
- 02
NNUE as the evaluation target
A classical evaluator is useful as a baseline, but NNUE gives the project a serious path toward stronger play.
- 03
UCI from the start
Compatibility with existing GUIs keeps the engine testable outside of its own CLI.
What I learned
- Correctness tooling matters more than clever pruning at the beginning.
- Small representation choices compound when they sit inside millions of searched nodes.