X-FEN for FullChess Variants Extension Proposal

[smrf]

When an engine would like to become able to use such FENs, it has to learn for EACH variant:
a) which variant (name) is actually related to a selected FEN?
b) what would be the meaning of different piece letters?
c) what would be the meaning of unusual FEN components?
d) where an official sum up of all these could be found?

If a new variant wants to join the set of already supported, then there must be found an official place:
a) to introduce an official name for the variant
b) to document the matching FEN piece letters' use and their special gaits
c) to document special rules e.g. concerning castling right's promotion possibilities, methods of castling
d) to clear divergences where variants do overlap in common positions like e.g. at normal, nocastling or fischerandom, where positions could have different FEN encodings, but where board situations are 100% identic
e) to extend / rewrite existing GUIs and engines to become aware to the new variant

Anyway the FEN string alone would not be sufficient to doubtlessly communicate a game situation. It would be understandable only within a separatedly to be defined rule situation.

In contrast to those problems X-FEN aims to support ONE interesting variants' subset related to traditional chess called FullChess, avoiding all those problems by 100% compatibly extending the meaning of traditional FEN.

It enables to write FullChess engines supporting a big number of variants, even still unknown, if merely being element in that FullChess subset, WITHOUT a need to change FullChess GUIs, engines or to have agreements inside a world full of tough chessvariants' individualists.

Moreover such new FullChess engines still would be able to act e.g. as UCI engines within traditional UCI supporting Chess GUIs to play traditional Chess without any change because of their downwards compatibility.

[hgm]

Indeed, the FENs can only be understood in the context of the variant. This is unavidable due to the large number of variants, and the limited number of letters in the alphabet. WinBoard protocol always makes the engine aware of the variant, as the first action in any new game.

You are correct in stating that variant names are a problem. Currently, WinBoard cannot support any variant that is not known to it under some name. You can cheat it in collusion with the engine by switching off legality testing, and playing one variant as if it were another, as long as the variant has enough different piece types. I am still looking for a better way to do this. I added 'variant fairy' as a kind of generic variant were all 22 piece types that WinBoard supports are available, but often I want to play an unofficial variant with a weird piece type (for the purpose of evaluating that piece type), such as a piece that moves like a Knight and captures like a King. Then I just use a Nightrider or a Commoner for it in variant fairy, with legality testing switched off, and the engines agreeing that H or M (which normally mean Nightrider or Commoner in variant fairy) now move in this particular way.

One way would be to provide 'wildcard' pieces, of which WinBoard does not have any pre-conception on how they move, but can be told so through the FEN for the initial setup. So that the FEN indeed becomes a mechanism for programming the GUI, and perhaps even the engine. As long as the deviating game rules are limited to the presence of some pieces with non-standard gait, they could be described as a composite or subset of standard pieces, surrounded by parantheses. E.g. (mNcK) occurring in a FEN could indicate a single square occupied by the piece that moves like N and captures like Q, while (fBbR) would be the 'Y' piece that moves forward like a Bishop, but backwards as a Rook. This is the versatile Betza system, that even allows the description of hoppers like the Xiangqi Cannon. It would have to be adapted to indicate the color of the piece as well, though.

I have my doubts that the FEN would be the best way too program engine and GUI for the rules of the game. It is clear that some extra information will have to be sent, even in the limited set of variants you aim to support with X-FEN you need these modifiers in the castling field (e.g. for Janus castling) and available promotion choice. But why hide this extra information in the FEN? It is much easier to send extra information in a PGN tag, and you already proposed to do this for non-standard piece naming. It would be much more versatile if such a tag could not only rename existing pieces, but define new ones. So that in Janus you would not have to say J=A, you could just as easily say J=(BN). Then you would not have to 'waste' precious letters on pieces that are compounds. There are enough letters for indicating the 'atomic' steps, especially with the use of 'modifiers' (e.g. f=forward, c=capture, etc.) which could select subsets of standard (8-fold symmetric) gaits. So the standard meaning of A would be Alfil = (2,2) leaper, but it could not occur in any FEN outside the context of a PGN tag that first defined A to indeed indicate an Alfil, rather than an Archbishop (i.e. A=(A)).

What you currently attempt with X-FEN does not solve any problem, it just dodges it. You select a subset of variants that have nearly identical description anyway (because they use the same pieces), and try to add new elements to the FEN to make that subset slightly larger than it would otherwise be, by encompassing some games that no one plays anyway (e.g. Janus). That is not helpful, as the true problem remains, and in fact becomes more difficult to solve by you 'requisitioning' some new letters that could have helped solving the true problem by defining a narrow standard meaning for them.

[smrf]

Harm, I did not suggest to use PGN to define or to identify variants or their details. I merely suggested a way to customize different naming intentions to enable in contrast a standardized piece name usage within the X-FEN itself. Thus the nature of the intended [Variant "..."] tag is to be a kind of comment or a translation hint. Thus a therein used variant name e.g. does not even imply any need for prior standardizations.

As long as there would not be an accepted official registrar for variants and their detailed rules and namings, any approach to cover all variants ever must fail. Thus I have been shrinking my goals to focus a clear subset of densly Chess related variants. But I am convinced to cover with that a big fraction of really played variants, nevertheless indeed skipping a lot of exotic, more distant to traditional Chess.

I am sorry when noticing that you seem to feel sabotaged in your wider intentions by my X-FEN approach. That is not what I intend to do. Therefore I am trying by this proposal to cover the FullChess subset, but to do it with minimal bad payloads for other developments.

[hgm]

Well, for WinBoard the requirement of the FEN format supporting any conceivable variant can be reduced to supporting any variant WinBoard actually implements. But Xiangqi and Shogi are amongst those, and quite justly so, as they are the most played Chess variants. The FIDE 'Mad Queen game' is only an insignificant variant in comparison.

To WinBoard it would be acceptable to have a default identification of variants from the board size, having the implied variant imply the meaning of the piece naming. The variants of your 'FullChess' would be implied by a board size of 10x8 or 8x8, where the promotion choice would be further implied by the board width: 10-wide would imply A and C are allowed.

This would cause problems in Seirawan and Janus. The way you propose to solve these problems in X-FEN (expansion of the syntax) is not acceptable to WinBoard. Other piece letters would would be acceptable, as they fall within the universal FEN syntax. I don't see why you would prefer to add 's' modifiers to the castling field, rather than indicating a Rook that can 'Janus-castle' simply by another letter, or a Pawn that could not promote to a Chancellor on a 10-wide board by another letter than P. J could indicate Janus Pawns, S could indicate Seirawan Pawns on an 8-wide board, and T could indicate a Rook with non-standard castling rights on 10x8. Pieces that can make different moves are in principle different piece types, even if it is only a minor difference, so it would be logical to indicate them by different letters.

Of course Seirawan Chess would need the holdings field, like Crazyhouse, to indicate which pieces can still be gated in, and there would be the problem of indicating which pieces still have 'gating rights'. The latter could be done through the castling field, which could be interpreted in a more general way as a list of backrank pieces that have not moved yet, in so far this is relevant. So Seirawan FENs for the initial position would start with a castling field ABCDFGHabcdfgh, indicating castling rights for the a- and h-Rooks, and 'virginity' of all other pieces as well. A '-' in the field (which now could appear next to other letters in the castling field) would indicate the King has moved, and would thus deny castling rights to any mentioned Rook (which would still have to be listed for its gating rights). Upward compatibility with Shredder FEN would be provided by the rule that a King does not have to be mentioned if its virginity is implied by castling rights for a Rook.

This system solves all problems within the existing FEN syntax, and thus seems superior to your X-FEN proposal.

[smrf]

Castlings are Kings' moves. Thus it does not make sense to modify Rooks within FEN, especially because they normally will not be renamed after they have lost or applied their castling ability. But such traditionally is done within the castling tag of FEN. That is the reason to extend the properties of that tag as done in X-FEN.

If any detail rule of variants would lead to different new piece letters, 28 hardly would be sufficient to mirror all these. Thus it seems to be better to gather common characteristics as for the castling method to be applied and to ecode that detail independently from other compatibly by minimal means.

[hgm]

Sorry, but that is nonsense. Castlings are Rook moves just as much as they are King moves. That some protocols transmit castlings as the step of the King is simply a matter of convenience, as the step of the King would unambiguously identify it as a castling, while the Rook could make its step also as a normal move. But this fails in games where a King might move differently, or indeed starts in a different position, as in FRC. So there the King-captures-own-Rook notation is sometimes used, but the Rook-captures-own-King notation would work just as well. (And in fact better, as it would also work in variants where capturing your own pieces is legal.)

[hgm]

If any detail rule of variants would lead to different new piece letters, 28 hardly would be sufficient to mirror all these. Thus it seems to be better to gather common characteristics as for the castling method to be applied and to ecode that detail independently from other compatibly by minimal means.

For the extremely limited subset of variants that you call FullChess 26 letters would be more than enough. So far we have only:

PBNRACQK + S + J + T

That is only 11, and covers FIDE Chess, Capablanca, Gothic, Embassy, Carrera, Bird, Chess960, CRC, Janus, Seirawan. Which other variants had you planned to include in FullChess that would have to draw on the remaining 15 letters?

[smrf]

I have suggested 12 piece types already. 6x6 and 10x10 boards could be supported, too. A lot of variants could fit into that X-FEN scheme, even a lot of new.

Changing rook symbols to underline different castling methods would lead either to the need to rename those back to R after castling or to live with differently encoded FEN strings for the same board situation (created by another variant with different castling rules). The need for new letters and the multiencoding of board situations would even multiply, if you would create variants with possible castlings between piece pairs different from KR. And if you would like to encode different promoting abilities by renaming pawns, the set of left letters would be easily exhausted because of the myriad of thinkable valid promotion piece selections.

Thus encoding such rule details by creating representing new piece type names simply is creating a big confusion. This would start an extension into a very wrong direction.

Moreover: where is the authority to fix the names for such differently to be interpreted rooks or pawns? It seems to be hard enough to discuss and fix the name for those binary pieces combining traditional gaits - as you could see from this thread itself.

[hgm]

You are talking about hypothetically possible variants, and there are always so many of those that it would defeat any compact notation scheme short of a full program written in a recursive language to play them. This is understood, but of no practical relevance. Only variants that people actually play are relevant. Xiangqi, Shogi, Mad Queen, Crazyhouse, Bughouse, Gothic, Chess960, Seirawan fit that description. Janus, hardly. Design a 'standard' that cannot handle one of the first 8, and it will be stillborn. Design a 'standard' that is not upward compatible with the existing standard for the first 3, and it will stillborn.

In practice, the authority lies with the author of the software that people will want to use.

It remains my opinion that FENs are not the right vehicle to describe the game rules, even if these are just rules about minor details of the game. They are designed to describe game state. If there is a need to describe the rules, the best way would be to simply add a variant-name field to the FEN, e.g. prefix it with :name:. If a variant has no name, there is probably a good reason for that, and that same reason will also make it unnecessary to transmit FENs for it in the first place.

[smrf]

Well, ok, as there seems to be no chance for any convergence, I will continue staying fully compatible to the existing X-FEN ideas by introducing:

Code: Select all

		SYMB_BAU = 'P', // Pawn        Bauer     'B'
		SYMB_SPR = 'N', // Knight      Springer  'S'
		SYMB_LAE = 'B', // Bishop      Läufer    'L'
		SYMB_ERZ = 'A', // Archangel (Archbishop)
					       //         B+N Erzengel  'E'
		SYMB_TUR = 'R', // Rook        Turm      'T'
		SYMB_ZEN = 'C', // Centaur (Chancellor)
					       //         R+N Zentaur   'Z'
		SYMB_DAM = 'Q', // Queen       Dame      'D'
		SYMB_MIN = 'M', // Minotaur (Maharadja)
					       //         R+N Minotaurus'M'
		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'