Im creating a chess analysis tool that can search for a player accross multiple platforms (Chess.com, Stockfish, etc...), then can analyse their games at mass within a period (usually a month). Its currently able to show an overview including the win rates for player colour, rating progression over the month, opponent analysis (av elo for wins, av elo for loss, etc...), and analysis of the openings.

How should I define the stages of the game to then perform detailed analysis? Like Opening is anywhere from 8-15 moves and I can then search those moves into an opening library to find their names, so thats easy enough.

But how to define where the middlegame ends and where the endgame starts? Its not as simple as seeing if the Queens are still on the board, so do I need to find the total value of captured pieces and then if that is over value x, then say we have moved to the endgame?

Thanks for anyhelp here, I am at a bit of a loss as to how we can define it.

Do you know where to find the best datasets that contain billions of positions with reliable scores (from strong and recent engines) that I can use to train my NNUE from scratch?

Ultimately I want to self train, but I need a strong basis that I can't generate with my engine in its current state (~3k elo).

This is a live training snapshot, not an Elo claim or a like-for-like depth comparison. Nyvera, running with tactical depth 2, defeated Stockfish configured to depth 12.

Original r/ComputerChess post with the animated replay:

https://www.reddit.com/r/ComputerChess/comments/1vzjid3/nyvera_tactical_depth_2_defeated_stockfish/

Engine-facing record

• Training game 30257 / 30,615; Nyvera as White; 1–0; 127 plies; game_over at 64. Qe7#

• Nyvera tactical depth: 2; Stockfish opponent depth: 12

• Opening setup: self_directed / self_directed_start

• Realized opening prefix: reti / reti_classical_root

• Training lane: 2/2 (wave 1); shared-memory epoch: 28357

The depth fields describe different machinery and should not be interpreted as equal search budgets. The game’s notable sequence is the queen loss on 17...Bxc3+, no White rooks after 27...Kxd8, then 61. b8=Q+ followed by mate on 64. Qe7#.

Exact PGN:

```

1. Nf3 d5 2. d4 e6 3. c3 c5 4. Qa4+ Nc6 5. Bf4 cxd4 6. Nxd4 Bd7 7. Nxc6 Bxc6 8. Qc2 Qf6 9. e3 e5 10. Bg3 Be7 11. f4 e4 12. c4 d4 13. exd4 Qxd4 14. Be2 Nh6 15. Qd2 Nf5 16. Qxd4 Bb4+ 17. Qc3 Bxc3+ 18. Nxc3 h5 19. O-O h4 20. Be1 h3 21. g4 Nd4 22. Bf2 Nxe2+ 23. Nxe2 e3 24. Bxe3 Bg2 25. Rad1 Bxf1 26. Kxf1 Rd8 27. Rxd8+ Kxd8 28. Bxa7 Kd7 29. Kf2 Ra8 30. Bd4 f5 31. gxf5 Ra5 32. Bxg7 Rxf5 33. Be5 Rh5 34. Bf6 Rc5 35. Nc3 Ke6 36. b3 Ra5 37. Bh4 Kf5 38. Kf3 Ra3 39. Be7 Ra8 40. a4 Ra6 41. Nd5 Ra7 42. Ne3+ Ke6 43. Nd5 b5 44. Bc5 Rg7 45. axb5 Rg8 46. b6 Rd8 47. Bd4 Kd7 48. b7 Rb8 49. Nf6+ Kd8 50. Bb6+ Ke7 51. Nd5+ Kd7 52. b4 Ke6 53. Nc7+ Kd6 54. c5+ Kc6 55. b5+ Kxb7 56. Nd5 Re8 57. c6+ Kc8 58. Bc5 Kd8 59. b6 Re6 60. b7 Rxc6 61. b8=Q+ Rc8 62. Qd6+ Ke8 63. Qe6+ Kd8 64. Qe7# 1-0

```

I've been working on an open-source, UCI-compatible C++ chess engine called Volatile for a while now, and I've reached a point where I'd really like to get other people involved.

It's currently somewhere around the 2200–2400 Elo range, and the engine already has a proper Alpha-Beta search backend, with the architecture designed to support both HCE and NNUE evaluation. Right now, I'm focusing primarily on the HCE.

The reason I started Volatile is somewhat different from the usual "I'm going to make another chess engine" story.

I've always found computer chess fascinating, but I've also noticed that getting into the internals of a very strong engine can be intimidating. Projects like Stockfish have evolved for many years and are incredibly optimized, but for someone new who wants to experiment with the search or evaluation, there can be a pretty steep learning curve.

I wanted to see if it was possible to take a different approach.

The main idea behind Volatile is to have a highly maintainable architecture, using modern C++ design patterns while still being fast enough to play serious/strong chess.

I'd prefer a codebase where another developer can open the repository, understand how the pieces fit together, modify the evaluation or search, run an experiment, and contribute the result without having to spend months on understand the entire engine.

Obviously, this is something I still need to prove. I'm not claiming that abstraction automatically makes a chess engine better or that Volatile has somehow solved engine architecture. That's exactly the experiment I'm interested in.

And this is where I'm hoping to find some people who are interested in joining me.

I'm not just looking for someone to give the project a quick star(although I don't mind if you do) or tell me it looks interesting. I'd really like to find developers who enjoy computer chess and C++ and would be interested in actually experimenting with the engine.

That could mean:

• improving evaluation
• experimenting with search heuristics
• benchmarking
• finding architectural problems
• reviewing PRs
• suggesting better designs
• or simply trying something weird and seeing whether it works

I'd especially love to have people who disagree with some of my architectural decisions and are willing to discuss them. If something I've designed is unnecessarily complicated or slower than it needs to be, I'd rather have someone point it out and help improve it.

My long-term goal is pretty ambitious: I want Volatile to become a genuinely community-developed engine.

I'd love to eventually look at the repository and see a constant stream of experiments, PRs, discussions and improvements from different people rather than everything coming from one developer.

And yes, eventually I'd love to see how far this architecture can actually go in terms of playing strength. Maybe one day Volatile can get close to the very top engines. Maybe it won't. I honestly don't know yet.

But that's what makes the experiment interesting to me.

Even if you don't want to contribute code, feedback on the architecture, things that look wrong, or ideas for where the engine should go next would be extremely valuable.

Maybe this is a bit ambitious but, I'd really like to build this engine with other people rather than just build it by myself.

Repository:
https://github.com/PriyojitRoy/Volatile

Welcome to the weekly /r/chessprogramming Engine Dev Help Thread.

Ask beginner and intermediate chess engine development questions here: move generation, search, evaluation, UCI, perft, debugging, testing, NNUE, or anything else related to building engines.

Good questions include code, FENs, logs, benchmarks, or a clear explanation of what you tried.

Project links are fine when you want technical feedback, not promotion.

Be helpful. Don’t dunk on beginners.

Hi everyone,

I'd like to share the new release of Luna, my UCI chess engine written in Rust: Luna CE v2.5.0.

What Luna is

Luna combines classical bitboard move generation (magic bitboards for sliders) with a quantized NNUE evaluation (HalfKP 256×2-32-32-1, Stockfish-compatible network format), incrementally updated on make/unmake. Search is negamax/PVS with iterative deepening, aspiration windows, a transposition table, and the usual pruning family (reverse futility, futility, null move with a zugzwang guard, mate distance pruning, LMR, quiescence with SEE and delta pruning). It falls back cleanly to a classical PST evaluation if no NNUE file is present.

What's new since v2.1.0

Move ordering: added a counter-move heuristic and capture history (both new signals alongside the existing killer moves and SEE/MVV-LVA ordering). The plain history heuristic was rewritten to use a self-limiting "gravity" update instead of a hard cap, plus a malus for quiet moves that were tried but didn't cause a cutoff — instead of only ever rewarding successes.
A real bug fix from a lost game: the UCI go command parser mishandled value-less flags like ponder. When a GUI/wrapper sent go ponder wtime X btime Y ..., the misalignment made Luna silently fall back to a fixed 5-second budget instead of reading the actual clock — the likely cause of a time forfeit from a completely winning position. Fixed, and pondering is disabled anyway since Luna doesn't implement the pondering protocol.
ARM64 support: working cross-compilation to aarch64, plus a NEON SIMD path for NNUE inference (previously ARM builds fell back to scalar code). Runs natively on ARM Linux and Android.
Housekeeping: cleaned up a messy repo (a stale duplicate copy of the source tree had accumulated at the root), removed dead code, translated all source comments to English for a wider audience.
Infrastructure

Luna now runs 24/7 on an Oracle Cloud ARM instance instead of my personal laptop, so it should be reliably reachable for games/challenges going forward rather than only when my machine happens to be on.

Results

Since deploying the fixes above and moving to dedicated hardware, Luna's Lichess bot ratings have climbed noticeably over the past few weeks: bullet 2001→2268, blitz 1787→2267, rapid 1794→2241. (Lichess bot ratings, not directly comparable to CCRL or other formal lists, but a real trend worth sharing.)

Links

GitHub: https://github.com/Spunc595/Luna-Chess-Engine
Lichess (challenges welcome): https://lichess.org/@/LunaEngineChess
Feedback and games against Luna are always welcome — happy to hear what breaks it.

Long time lurker, first time poster. I went back to my hobby engine from a few years ago. It plays around 2200 on lichess. I added some forward pruning refinements, tuning changes, eval changes, bug fixes, etc. getting between 1-20 elo most of the time. Spent weeks on it. Got about 100 elo doing this. I got fed up with how little progress I was making and decided to try out aspiration windows. I have seen people say aspiration windows just don't work for them so I never decided to try it out before today. This morning I put in a pretty basic implementation of it and it gave me +219elo (+-8), which is huge obviously. I should have done it sooner. It sees 1-4 extra ply most of the time, and in some positions it sees double the depth it did before. This is just a post telling you to try out aspiration windows if you haven't. I start with a margin of 30cp and it increases exponentially as we go out of bounds. I am using handcrafted eval and fail hard PVSearch with null move, futility, reverse futility, LMR, and hashtable cutoffs with hashmove-mvvlva-killers-history for move ordering. My scores are are usually very stable - thats probably why this works so well. Im just so happy something finally worked out I made a reddit account to post on here. My search became so much stronger my engine is figuring out how to exploit weaknesses in my eval function which is something I have never seen before.

I'm writing a deliberately small chess engine (around 400 lines of code, including terminal UI), and now I'm looking for advice on what to do next. What would you add or remove? Are there similar engines I should look at?

The engine uses a fixed-depth negamax search with alpha-beta pruning and a simple quiescence search (captures only). The evaluation is intentionally simple: material plus mobility, with a small endgame bonus for advanced pawns. There is no iterative deepening, transposition table, move ordering, killer/history heuristics, aspiration windows, null-move pruning, opening book, endgame tablebases.

It is inspired by Nanochess from Oscar Toledo.

I wrote a Java version, and a version in my own programming language. And now a Javascript version, translated by AI, to play in a browser. I have tested it against Stockfish (my engine beats it at a low level) using python-chess and a UCI API. There are unit tests, including move generation using some of the Perft positions. Let it play a few hundred games against Stockfish to find and fix bugs. Now it wins most of the time against Stockfish at the lowest UCI_Elo setting (1320) with depth 4. (Depth 5 is the default setting currently.)

The goals of my engine are:

• Keep the code relatively easy to understand for learning, and building similar engines for other games.
• A very small engine that still plays reasonable chess, that can beat me (a beginner).
• Showcase my new programming language.
• Play chess in the terminal or in a browser, for fun (for beginners).
• Slightly simplified rules: always promote to queen; repetition and 50-move rule are ignored.

Some ideas I have:

• Simplify the evaluation method, and verify the results by playing against Stockfish. I wonder should it play against itself with depth e.g. 2, so it is very fast?
• Measure the Elo systematically, but then how to do this in a fast way?

What features would you add (or remove) while keeping the engine small and educational?

Are there interesting simplifications?

I am an absolute newbie, so this might be a dumb question, started on this 2 weeks ago. I got scared once I saw the UCI specification and decided to make a frontend part first, without UCI or evaluation, just playable board, but with legal moves, checks and checkmates.

I almost finished and after painfully slow perft testing I realized that I didn't even need to implement all that in the frontend? Like, should frontend be just the representation of engine state? Okay, maybe just the legal moves generation, so the player could only make legal moves. Making the whole system self-sufficient made me write some pretty bad code lmao (architecture-wise).

What is the right way to do it?

Welcome to the weekly /r/chessprogramming Engine Dev Help Thread.

Ask beginner and intermediate chess engine development questions here: move generation, search, evaluation, UCI, perft, debugging, testing, NNUE, or anything else related to building engines.

Good questions include code, FENs, logs, benchmarks, or a clear explanation of what you tried.

Project links are fine when you want technical feedback, not promotion.

Be helpful. Don’t dunk on beginners.

​

I’ve just released **Gyatso v1.5.0**, a major step forward for my open-source chess engine written in Nim.

The current estimated strength is around:

* **~3360 CCRL 40/15**

* **~3347 CCRL Blitz (2'+1")**

These are still estimates, so independent testing and Elo results would be greatly appreciated.

The project is completely open source, and I’m continuing to learn, experiment, and improve Gyatso with the help of the chess programming community.

Release:

https://github.com/GyatsoYT/GyatsoChess/releases/tag/v1.5.0

Source code:

https://github.com/GyatsoYT/GyatsoChess

If you’re interested in chess programming, engine testing, or Nim, I’d be happy to hear your feedback.

Welcome to the weekly /r/chessprogramming Engine Dev Help Thread.

Ask beginner and intermediate chess engine development questions here: move generation, search, evaluation, UCI, perft, debugging, testing, NNUE, or anything else related to building engines.

Good questions include code, FENs, logs, benchmarks, or a clear explanation of what you tried.

Project links are fine when you want technical feedback, not promotion.

Be helpful. Don’t dunk on beginners.

After having worked on my search for a long time I've decided to work on my evaluation function for a bit, since now it's just material + piece square tables. I was a bit concerned adding in checks for mobility, pawn structure, king safety, etcetera would slow my engine down by a lot though. I came across lazy evaluation as a solution, but I'm a bit afraid it will horribly misjudge some positions and not go through with a full evaluation.

So then my question is, is that risk worth the speed up? Or are there ways to tune it so that risk can be minimized?

https://chessprogramming.org/ has been down for a few days, but I checked just now and see a message that it's now hosted by lichess.org

So, until now I had a TT that I cleared between moves. I replace by prefering bigger depth and exact result.I added an age and now I always replace when prev TT move is older.

Whenever a useful TT hit is found I refresh their age to current age so that they dont get replaced by default.

The thing is:

Should I refresh all TT hits or just useful TT hits?

Right now go depth 9, go depth 10 is slower than only go depth 10 and its probably because TT entries get replaced before they can prove they are useful.

What do you guys suggest? I will test the 2 variants but I'd like to hear from somebody else. Perhaps maybe use the difference in age as a depth penalty idk

​

Their app does offline analysis with no internet. Stockfish is GPLv3, if it's bundled in, aren't they supposed to open source the app? or it's not actually Stockfis?. Anyone know?

Welcome to the weekly /r/chessprogramming Engine Dev Help Thread.

Ask beginner and intermediate chess engine development questions here: move generation, search, evaluation, UCI, perft, debugging, testing, NNUE, or anything else related to building engines.

Good questions include code, FENs, logs, benchmarks, or a clear explanation of what you tried.

Project links are fine when you want technical feedback, not promotion.

Be helpful. Don’t dunk on beginners.

I'm new to this and I've always just gotten stuck on programming the base game (which moves are legal and which aren't) and I'm wondering whether I should keep a list of pieces (each with color, position, and type) or an 8x8 grid where each square has a piece or just a blank. Or should I do something else?

is it just me or is it down for everybody

I've been working on my engine for a few weeks and I'm really happy with my progress for my first time. I've noticed lately I mostly work on search though, and most of the time I research what improvements are best they are all search related. If I compare that with my evaluation which is just counting pieces + psq for mid and engames it seems quite unbalanced.

Is this what's expected, or should I shift my focus towards evaluation for a bit?

I've been training a small transformer (39M params) to imitate Stockfish and pairing it with alpha-beta search. Two results from the last week that might be useful to others doing NN + search on modest hardware.

1. My beam was structurally incapable of finding the right move ~30% of the time.

Search expanded the policy's top-4 moves at each node. I never checked whether Stockfish's best move was actually in that top 4. It's a two-minute script, and the answer was ugly:

Depth-5 analysis inside a candidate set that excluded the correct move in 29.4% of positions. No amount of depth or pruning recovers a move you never generate.

Fix was late move reductions, already written and switched off. Wider beam, reduced depth for late candidates, re-search the promising ones:

+25% nodes, identical wall-clock per move. Two independent brackets agreed within 1 Elo.

1. fp16 and a transposition table did nothing, because I wasn't compute-bound.

Full day of inference optimisation. fp16: ~0%. TT: a wash. Batched interior nodes: net negative. PVS + iterative deepening: node-neutral. Only survivor was an allocation-free move -> id lookup, ~11%.

The model is tiny, so a forward pass is ~100 individual kernel launches in an eager framework, and every interior node runs at batch size 1, re-reading all 39M weights to score one position. ~1.5 ms per node, roughly 17x above the memory-bandwidth floor. Latency-bound, not FLOP-bound. The real fix is a Leela-style batched frontier, which I haven't done yet.

Also useful: mining training positions by centipawn loss yielded 0.5% (search is already good at not hanging pieces). Mining by recall failure: positions where SF's best move falls outside the model's top-K: yielded ~30%, and two fine-tuning rounds took recall@4 from 68.6% to 78.1%.

Longer write-up with the failed ideas (a looped recurrent-depth core that turned out flat from iteration one, and ternary weights that never once did ternary arithmetic): https://latentheat.dev/blog/chess-bitter-lesson

plays as https://lichess.org/@/latentheatlm/all