I think my initial stab would be to encoding the source position (6 bits) and end position (6 bits) for a constant 12 bits per move.
You don't need to store whether it's a capture, you can figure that out from the game state. You don't need to store disambiguations, there are none in that format. You don't need to store check/mate, you can figure that out from the game state.
The only wrinkles (that I can tell) are castles and promotions. But you can get around this by the fact that kings and pawns have limited movement, so their legal destination squares are highly constrained.
So you could signal a promotion by encoding the destination with opposite rank, and using the file to encode which piece. Promoting to a rook on c8 gets its destination encoded as a1 - "a" for a rook, and "1" to indicate a promotion.
Similarly, you could encode a castle by encoding the king's move with opposite destination rank. Castling the king to f1 gets encoded as f8, and to g1 as g8.
> Similarly, you could encode a castle by encoding the king's move with opposite destination rank. Castling the king to f1 gets encoded as f8, and to g1 as g8.
You are overcomplicating this. For castling just record it as the King's source and destination. E.g., White kingside castling is e1g1, White castling queenside is e1c1, Black castling kingside is e8g8, and white castling queenside is e8c8.
All king moves other than castling move the king at most one file, so when you see a king on e1 and the move is e1g1 or e1c2 which is a move of two files you can infer that it must be castling.
For promotion, I suggest splitting it into two cases: promotion to a queen and promotion to something else. I saw a post once on Reddit from someone who analyzed promotions from all games in the Lichess database, and 98.7% were to queens, so we'll make that case the simplest.
I suggest that pawns that promote to a queen are simply recorded as moving to the promotion square. It is implicit that they promote to a queen. For example a pawn at b7 that moves straight forward and promotes to a queen would be recorded as b7b8. A pawn at b7 that captures on a8 and promotes to a queen would be recorded as b7a8.
For pawns that promote to a rook, record the move as a move to a square one rank back from the promotion square. For example b7b8 promoting to rook would be recorded as b7b7, and b7a8 promoting to a rook would be recorded as b7a7.
Similarly for promotions to bishops. Record the destination two ranks back. So b7b8 promoting to bishop would be b7b6. Similar for knights but three ranks back, so b7a5 for a pawn at b7 that captures on a8 and promotes to a knight.
> All king moves other than castling move the king at most one file, so when you see a king on e1 and the move is e1g1 or e1c2 which is a move of two files you can infer that it must be castling.
Yeah. For some reason I had a brain fart and thought that the two castles moved the king 1 and 2 files, instead of 2 and 3 files, and that made me think you needed to disambiguate a 1 file castle with a 1 file move.
Which is clearly dumb. I blame insufficient coffee.
Both O-O and O-O-O castles move the king by two squares.
It gets more interesting if you want to also store fisher random chess, because the casting can involve a king move by any number of swuares or not moving at all. But even in this case the casting could be unambiguously recorded as a move by 2 squares(even if the king doesn't move at all)
As for promotion: in a valid chess position you could promote a single pawn at three files simultaneously. One by moving forward and then left and right capture. Additionally, you could have two pawns promoting on the same square, again with capture. And you can have a combination of both.
Encode a white's move exd8=N with white pawns on e7 and c7 and three black queens on f8, d8 and b8.
> you could promote a single pawn at three files simultaneously. One by moving forward and then left and right capture.
Ooh, didn't think of that, thanks. Still there's enough constraint in the legal destination squares to work around that. There's at least half the board that's inaccessible to a pawn about to promote, which should be enough to encode any of the 3 legal destination squares and 5 possible promotion targets.
Edit: maybe keep the destination file as-is, and use the destination rank to encode the promotion piece?
> Additionally, you could have two pawns promoting on the same square
The source square should disambiguate between those though, right?
Source position -> 6 bits
destination position as (
forward left / forward / forward right -> 2 bits
Target piece info Queen/Bishop/Knight/Rook 2 bits
)
I think my initial stab would be to encoding the source position (6 bits) and end position (6 bits) for a constant 12 bits per move.
You don't need to store whether it's a capture, you can figure that out from the game state. You don't need to store disambiguations, there are none in that format. You don't need to store check/mate, you can figure that out from the game state.
The only wrinkles (that I can tell) are castles and promotions. But you can get around this by the fact that kings and pawns have limited movement, so their legal destination squares are highly constrained.
So you could signal a promotion by encoding the destination with opposite rank, and using the file to encode which piece. Promoting to a rook on c8 gets its destination encoded as a1 - "a" for a rook, and "1" to indicate a promotion.
Similarly, you could encode a castle by encoding the king's move with opposite destination rank. Castling the king to f1 gets encoded as f8, and to g1 as g8.