X-FEN for FullChess Variants Extension Proposal

[smrf]

a) E.g. 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.

(To enable a wider acceptance of names beside of christian areas I will prefer using more neutral names: A=Archangel, C=Centaur, G=Giant)

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

d) there are variants with reduced (promotion) 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 additionally following '*' 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.

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).

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 (first passed) coordinate of possible target squares has to be used then (because the old position of the moved pawn will not be derivable 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 notation 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 (lower case) column letter of the involved rook should be appended then, comparable to method of distinguishing different promotion kinds by (upper case) 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.

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 (distinct from column letters) 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.

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]

And for people that want their FENs and PGNs be undestood by WinBoard;

Use the letters to indicate pieces that are defined as defaults for the variant that is being played. E.g. C=Cannon and A=Advisor in Xiangqi, and Archbishop=J in Janus Chess, A in Capablanca/Gothic Chess, and S in Superchess. And don't use any spurious characters in the castling field (only KQkq or the file letter).

[smrf]

Harm, I see that you are coming from the Winboard world. There is an approach to name variants in the dialog between an engine and a GUI. This leads e.g. to the strange behaviour, that it demands for differently encoded algebraic castling moves depending on being inside normal or fischerandom. I dislike that approach very much.

X-FEN tries to avoid the need of an engine to have a register of valid known variants, instead it could be open for a big family of chess related FullChess variants. X-FEN is not intending to support all possible variants, often being very far from traditional chess. This is left to other variant fans, to find a solution beside of FEN or X-FEN.

In the castling field there have to be encoded castling relevant data. Having the traditional castling method working there is no need for any additional letter, thus staying compatible to FEN. Other variants like Janus will not at all be understood by traditional engines, thus an additional letter 's' for symmetric castling is giving no additional killer argument here.

Using different piece letters within X-FEN at different variants will unnecessarily make it very difficult to support a lot of densly chess related variants by one single engine. Moreover it should be the task of the GUI to translate standard X-FEN piece letters into variant specific preferred letters or at least finally into language depending letter sets as e.g. for German: PNBRQK -> BSLTDK. So I intend to have a common X-FEN syntax which will be independently consistent from single variants.

It seems not to be attractive to start a discussion on to be used letters for any new variant, which wants to be supported by X-FEN. Instead I suggest to use a commenting PGN token: [Variant "..."] as proposed to customize such requirements via the GUI.

[hgm]

Indeed, under WinBoard, engine and GUI are always aware of the variant being played. Unlike X-FEN, WinBoard aims to support as wide a variety of variants as possible. This would be frustrated by assigning fixed (variant-independent) letters to piece types, as there are not enough letters in the roman alphabet. So of necessity, WB will need to transfer additional information on what the letters in the FEN mean, and sending the explicit name of the variant is a very compact way of doing that.

Once the variant name is sent, extra information in the FEN is redundant, and would needlessly complicate the FEN reader. I prefer to simply send different variant names, than first create ambiguity by giving variants with different rules the same name ("fullchess"), and then having to resolve the ambiguity in the FEN in a cumbersome way.

But of course you can define what you like for X-FEN standard. I only want to make people aware that this standard is not the standard that WinBoard uses. So if they want to run their engines under WB, or load te games andd positions from their databases into WinBoard, they better use the WinBoard standard, and not X-FEN.

[smrf]

Maybe following piece list is more acceptable (Eng/Ger):

Code: Select all

		SYMB_BAU = 'P', // Pawn         Bauer     'B'
		SYMB_SPR = 'N', // Knight       Springer  'S'
		SYMB_LAE = 'B', // Bishop       Läufer    'L'
		SYMB_ERZ = 'C', // Cherub   B+N Erzengel  'E'
		SYMB_TUR = 'R', // Rook         Turm      'T'
		SYMB_MIN = 'M', // Minotaur R+N Minotaurus'M'
		SYMB_DAM = 'Q', // Queen        Dame      'D'
		SYMB_AMA = 'A', // Amazone  Q+N Amazone   'A'
		SYMB_KOE = 'K', // King         König     'K'
		SYMB_FAU = 'F', // Faun     K+N Faun      'F'
		SYMB_GRE = 'G', // Griffon  K+B Greif     'G'
		SYMB_HYD = 'H', // Hydra    K+R Hydra     'H'

[hgm]

The problem is that no list is acceptable as a universel convention piece abbriviations, as there are more possible pieces than letters. It is the idea of having such a universal list that is flawed, and the fact that some specific choice for naming the pieces could be less objectionable than others cannot cure that..

[smrf]

Hmm, my intention is to support such piece types coming from traditonal chess or being paired combinations of those. This is part of the so called FullChess approach. For this subset of existing variants I plan to extend the usability of FEN/X-FEN to provide a common vehicle for communication e.g. between GUIs, engines or databases, targeting this variant family alone.

It nevertheless would be fine to have a convergence within that limited goal, even if it is not intended to support any thinkable variant e.g. as presented at the chessvariants.org site.

You are right when stating that this approach cannot support every variant, but that is no argument for not to try to do the very best for the FullChess subset. I wonder, why you are not arguing even harder against traditional FEN, too, which is supporting merely traditional chess.

If you have convincing ideas to support all known variants by another approach, simply do it, and do not hesitate. I am not working for that huge goal.

[hgm]

Indeed, I do not hesitate, as should be apparent from the fact that what you cheer me on for has already been done.

WinBoard does aim to support a large variety of variants, in particular the variants that are most played, such as Xiangqi, Shogi, FIDE Chess, Crazyhouse, Suicide, Chess960, Gothic Chess. And it does use FENs to communicate with the engine. And the X-FEN standard you suggest is not cmpatible with the FENs that WinBoard sends or expects.

So this gives people a choice: they either should use X-FEN, and take it for granted that their engines will not be able to run under WinBoard, and their PGNs cannot be loaded into WinBoard, or they should stick to the WinBoard standard.

[smrf]

... And the X-FEN standard you suggest is not cmpatible with the FENs that WinBoard sends or expects. ...

It would be helpful to give some examples for that. I have not been aware of Winboard FEN being able to support all those variants.

[hgm]

OK, here they are:

Code: Select all

rnbqckabnr/pppppppppp/10/10/10/10/PPPPPPPPPP/RNBQCKABNR w KQkq - 0 1
rnbqkbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKBNR[-] w KQkq - 0 1
lnsgkgsnl/1r5b1/ppppppppp/9/9/9/PPPPPPPPP/1B5R1/LNSGKGSNL[-] w 0 1
rheakaehr/9/1c5c1/p1p1p1p1p/9/9/P1P1P1P1P/1C5C1/9/RHEAKAEHR w 0 1
rnebmkfwbenr/pppppppppppp/12/12/12/12/PPPPPPPPPPPP/RNEBMKFWBENR w 0 1
rjnbkqbnjr/pppppppppp/10/10/10/10/PPPPPPPPPP/RJNBKQBNJR w KQkq - 0 1
rmbqkbmr/pppppppp/8/8/8/8/PPPPPPPP/RMBQKBMR w KQkq - 0 1
rnbqkknr/pppppppp/8/8/8/8/PPPPPPPP/RNBQKKNR w - - 0 1
aqnnrkbcrb/pppppppppp/10/10/10/10/PPPPPPPPPP/AQNNRKBCRB w IEie - 0 1
rnbkqbnr/pppppppp/8/8/8/8/PPPPPPPP/RNBKQBNR w 0 1
nrnbbkqr/pppppppp/8/8/8/8/PPPPPPPP/NRNBBKQR w HBhb - 0 1
rnbfqkfbnr/pppppppppp/10/10/10/10/PPPPPPPPPP/RNBFQKFBNR w KQkq - 0 1
vebqkanc/pppppppp/8/8/8/8/PPPPPPPP/VEBQKANC[NBRRnbrr] w KQkq - 0 1

From top to bottom you see FENs for the initial positions of:

Gothic Chess
Crazyhouse
Shogi
Xiangqi
Courier Chess
Janus Chess
Knightmate
Two Kings
CRC *
Shatranj
FRC *
Falcon Chess
Superchess *

The variants marked with (*) are shuffle variants, so you see one randomly picked realization for the opening setup only.