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)?

  • Pieces of just one color, or both?
    – D M
    Commented Feb 28 at 23:27
  • @DM Single color, because that's the only thing that matters for the question of determining that color's next move.
    – Danya02
    Commented Feb 29 at 6:10

1 Answer 1


Assuming you mean pieces of just one color, 15 can be attacking one square:

[fen "B3R3/7Q/3N1N2/2N3N1/3Kn3/2NP1PN1/3N1N2/4R3 w - - 0 1"]

The wrong-colored bishop is the only one that can't participate.

  • If it matters, those pawns could also have promoted to bishops. Just in case you don't count pawns as "pieces" for your purposes.
    – D M
    Commented Feb 28 at 23:33

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.