I'm thinking about developing an optimized chess database file format. I can record a single move in 12 bits: two squares, each one with two coordinates, where each one is a number from 1 to 8.
Algebraic notation only shows the destination square for a move and the piece's type (either blank for pawn or a letter for one of the five non-pawns), which is also 12 bits; but when two pieces of the same type can move to the same square, they're disambiguated by which file the piece was on before, which is another 8 options or 3 bits. (Castling could be encoded as a king move of two squares' distance, rather than being a special case like SAN does it.)
My idea was to encode the move with just the destination square, and when there's ambiguity, select which one of the pieces it can be by enumerating them in some standard order then indicating which one it is with some index.
How big should the space for this index be? What's the largest number of squares on which there can be pieces that all attack a particular square, and what's an example of such a position (so I can use it for testing)?
