4 ms·
I had very similar thoughts but I think one can do much better, even. Each move only needs four bits to identify the piece because each side only has 16 pieces
by jprete 3y ago
I had very similar thoughts but I think one can do much better, even.
Each move only needs four bits to identify the piece because each side only has 16 pieces at maximum. The game replayer would need to keep track of each pawn's starting file though (including after promotions).
Variable-length encodings of the move options help a lot. Pawns only need two bits because there are never more than four legal moves for a pawn - except for promotions, but just handle those specially for those exact cases (if a pawn moves to the last rank then encode the promotion with two bits, otherwise encode the next move). Knights and kings each need three bits for the move - encode each king-castling option as a move to the appropriate rear diagonal (normally off the board so not otherwise legal). Bishops and rooks need four bits (rank and direction). Queens only need five (three bits for rank, two for direction).
This way you can get down to between six and nine bits per move.
- amluto 3y ago> The game replayer would need to keep track of each pawn's starting file though (including after promotions). That seems unnecessary. Don’t index the pieces based on their type and where they started — index them based on their current location. So the piece the lexicographically first (rank, file) is piece 0, and 4 bits trivially identifies a piece once you know the color.
- jprete 3y agoTrue, I hadn't thought of that.