Custom fairy pieces in Fairy Stockfish

[hgm]

Current Fairy Stockfish allows the definition of custom pieces in its configuration file variants.ini, in which people can specify the rules of chess variants of their own design. To this end FSF has a large number of magic bitboard tables, computed at startup, for a variety of standard moves. Currently it has tables for Rooks, Bishops, the hopping and grasshopping versions of those (which contain the moves between the 1st and 2n obstacle in the path, or the square just after the 1st, rather than the moves up to the 1st obstacle), Nightriders and some lame leapers (Xiangqi Elephant and Horse, Janggi Elephant). Custom pieces can then select any number of those for being used in the generation of their moves, possibly selecting only a limited number of directions the full moves offer. (E.g. for a piece that move forward like a Bishop and backwards along a file (the 'Y') it would use the Bishop and Rook tables, masking away the unwanted slides afterwards.)

Obviously selection from a given set of possibilities limits what you can do to the possibilities on offer. Expanding on that by adding new tables is of course possible, but it just pushes the limits rather than removing those. And it leads to a proliferation of magic bitboard tables, most of which would never be used. (How many variants contain a Grasshopper. Or a Nightrider?)

So I decided to start working on another approach: not use a fixed set of tables initialized at startup, but create tables on the fly to serve the selected variant. The number of pieces in a typical variant might already be smaller than the number of different moves for which tables are now created at startup, saving time on the creation of the tables. In addition, tables can be generated for the board size in use, rather than the maximum supported board size (12x10 in the largeboards version), also saving time. An additional advantage is that the tables can be adapted to the individual pieces, often allowing the move generation to be done with fewer lookups than when using standard tables. E.g. the mentioned Y piece could easily generate all its three slides in a single lookup even on 12x10. While drawing on standard Rook and Bishop tables would have to combine lookups in each of those to generate Queen moves, of which it would then select the Y part using a mask.

So the aim is to automate generation of magic-bitboard tables from an (arbitrary) description of a piece move. This would then also allow implementation of pieces that don't slide along a straight path, but trurn corners, or move along circles. I will use this topic thread to blog on this project.