248 is max in my case (actually later I noticed I could shave another 4 bits), if there are less pieces, there will be less data
But probably with encoding your solution would be better
But probably with encoding your solution would be better
1 bit for each square represent there is a piece on that pos so 64 bits
then for each side, 4 bits to represent number of pieces and 3 bits for each piece to represent their type
At max 64 + 2x(4 + 3 x 16)=168 bits for 16 pieces each side.
edit: nvm this wouldn't work since you wouldn't know the colors of the pieces on board. You need to store 4 bits for each piece, 1 color + 3 type so it is 64 + 2 * 4 * 16 = 196. I am not sure if this is better anymore
To beat it you must encode each piece with a different number of bits. E.g.
Q c00
N c01
P c10
B c110
R c1110
K c1111
The issue is that each time a P is promoted to R or B (a stupid thing to do, since a Q would be better) you need one or two bits more. On the other hand, you spare 3 to 5 bits for each captured piece. In normal play, captures outnumber promotions, and promotions are either to Q or N, never R or B, but theoretically...
As far as max size goes, 64 bits plus data per piece seems to be the right path. Especially if you huffman the pawns to be 3 bits each while other pieces are 4 bits.
The grandparent method gets pretty bloated when you start promoting.