The state of an individual chess piece can be stored in 6 bits. 3 bits for the X coordinate, 3 bits for the Y coordinate. A captured piece can use the same co

The state of an individual chess piece can be stored in 6 bits. 3 bits for the X coordinate, 3 bits for the Y coordinate. A captured piece can use the same coordinates as the King, which would indicate that it's captured. For promoted pieces, you can use 3 bits per promoted piece type (Bishop, Rook, Knight, Queen) to indicate how many exist. For the case of 8 promoted pawns, you'd need one more bit to indicate that all pawns have been promoted and to treat a 7 as an 8. You need 1 bit to indicate who's turn it is. You need 1 bit per player to indicate if castling is still possible, and 1 bit to indicate if the last pawn move was two squares. What gets tricky is tracking for the draw rules. There's '50 moves with no pawn or capture', '3 move repetition', '5 move repetition', '75 moves with no capture or pawn move'. 50 or 75 are simple enough to count, but tracking identical boards from a previous state would be hard to do with limited bits. So then we have: 6 bits for piece coordinates of 32 pieces (192 bits) 13 bits for pawn promotion status for each player (26 bits) 1 bit per player for castling allowed (2 bits) 1 bit for whose turn 1 bit for en-passant possible 7 bits for move counter with no pawn movement or captures That works out to 29 bytes. Edit: Article did promotions much better by removing impossible promoted piece counts. 'Castling allowed' flag could be tied to 'both rooks in their original positions'. If the pieces look like they're in their original positions, but a king or rook moved, swap the two rooks so they're not in the original position anymore. En-passent check by swapping pawn order is neat, but pawn order could instead be used to eliminate the 'promoted' flag per pawn instead.