New PGN Tag: VariantFamily

[hgm]

I introduced a new PGN tag, which XBoard/WinBoard will use in 'engine-defined variants'. Such variants can have arbitrary names, unknown to the GUI, but the engine then has to specify a 'parent variant, which will act as a 'template' for providing the rules. Some aspects of these rules (such as participating pieces, how these move, the initial position) can then be further modified by the engine.

To make it possible for a GUI to read back saved games in such a variant in absence of an engine for specifying the rules (i.e. in Game Viewer mode), the games are now saved with a VariantFamily tag specifying this parent variant. The original variant name will be in a preceding Variant tag. The initial position can of course be seen in the FEN tag, while participating pieces and their moves could be specified in a VariantMen tag. This means the PGN now contains all information that an engine would supply on selecting the engine-defined variant, thus making the presence of the engine unnecessary.

[phhnguyen]

Can you explain more:
- give examples of Variant/VariantFamily
- what extra information/benefits engines/chess GUIs can get from VariantFamily/Variant vs Variant only
- if we can simply use a hidden/internal map between Variant-VariantFamily in the code instead of using that external tag in PGN to get that info (in the view of a database designer, we should avoid as much as possible redundant information which can be inferred from existing ones)

[hgm]

For example, Fairy-Stockfish now does support 4 flavors of Janggi (Korean Chess), which it calls janggi, janggicasual, janggimodern and janggitraditional. These only differ in the rules for determining game termination / result. (E.g. in some a draw is just a draw, in others it can be considered a partial win/loss depending on who has the most material left.)

Of those 4, XBoard only implements 'janggi' as a standard variant. (I recently added that, because the Janggi rules are so special that no methods are currently available with which an engine could explain them to a GUI.) The other three names are unknown to XBoard, and are thus considered 'engine-defined variants'. When the user selects any of these from the menu, the engine will send a 'setup' command to the GUI to tell it to switch to standard variant janggi (the 'parent variant'). In addition its specifies participating pieces and initial setup (which here are all the same as in standard janggi). It would have the possibility to redefine piece moves through 'piece' commands, but that is not needed here. After that the GUI and engine are in agreement about the rules, and games can be played.

If such a game (say of janggicasual) is saved, the Variant tag in the PGN will be set to 'janggicasual'. It has to be, because if it had been set to 'janggi' (the parent variant) there would have been no way to recognize which flavor of Janggi had been played here. But if XBoard then tries to read it back, it would only know what 'janggicasual' means if an engine would tell it that through a 'setup' command when XBoard switches to the mentioned variant. Without an engine XBoard would have no clue at all what 'janggicasual' means, and what moves it should use for the various pieces.

So this is where the VariantFamily tag comes in: in the saved janggicasual game it would specify janggi as the VariantFamily. XBoard can then switch to 'janggi' on loading such a game without any engine telling it to do so. So this serves the goal of making a PGN contain all information necessary for the GUI to handle that game.

[Ferdy]

For example, Fairy-Stockfish now does support 4 flavors of Janggi (Korean Chess), which it calls janggi, janggicasual, janggimodern and janggitraditional. These only differ in the rules for determining game termination / result. (E.g. in some a draw is just a draw, in others it can be considered a partial win/loss depending on who has the most material left.)

Of those 4, XBoard only implements 'janggi' as a standard variant. (I recently added that, because the Janggi rules are so special that no methods are currently available with which an engine could explain them to a GUI.) The other three names are unknown to XBoard, and are thus considered 'engine-defined variants'. When the user selects any of these from the menu, the engine will send a 'setup' command to the GUI to tell it to switch to standard variant janggi (the 'parent variant'). In addition its specifies participating pieces and initial setup (which here are all the same as in standard janggi). It would have the possibility to redefine piece moves through 'piece' commands, but that is not needed here. After that the GUI and engine are in agreement about the rules, and games can be played.

If such a game (say of janggicasual) is saved, the Variant tag in the PGN will be set to 'janggicasual'. It has to be, because if it had been set to 'janggi' (the parent variant) there would have been no way to recognize which flavor of Janggi had been played here. But if XBoard then tries to read it back, it would only know what 'janggicasual' means if an engine would tell it that through a 'setup' command when XBoard switches to the mentioned variant. Without an engine XBoard would have no clue at all what 'janggicasual' means, and what moves it should use for the various pieces.

So this is where the VariantFamily tag comes in: in the saved janggicasual game it would specify janggi as the VariantFamily. XBoard can then switch to 'janggi' on loading such a game without any engine telling it to do so. So this serves the goal of making a PGN contain all information necessary for the GUI to handle that game.

Why not make the header like the following?

Code: Select all

[ParentVariant "janggi"]
[Variant "janggi_whatever"]

[hgm]

That is basically the same idea, with a different name for the tag. Of course the name is quite arbitrary from a technical point of view. It seemed to me that the meaning 'ParentVariant' would be less generally clear (i.e. to people not being familiar with the CECP specs) than 'VariantFamily', and that the latter would fit better with the 'VariantMen' which we already have.

[Ferdy]

That is basically the same idea, with a different name for the tag. Of course the name is quite arbitrary from a technical point of view. It seemed to me that the meaning 'ParentVariant' would be less generally clear (i.e. to people not being familiar with the CECP specs) than 'VariantFamily', and that the latter would fit better with the 'VariantMen' which we already have.

It is all right then. Updated the pgn-standard, adding section 9.10 for the variant tags under tag_variant branch. Once satisfied and done it will be merged to master. You can contribute if you like.

These are the changes on section 9.10.