This is very cool and having stalemate is nice, however how much space would it take to implement the full ruleset?
As you write: not implemented: castling, en passant, promotion, repetition, 50-move rule - those are all required to call the game being played modern chess.
I could see an argument for skipping repetition and 50-move rule for tiny engines, but you do need castling, en pessant and promotion for pretty much any serious play.
Cool project. You could also use the front-end of GNU chess to save some lines, and implement only a back-end.
Bug report:
a b c d e f g h
8 r n b q k b n r 8
7 . . p p p p p p 7
6 . p . . . . . . 6
5 p . . . . . . . 5
4 P . . P P . . . 4
3 . . . . . . . . 3
2 . P P . . P P P 2
1 R N B Q K B N R 1
a b c d e f g h
move: b2b3
ai: b6b4
The pawn is not permitted to move two fields after it has already beeen moved once before: b6b4 isn't a valid move after b7b6. (First moving two fields, and then one would have been okay, in contrast.)
If anyone is curious, the most common tool I've seen for ELO estimation among engine developers is cutechess [1], which uses SPRT [2]. Or ordo [3], haven't used this myself though
maybe for very low ratings it's plausible?
1 elo per byte might happen in a tiny range
but at a useful strength it would break fast, that's what i think
What's the snallest possible program that accepts a chess board state and prints any legal move? True randomness may only have a couple hundred ELO, but then, that's pretty big for golf
How many games did you have to throw away because stockfish wanted to castle? Or did you force stockfish to not castle? Castling seems like such a frequent move it is hard to draw any conclusions about the strength of an engine that does not support it.
zero games were thrown away for castling, because i forced stockfish not to castle (and not to play en passant/promotion) by filtering legal moves and only giving those filtered moves via root_moves
so every game stayed in the same no castling variant
and you're right, this rating is for that constrained variant, not full chess.
It's wild to think that 4096 bytes are sufficient to play chess on a level beyond anything humans ever achieved. Makes you think what other difficult tasks are out there that take even highly gifted humans years or decades to master, but a superior algorithm would more or less fit into one of those big QR code formats.
These things always make me think back to Westworld season 2, where the finale revealed that human minds are much simpler than they themselves believe and fit completely into an algorithm that could be printed in an average book.
Well, one of the most fundamental algorithms for building a chess AI is minimax [1] (or variants like negamax), and that’s been around for close to a century. The key difference is that as compute power and available RAM have grown, it’s become possible to search much deeper and evaluate far more plies.
So while 4k is still very impressive for the code base, it comes with a significantly larger runtime footprint.
If you look at the current winner [1], it does a lot more than just brute force tree search. The space state for chess is simply too big to cover without good heuristics. Deep Blue may have been a pure brute force approach to beat Kasparov after Deep Thought failed using the same core algorithm, but modern chess engines search far deeper on the tree with far fewer nodes than Deep Blue ever could thanks to better heuristics.
I'm not suggesting that it's only brute force tree search, just that it's not very complicated to develop a theoretically perfect chess engine in direct response to the parent
> It's wild to think that 4096 bytes are sufficient to play chess on a level beyond anything humans ever achieved.
The mailbox board representation is a good call for size-constrained engines. Bitboards give faster move generation but the manipulation code (shifts, masks, magic numbers for sliding pieces) eats a lot of bytes. With mailbox you just need offset tables and a sentinel check for board edges. Curious what your evaluation function looks like though. At 2KB you can't fit piece-square tables (that's 384 values minimum for both colors), so are you doing material-only eval or did you squeeze in some positional heuristics?
The gap between your 1200 Elo in 2KB and the TCEC 4K engines at ~3000 Elo is interesting. That extra 2KB buys a lot when it goes to better evaluation and move ordering. Even a simple captures-first sort in alpha-beta pruning costs only a few bytes of code but can roughly double your effective search depth.
This is very cool and having stalemate is nice, however how much space would it take to implement the full ruleset?
As you write: not implemented: castling, en passant, promotion, repetition, 50-move rule - those are all required to call the game being played modern chess.
I could see an argument for skipping repetition and 50-move rule for tiny engines, but you do need castling, en pessant and promotion for pretty much any serious play.
https://en.wikipedia.org/wiki/Video_Chess fit in 4k and supported fuller ruleset in 1980 did it not?
So I would ask what is the smallest fully UCI (https://www.chessprogramming.org/UCI) compliant engine available currently?
This would be a fun goal to beat - make something tiny that supports full ruleset.
PS my first chess computer in early 1980s was this: https://www.ismenio.com/chess_fidelity_cc3.html - it also supported castling, en pessant, not sure about 50 move rule.
Cool project. You could also use the front-end of GNU chess to save some lines, and implement only a back-end.
Bug report:
The pawn is not permitted to move two fields after it has already beeen moved once before: b6b4 isn't a valid move after b7b6. (First moving two fields, and then one would have been okay, in contrast.)Thanks for pointing it out! I will try to patch it.
Appreciate you taking the time to test it.
If anyone is curious, the most common tool I've seen for ELO estimation among engine developers is cutechess [1], which uses SPRT [2]. Or ordo [3], haven't used this myself though
[1] https://cutechess.com/
[2] https://www.chessprogramming.org/Sequential_Probability_Rati...
[3] https://github.com/michiguel/Ordo
Do you think it would be possible to achieve 1:1 ELO:bytes? Even smaller, but can be less smart.
That's an awesome code golf challenge
maybe for very low ratings it's plausible? 1 elo per byte might happen in a tiny range but at a useful strength it would break fast, that's what i think
What's the snallest possible program that accepts a chess board state and prints any legal move? True randomness may only have a couple hundred ELO, but then, that's pretty big for golf
How many games did you have to throw away because stockfish wanted to castle? Or did you force stockfish to not castle? Castling seems like such a frequent move it is hard to draw any conclusions about the strength of an engine that does not support it.
zero games were thrown away for castling, because i forced stockfish not to castle (and not to play en passant/promotion) by filtering legal moves and only giving those filtered moves via root_moves
so every game stayed in the same no castling variant
and you're right, this rating is for that constrained variant, not full chess.
https://www.chessprogramming.org/Toledo is a family a moderately strong tiny chess programs.
If you ever spent much time at a chess club, you've seen why 2kB is a really disturbing number.
I have not. Can you please tell me why?
He's just trying to trick HN readers to join chess clubs.
Not really. You have to see it for yourself.
(Partial answer, 2kB is a very small fraction of what we'd like to think counts as human.)
Humans don't have much capacity for systematic tree search. It's sort of amazing that humans can do as well as they can, given that limitation.
Cool that you could keep it under 2k but it would nice to have a readable version of the source code.
Do you work with it like this or do you have some sort of script you apply to get it down to a single line, single letter variable names?
What you’re describing is the typical output / function of a minifier
The real fun would be reverse-engineering the minified code (there are loads of tools to do this for chrome extensions)
not lossless
How did you handle games where Stockfish would castle or promote?
i forced stockfish to play only non castling, non en passant, non promotion moves by filtering legal moves and passing only those as root_moves
also removed castling/EP rights from FEN
I'd call that cheating but the size and capability is impressive nonetheless.
This is amazing! Thanks for sharing. What would be the elo gain for 4KB engine?
P.S. I assume 1200 elo in chess com scale (not lichess / fide elo) and bullet chess variant?
There is a TCEC category for 4k engines. The top ones are ~3000 Elo.
It's wild to think that 4096 bytes are sufficient to play chess on a level beyond anything humans ever achieved. Makes you think what other difficult tasks are out there that take even highly gifted humans years or decades to master, but a superior algorithm would more or less fit into one of those big QR code formats.
These things always make me think back to Westworld season 2, where the finale revealed that human minds are much simpler than they themselves believe and fit completely into an algorithm that could be printed in an average book.
Well, one of the most fundamental algorithms for building a chess AI is minimax [1] (or variants like negamax), and that’s been around for close to a century. The key difference is that as compute power and available RAM have grown, it’s become possible to search much deeper and evaluate far more plies.
So while 4k is still very impressive for the code base, it comes with a significantly larger runtime footprint.
[1] - https://en.wikipedia.org/wiki/Minimax
The core search algorithm is very simple though. 4KB engines may not run that fast if they do exhaustive search, but they’ll be quite accurate.
According to TCEC the time control is 30 mins + 3 sec, that’s a lot of compute!
If you look at the current winner [1], it does a lot more than just brute force tree search. The space state for chess is simply too big to cover without good heuristics. Deep Blue may have been a pure brute force approach to beat Kasparov after Deep Thought failed using the same core algorithm, but modern chess engines search far deeper on the tree with far fewer nodes than Deep Blue ever could thanks to better heuristics.
[1] https://github.com/MinusKelvin/ice4
I'm not suggesting that it's only brute force tree search, just that it's not very complicated to develop a theoretically perfect chess engine in direct response to the parent
> It's wild to think that 4096 bytes are sufficient to play chess on a level beyond anything humans ever achieved.
Oh my god the source is so tiny! It's really hard to parse because of it being minified but I love it to bits.
Good job! I love how you obfuscated your code, really in a spirit of FOSS!
Oh well, the file initially looked like https://github.com/datavorous/sameshi/blob/7ab4e47144f96becd...
It is hideous now!
Coworker: “hey if you have a second, I have a one-liner PR open”
The PR:
The mailbox board representation is a good call for size-constrained engines. Bitboards give faster move generation but the manipulation code (shifts, masks, magic numbers for sliding pieces) eats a lot of bytes. With mailbox you just need offset tables and a sentinel check for board edges. Curious what your evaluation function looks like though. At 2KB you can't fit piece-square tables (that's 384 values minimum for both colors), so are you doing material-only eval or did you squeeze in some positional heuristics?
The gap between your 1200 Elo in 2KB and the TCEC 4K engines at ~3000 Elo is interesting. That extra 2KB buys a lot when it goes to better evaluation and move ordering. Even a simple captures-first sort in alpha-beta pruning costs only a few bytes of code but can roughly double your effective search depth.
Codex or Claude Code?
none.
scribbling long enough on a piece of paper is more enjoyable than prompting.
a thousand times this.