Check out Symmetric Chess, our featured variant for March, 2024.


[ Help | Earliest Comments | Latest Comments ]
[ List All Subjects of Discussion | Create New Subject of Discussion ]
[ List Earliest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]

Single Comment

Match between Fairy Max and ChessV[Subject Thread] [Add Response]
H. G. Muller wrote on Wed, Mar 4, 2020 08:57 AM UTC:

I think the real problem is that the ChessV.Engine.exe is defective; see my posting in the ChessV comments.

Note that Fairy-Max calls this game 'frog' only because the user configured it this way; Frog Chess is neither pre-cofigured in Fairy-Max, nor an XBoard standard variant. It would be just as easy to make Fairy-Max use the name that ChessV uses.

I am not sure it is 'unfortunate' that XBoard protocol only defines a very limited list of standard variants. The problem is that such a list, no matter how long you make it, will never be (or stay) complete anyway. To be future-proof, any name should be allowed. This means the names are not really part of the protocol anymore than the names of chess engines are; they are just data, and the protocol prescribes only what commands should be used to communicate them.

IMO the list of standard variants is already way too long; many variants in the list have no special properties, and only differ from each other (or from orthodox Chess) through board size, array, and piece moves. And the latter properties have basically become freely specifiable parameters for 'engine-defined variants'. So variants like Capablanca Chess, CRC, Great Shatranj really have become redundant, and are maintained only to deal with 'legacy engines'. Because the latter would not reply to the 'variant' command that selected them with a 'setup' command for specifying the array and board size.

The concept of engine-defined variants does raise the problem of name standardization, though. Which becomes more than a cosmetic problem when we want to play engines against each other. Perhaps GUIs should already provide a work-around for cases where engines disagree on the name of a variant they both play, like a per-engine 'alias list' of variant names. Which the GUI then should apply (in either direction) on both variant names received from the engine and sent to the engine.