You would still need 8 bits to store the move, as a Chess position can have more than 127 moves. And there are 8-bit encodings that do not need complete move generation, but just looking at the board. By concatenating piece type, the number of the piece of that type (according to a raster scan of the board), and the number of the move a piece of that type can have.jdart wrote:There is a trick you can use to store the moves, which is to implement a move generator that can produce moves in a repeatable sort order, and then store the move indices in the book. You don't have to store the move itself, because you can just run the move generator, get the full list of moves and then pick the nth move, where n is returned from the book.
E.g. Pawns can have 4 moves, and you can have 8 of them, so this requires 32 codes. Knights and King have 8 moves, and you have 3, so 24 more codes. Rooks and Bishops have up to 14 (use 16), and you have four, so 64 more codes. There even would be room for some over-completeness and for under-promotions. Not exhaustive, but how much of that would you need in the opening...?
Polar coordinates also can be useful, in large variants. E.g. to make a book for Maka Dai Dai Shogi in Polyglot format would be a problem, as it has a 19x19 board, so that a square number no longer fits in a byte, and the move field of 16 bits can no longer hold from- and to-square. But you can encode as from-square (9 bits), orientation (2 bits) and location along the ray (5 bits). That even leaves some codes (with invalid square numbers) to indicate special moves, like Knight jumps, by indicating an ID number of one of the few pieces that have such moves, and the number of the move.