X-FEN for FullChess Variants Extension Proposal

[smrf]

Of course not every engine must support all thinkable variants. But X-FEN should become able to support a wider range of variants partially compatible to traditional chess.

a) 6x6, 6x8, 8x8, 10x8, 10x10 board geometries will be supported - they could be recognized analyzing the initial X-FEN tag.

b) supported piece types are traditional PNBRQK and A=B+N, C=R+N, G=Q+N.

c) the default piece set (for promotions) is the traditional set, and additionally A+C for 10x? boards.

d) there are variants with reduced piece sets e.g. like Janus Chess (no C) and Los Alamos Chess - here an optionally following separated tag ":C" (example for Janus Chess, initial ':' followed by type letters) could switch on or off piece types for possible promotions.

e) pawns (moved ore unmoved) will be allowed to move forward several steps at once over free squares but not multistepping more than before the middle of the board, where passed squares become possible e.p. targets (thus the optional e.p. target square implicitely might point to more than one shown target).

More on this will follow soon.

[smrf]

f) the e.p. field has to be supported exactly then, when at least one pseudolegal e.p. capture would be possible - the most outer coordinate of possible target squares has to be used then (because the old position of the moved pawn will be not to be derived e.g. at 10x10 boards).

g) castling moves normally are done as follows: the King is placed THREE steps from the a-side (O-O-O) or TWO steps from the other side (O-O), then the related rook will be placed inner beside the king. At random starting arrays there it could be, that the king does only one or none step during such a Fischer-Castling, thus that move in algebraic natation cannot always be encoded merely by source and target coordinates to distinguish it sometimes from a regular king's move or a kind of nullmove. Thus the column letter of the involved rook should be appended then, comparable to method of distinguishing different promotion kinds by piece letters.

h) in the case of free castling the target position of the king could vary. Thus it will be necessary to modify the O-O / O-O-O notation, too. Here the target colum letter has to replace the last 'O': e.g. O-O-b when castling towards the a-side placing the King upon b1.

[smrf]

i) castling rights letters Qq traditionally address rooks at the a-side of the matching king, letters Kk adress rights at the other side. The castling right normally belongs to the most outer rook at that side. In case it should belong to an inner (of several) rook, the matching castling right letter has to be replaced by the column letter of the related rook: using upper case for white castling rights, lower case for the black (this probably will be necessary only in less than 0.001% of all cases). This method is 100% compatible to traditional FEN.

j) the castling letters might be preceded by an additional letter indicating different castling methods: 's' for symmetric castling (as in Janus Chess), 'm' for modern castling (as in Embassy Chess), or 'x' for free castling.

[smrf]

k) the communication between engine and GUI always has to be done using the piece letters as from introduced above: PNBRQK+AC+G. But there are some variants traditionally using different letters. This has to be a task of the GUI only. Thus this has to be declared inside a comment-type PGN token, e.g. for Janus Chess: [Variant "Janus J=A"] or for Embassy Chess: [Variant "Embassy M=C C=A"]. The PGN move notation then has to use the letter replacements for move pieces. The X-FEN itself always has to remain unchanged, because it has to be a common approach.

[hgm]

I am not in favor of FEN formats that try to specify the rules of the game, rather than just the game state. I think that specifications on what type of promotions are allowed, or which type of castling, belong in this category. The castling field should specify the thing that cannot be seen from the board position or the rules, namely if the pieces have moved before, or not.

Pawns with different promotion possibilities are just not the same piece type. So if you want to have universal meaning of the letters (which is a bad idea; see below), you should different letters for Janus-Chess Pawns and Capablanca-Chess Pawns. Using P for the latter is a bad idea, as there are Capablanca variants on 8x8 (e.g. Seirawan Chess), where the Pawns can promote to Hawk or Elephant (A or C).

Having fixed piece-indicator letters will not work, as there are more than 26 pieces, and long before that you will run out of sensible abbreviation letters. E.g. the usual meaning of C (employed by ~70% of the World's Chess players) is Cannon, not Chancellor, and A = Advisor, not Archbishop. For 200 Million Chess players G = Gold General, not the Amazon (Q+N) piece. This can be solved to some extent while maintaining compatibility with existing standards by making the default meaning of the letters dependent on the board dimensions. Then C cound be Cannon on 9x10 boards, but Chancellor on 10x8 boards.

As far as a universal system for assigning letters to pieces goes, I would like C ('Cardinal') for Archbishop and M ('Marshall') for Chancellor, so that the Amazon could be designated by 'A', better than A and C.

For e.p. captures, in some variants it cannot be avoided giving the complete Pawn move in the e.p. field of the FEN. E.g. with Berolina Pawns, both specifying the Pawn that can be captured, and specifying the place you have to move to to capture can be ambiguous.

[smrf]

I am not in favor of FEN formats that try to specify the rules of the game, rather than just the game state. I think that specifications on what type of promotions are allowed, or which type of castling, belong in this category. The castling field should specify the thing that cannot be seen from the board position or the rules, namely if the pieces have moved before, or not.

My approach is to have a unique board position declared inside a unique FEN. This avoids the need to keep a list of to be implemented variants always up to date. And it avoids the nonsense of encoding same traditional chess positions by different FEN strings simply if they might stem also from a Chess960 position.

Pawns with different promotion possibilities are just not the same piece type. So if you want to have universal meaning of the letters (which is a bad idea; see below), you should different letters for Janus-Chess Pawns and Capablanca-Chess Pawns. Using P for the latter is a bad idea, as there are Capablanca variants on 8x8 (e.g. Seirawan Chess), where the Pawns can promote to Hawk or Elephant (A or C). ...

I do not want to encode everything thinkable variant by X-FEN. I am targetting FullChess positions downwards compatible to chess and combinations of gaits existing there. If you want to cover more you have to do a very different and much bigger task. But my intended X-FEN extension is no obstacle for you to do this. (P.S.: promotion possibilities are specific to a game, not to a single pawn. Thus it is redundant to encode that multiply by different pawn letters.)

[smrf]

As far as a universal system for assigning letters to pieces goes, I would like C ('Cardinal') for Archbishop and M ('Marshall') for Chancellor, so that the Amazon could be designated by 'A', better than A and C

Well, this would affect actually stored positions, but that is not that much. So M=R+N and C=B+N could be a solution for X-FEN, too. Because the [Variant] tag would be able restore its common use e.g. for CRC. (P.S.: same would be valid for A=Q+N.)

Also the integration of K+N or K+B as piece types might be possible using two additional letters.

[smrf]

d) there are variants with reduced piece sets e.g. like Janus Chess (no C) and Los Alamos Chess - here an optionally following separated tag ":C" (example for Janus Chess, initial ':' followed by type letters) could switch on or off piece types for possible promotions.

An additional '*' would imply, that only such piece types could be used to promote into, which are not already standing on the board (having the same colour). Such kind of rule is used in Superchess.

[hgm]

I do not want to encode everything thinkable variant by X-FEN. I am targetting FullChess positions downwards compatible to chess and combinations of gaits existing there. If you want to cover more you have to do a very different and much bigger task. But my intended X-FEN extension is no obstacle for you to do this. (P.S.: promotion possibilities are specific to a game, not to a single pawn. Thus it is redundant to encode that multiply by different pawn letters.)

For WinBoard I do want a FEN standard that works for all variants it supports now, or might support in the future, and this could be pretty much any thinkable variant. I don't want to needlessly complcate the FEN format with specialized features that serve no purpose other than to specify variant rules (such as castling types or promotion choices) that only work for Fullchess.

So in WinBoard I will use a FEN type that is not necessary upward compatible (or even compatible) with X-FEN. Winoard will always interpret FENs in the context of the currently active variant, i.e. the variant will supposed to be known, and the meaning of piece-indicator letters can depend on the variant.

For variant fairy, which is meant as a loosely defined variant in which pretty much any piece can participatte, I might allow 'descriptive notation' for a piece. In this notation, a piece would not be described by a single letter, but by a group of letters and symbols specifying the moves, between parentheses. The letters within the parentheses will be universal (i.e. variant independent), similar to so-called Betza notation.

[smrf]

The flexibility of renaming piece types within a GUI by using a [Variant] tag as introduced will also work on base of the current X-FEN piece letters. Thus there I am not seeing any must of a renaming. As long as there are no very convincing arguments against those current letters I think it will be best to keep this convention.