Enter Your Reply

Indeed, what Fairy-Max uses to define the pieces in its fmax.ini file is not
so much a notation, as well a direct reflection of how its move-generator
tables are to be filled. To equip it with some sort of compiler for a more
user-friendly format is something that never got off the to-do list. :-(

Basically it is just a list of step vectors on its internal 16x8 board,
which has the additional complication that white plays 'downstream' (so
-16 is one step forward, etc.). This has the advantage that any form of
asymmetry (also left-right) can be handled without extra provision. But it
has the disadvantage that the common case of totally symmetric pieces still
requires a cumbersome enumeration of each individual direction. Like to
define a Knight you would need +14, +31, +33, +18, -14, -31, -33, -18. It
would be nice to have some meta-symbol that would allow you to abbreviate
this to something like 18* or (2,1)*.

Apart from specifying each direction, you also have to specify what the
move can do in each direction (capture, non-capture) even in the
overwhelmingly common case where you can do both. So the common case is
that you have an enumeration now of STEP,RIGHTS codes, where RIGHTS equals 3
(for slider) or 7 (for leaper). For divergent pieces the RIGHTS can be 1 or
2 lower, depending on if capture or non-capture is forbidden. RIGHTS codes
larger than 7 are only needed for the more uncommon case of two-stage moves
(like hoppers or lame leapers). There you would have to specify (in the
high digit) another set of rights for the second stage of the move, with
very obscure encoding.

Special cases are castlings and initial pawn double pushes. I use an
otherwise useless RIGHTS code 4 for that (which in the system would
indicate a leaper move that can neither capture nor non-capture). Fairy-Max
takes that to mean the same as 0 (indicating a step that can't do anything
but is not the last stage of the move, so that it is still useful as an
intermediate step of a lame leaper, or a Grasshopper on the way to its
platform), except that you are only allowed to do it with a virgin piece.
So the double push of a Pawn is actually implemented as an independent
lame-leaper move added to the Pawn.

E.p. capture of pieces that did such a special virgin lame-leap was
hard-wired in Fairy-Max, and this is one of the things I had to change for
Spartan Chess. With the usual definition of the Pawns (either FIDE or
Berolina), the Hoplites could be e.p.-captured, and were forbidden to move
to a square just jumped over by a FIDE Pawn (because this was interpreted
as an attempt to e.p. capture the FIDE Pawn, and Berolinas are not allowed
to capture diagonally...). So I requisitioned some bits that would be
meaningless in this case from the high-order digit of the RIGHTS (if the
low-order digit is 4), to indicate that the e.p. square should not be set,
and to indicate if the double-push can be made even if the intermediate
square is occupied (for the Hoplites), and added some C-code to perform 
the required actions in response to these bits.