You are on the backup site for Chessvariants.com. Any posts, moves, or other changes you make here will not be permanent, because the pages and database from the main site will be backed up here every midnight EST. Additionally, things may not be working right, because this site is also a testbed for newer system software. So, if you are not here to test, develop, or merely read this site, you may want to change .org to .com in the navigation bar and go to the main site.



The Chess Variant Pages




[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Earliest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Single Comment

Fairy-Max: an AI for playing user-defined Chess variants. A chess engine configurable for playing a wide variety of chess variants.[All Comments] [Add Comment or Rating]
H. G. Muller wrote on 2021-06-26 UTC

The way castling works in Fairy-Max is that any piece that has castlings amongst the moves on its definition line will castle with the piece on the same rank on the left or right edge. Provided both are virgin. The problem is that while setting up a position from an external source, virginity is judged by whether the piece is placed in the same position as the internal start position. And that currently the internally defined start position can only have non-Pawns on the back rank, and a single rank of Pawns placed on another rank (which cannot be specified fully independently from the width of the promotion zone).

This is already versatile enough to implement many chess variants, but by no means all. Multi-variant engines like Sjaak II are much more flexible in this respect.

What I am thinking about is to allow the lines that specify the (non-Pawn) piece placement in the fmax.ini file to be longer than the board width, and put the extra pieces that are specified on the next rank, bumping the Pawns one rank forward for every new rank. For engine-defined variants Fairy-Max has to communicate the internally defined initial position to the GUI in FEN format, though. And the current FEN generator is not completely general, but assumes there will only be pieces on the back rank. So this will have to be entirely rewritten.