Variant FENs: a Call for Sanity

May 30, 2016, 8:08 AM |

FEN does a pretty good job of describing a standard chess position: a simple space-delimited string encodes, from left to right, the following information:

  • the board setup
  • whose turn it is
  • castling rights ("-" for none)
  • en passant capture square ("-" for none)
  • half-move clock for the fifty-move rule
  • fullmove number

With these fields we can record all of the details necessary to recreate any standard chess position.  Here I argue that we can, and should use the exact same fields for the hundreds of existing and yet-to-be-created chess variants; and that any variant-specific info should be added to the end as extra fields, leaving the standard FEN fields unmodified.

This enables software that only supports standard chess to display at least the board setup of a variant position, provided it just ignores the extra fields.  More importantly, from an engineering perspective, it gives variant implementers an extremely easy, clean and performant way of parsing and generating FENs: let the existing FEN library handle the first 6 fields, then look for the extra fields and apply any further manipulations.  Generation can likewise be done by creating a standard FEN and adding stuff to the end.

Here are some examples with real variants:


Extra fields

  • Number of checks given by white
  • Number of checks given by black

Parsing method

  1. Get position from existing FEN library
  2. Look for 7th field; set white's check count or default to 0
  3. Look for 8th field; set black's check count or default to 0

Note that this algorithm supports standard FEN strings by just defaulting the check counts to 0 if not present.


Extra fields

  • Piece holdings, represented in the same way as a rank of pieces in the board setup field, or "-" for none.  For example, "PPPrbq" represents white having 3 pawns available to drop and black having a rook, a bishop and a queen.
  • Locations of promoted pieces -- algebraic square notation, separated by commas (necessary because promoted pieces revert to pawns when captured).

Parsing method: again, standard FEN utilities can be used to generate a position from the first 6 fields, and then the Crazyhouse code can take-over, set piece holdings, and mark pieces as promoted with whatever internal representation is used.

Some Crazyhouse FEN formats currently in use mark promoted pieces by embedding extra characters in the board setup field, and place the holdings directly after it; needlessly breaking compatibility with standard FEN viewers and preventing code re-use. 

2-move Chess

Extra information needed

  • 2-move number (whether the active player is on the first or second move of their turn)

Standard FEN already has "w" or "b" for the active player.  We could easily extend that and use "w1"/"w2"/"b1"/"b2", or perhaps "w"/"W"/"b"/"B".  We could use some nifty regular expressions to do the conversion in a couple of lines.  But why bother?  The easiest solution -- and by far the most maintainable one, as the number of variants we support increases over time -- is to tack "1" or "2" to the end and let existing FEN code handle the rest.

Variants generally modify the rules, having been created as a way of exploring and expanding what can be done with a standard chess board (or boards...)  The basic elements stay the same, with any new constraints or abilities requiring extra information to be stored, not different information; so the resulting extensions to the FEN format should be just that -- things added on.