XBoard and chess variants

[Evert]

Now that XBoard is able to recognise engine-defined variants (although the identification apparently doesn't always work), is it still useful to list variant "fairy" in the list of supported variants? It doesn't normally correspond to anything well-defined, and I actually just noticed I don't send it anymore. I guess I should include it for the benefit of being able to select an engine-defined variant in older versions of XBoard, but other than that, is it still useful?

[hgm]

Like you say, backward compatibility would be one important reason. There will always be old versions of engines that specify they can play fairy, or NxM+S_fairy, and people that want to use these. So it must remain selectable from the menu.

From the engine side a reason to keep older names for variants in the variants-feature list (like 5x5+5_shogi for mini-Shogi) is to be able to play them against engines that still call them that way, either because they don't support engine-defined variants yet, or that they call it different. Even if XBoard would understand 'minishogi', it doesn't mean the opponent will. For this reason I let Shokidoki announce both 'tori' and '7x7+6_shogi' in its variants feature. It might be good practice to do that for any engine-defined variant (and provide an engine option to resolve ambiguities), to make it easier to play engines against each other that define different names for the same variant.

The current version of Fairy-Max still uses fairy + the engine-defined option "Variant fairy selects" to implement the different flavors of Chess with Different Armies. (I removes Spartan as a coice there, however, as that is now even a standard XBoard variant.) It is true that I could use the same mechanism with an engine-defined variant 'cwda', though, and an option "Variant cwda selects".

I guess that many variants would not really been added as standard variants if we would have had the engine-defined-variants mechanism earlier. (E.g. Knightmate, Cylinder, Berolina, Superchess, Great Shatranj, ASEAN, Janus, Falcon, Elven Chess would probably not be sorely missed. Although Knightmate and Berolina still make essential use of hardcoded XBoard features for mate detection and e.p. capture.)

[Evert]

From the engine side a reason to keep older names for variants in the variants-feature list (like 5x5+5_shogi for mini-Shogi) is to be able to play them against engines that still call them that way, either because they don't support engine-defined variants yet, or that they call it different. Even if XBoard would understand 'minishogi', it doesn't mean the opponent will. For this reason I let Shokidoki announce both 'tori' and '7x7+6_shogi' in its variants feature. It might be good practice to do that for any engine-defined variant (and provide an engine option to resolve ambiguities), to make it easier to play engines against each other that define different names for the same variant.

Ah, good point about the different shogi variant names. I added those to my list of "aliases". These provide a list of alternative names for variants, which are announced at the end of the variants list. I currently have

Code: Select all

static struct name_alias_t {
   const char *name, *alias;
} aliases[] = {
   { "chess",        "normal" },
   { "chess",        "chess960" },
   { "chess",        "fischerandom" },
   { "chess",        "fischerrandom" },
   { "chess",        "nocastle" },
   { "chess",        "wildcastle" },
   { "capablanca",   "caparandom" },
   { "minishogi",    "minisho" },
   { "minishogi",    "5x5+5_shogi" },
   { "torishogi",    "tori" },
   { "torishogi",    "7x7+6_shogi" },
   { "shoshogi",     "sho" },
   { "shoshogi",     "9x9+0_shogi" },
};

So all "normal" 8x8 chess variants are mapped to "chess", which is Sjaak's internal name for that game. Seems to work well.

The current version of Fairy-Max still uses fairy + the engine-defined option "Variant fairy selects" to implement the different flavors of Chess with Different Armies. (I removes Spartan as a coice there, however, as that is now even a standard XBoard variant.) It is true that I could use the same mechanism with an engine-defined variant 'cwda', though, and an option "Variant cwda selects".

I guess that many variants would not really been added as standard variants if we would have had the engine-defined-variants mechanism earlier. (E.g. Knightmate, Cylinder, Berolina, Superchess, Great Shatranj, ASEAN, Janus, Falcon, Elven Chess would probably not be sorely missed. Although Knightmate and Berolina still make essential use of hardcoded XBoard features for mate detection and e.p. capture.)

Sjaak used to have a "Variant fairy selects" option as well. I guess I'll keep that and just seed it with the list of variants (but perhaps I should filter out the known ones).

[hgm]

Btw, the latest XBoard commits to hgm.nubati.net should also fix the too loose variant detection: it turns out that StringToVariant in XBoard also did just a strstr(string, standardName) to trigger even if the name occurs as a sub-string. This probably because it is used on the game-start messages of ICS, which can print a long sentence of which the name is just a part. For all non-ICS variants I now require an exact match.

I also provided a potental extra column in the New Variants dialog for engine-defined variants, so you can use up to 22 now.

[Evert]

Btw, the latest XBoard commits to hgm.nubati.net should also fix the too loose variant detection: it turns out that StringToVariant in XBoard also did just a strstr(string, standardName) to trigger even if the name occurs as a sub-string. This probably because it is used on the game-start messages of ICS, which can print a long sentence of which the name is just a part. For all non-ICS variants I now require an exact match.

I also provided a potental extra column in the New Variants dialog for engine-defined variants, so you can use up to 22 now.

Awesome, I'll upgrade to that.

Also, is there a way to tell XBoard to use that awesome lion image? It doesn't appear to be in the piece-to-char table...

[hgm]

Yes, there is. Just make the pieceToChar string longer.

XBoard 4.8 now has 44 piece types in stead of 22, so you can makepieceToChar strings of upto 88 characters. As usual, the last piece you mention is for King. Piece number 22 (when we start counting at 1) is now Lion in stead of King (which moved to 44).

The 'row length' is doubled in Chu, i.e. piece 23-44 are considered the promoted versions of 1-22, when you define them as '+'. This was done because the promoted pieces of regular Shogi that naturally mapped to 12-22 tend to occur in the Chu setup as unpromoted and promotable. The representations of piece 23-44 (if they exist) reflect Chu promotions. (e.g. the piece 22 places behind the Wazir/Gold symbol is a Rook, slightly simplified to indicate its non-promotability.)

Use of these pieces is not recommended, however, as most of them do not have an image defined for them in WinBoard. (The standard edition of WinBoard does not support Chu, as the Alien Edition already did.) The Lion is an exception, though. (As WinBoard does support Mighty-Lion Chess.)

[Evert]

Yes, there is. Just make the pieceToChar string longer.

XBoard 4.8 now has 44 piece types in stead of 22, so you can makepieceToChar strings of upto 88 characters. As usual, the last piece you mention is for King. Piece number 22 (when we start counting at 1) is now Lion in stead of King (which moved to 44).

Ah, that does indeed work! Cool.

Use of these pieces is not recommended, however, as most of them do not have an image defined for them in WinBoard. (The standard edition of WinBoard does not support Chu, as the Alien Edition already did.) The Lion is an exception, though. (As WinBoard does support Mighty-Lion Chess.)

I guess the Lion, and possibly the horizontal and vertical swords, are really the only ones that are really interesting for extra pieces. The panther and claw look cool, but I can do without them.

It would be cool if the engine could tell the GUI to use some particular image (something like "image char filename"). It would make it easier to customise the GUI for a particular variant. Although it would be cool, it's probably too fragile (can fail in too many ways), so just put that one on an "in my ideal world…" wishlist.

[Evert]

I actually have an idea that would make it possible to do engine matches even if the engines refer to a variant by different names: a configuration option that allows the user to define an alias.
The only downside is that the engine would need to be restarted to refresh the variant list.

[Evert]

For now I've just added a drop-box to Sjaak's engine options that allows the user to select any variant it knows to be played as "variant fairy". This seems to work well, at least for variants that specify a "parent" variant in their setup string. Not all do though (in particular, standard variants don't, but I could reconstruct it for them) and there seems to be an issue where XBoard rejects move options, despite "piece" strings being sent.

By the way, I think I've found another bug: the protocol spec says I can send "setup FEN", but that is rejected with "Engine did not send setup for non-standard variant". I need to at least include a pieceToChar string (which may be completely empty, apparently).

[hgm]

This sounds like an error in the specs. In an engine-defined variant you should at least specify a parent variant, or XBoard would stay in VariantUnknown, which then triggers the error message when it receives the 'pong' that tells it the 'variant' command has been processed.

I guess you can get away empty pieceToChar strings because XBoard's routine SetCharTable() aborts on strings shorter than 12 (or odd length).

XBoard would reject piece commands with legality testing on in variants that it knows the rules of. (Which is most standard variants, even on non-standard board size.) Only if it is obvious that it would have no hope testing legality by itself it will accept the piece commands even with legality testing on.