UCI protocol for chess variants

[hgm]

Would be great if an engine knows what gui it is run to too.
Something like after receiving the uciok from engine, the gui will
send,

Code: Select all

id guiname ZZZ
id guiversion YYY

If the engine does not understand (for example) the commands the gui are sending, it can send an info string message to the gui and then quit by itself. In this case gui and engine hangs are avoided. With this possibility if the gui does not send ucinewgame command at appropriate time, and if that command is critical for the engine to function properly, it is better to design an engine that will quit than to wait for undefined behaviour to happen. The engine author will take note of the guiname and guiversion, so that future engine versions can react accordingly.

This has been proposed for XBoard even before I was involved with it, and it was decided that it is a bad idea, for several reasons.

One is that it encourages forking of the protocol. GUI authors will feel themselves justified to keep non-compliant implementations, defending them by "but the engine should have known that in GUI XXX we do things this way", forcing engine authors to implement GUI recognition, and adapt the behavior of their engine to whatever GUI they happen to be running under.

I also thinks it sends the wrong signal. If an engine cannot handle absence of 'ucinewgame', the author had better spend his time making sure it can, rather than equipping the engine with a list of GUIs on which it can and cannot run, and printing an excuse for why it cannot. It is like 'solving' the problem that trains don't run in time or at all by starting an automated SMS service that informs people that "today there will be no trains". They will still not be able to get to work...

It is basically a method to make it easier for problems and bugs to be conserved and coexists, rather than to be solved and repaired.

[Matthias Gemuh]

Yes, but this assumes there actually is anything to select. Multi-variant engines are quite rare. A GUI that would support multiple variants obviously would need some method for the user to switch it to the right mode. A system were you simply assume that the engine will play that same variant is still workable. If people want to set the GUI for Suicide, they'd better load a Suicide engine, or they would be asking for trouble. It would be a nice gimmick if there was some protection against using a wrong engine, but it is not really essential. The only real problem would occur in the case of multi-variant engine. But that is again a step up from simple variant engines.

It would be interesting to know how Matthias solved this for his 10x8 engines in ChessGUI.

He lets the user define what each engine is capable of (i.e. UCI1, UCI2, WB1, WB2, Chess960, Capablanca, Gothic, etc) during engine installation.
When user is setting up tournament, GUI hides all unqualified engines.
If you choose say Gothic or Chess960 or ... at tournament setup, only suitable engines show up to choose from.

[hgm]

All your engines play only a single variant?

I could imagine the same engine can both play Capablanca and Gothic, and perhaps Bird. Or do you consider that all 'Capablanca' and just let the GUI decide about the initial position, and feed that to the engine?

Does "position startpos" mean anything to your 10x8 engines, or would you always have to use "position fen" in 10x8 Chess?

[Matthias Gemuh]

All your engines play only a single variant?

no

I could imagine the same engine can both play Capablanca and Gothic, and perhaps Bird. variant = CapaRandom
Or do you consider that all 'Capablanca' and just let the GUI decide about the initial position, and feed that to the engine?

Does "position startpos" mean anything to your 10x8 engines, or would you always have to use "position fen" in 10x8 Chess?
I can't remember.

I use "CapaRandom" not really as variant name, only as engine property.

[gcramer]

I've implemented the chess variants Three-Check and King-of-the-Hill (should be named King-on-the-Hill?) in stockfish, this modified version is part of the Scidb distribution (a chess database application).

1. I strongly suggest not to handle Chess960 as a chess variant, it's a super-set of chess positions instead, and standard chess is embedded naturally as position 518. If you handle Chess960 as a chess variant you have a serious restriction, what's about Crazyhouse/Bughouse games starting with a Chess960 position? And Chess960 positions are very welcome in Crazyhouse/Bughouse, because the choice of openings is quite restricted here compared to standard chess, Chess960 offers a much larger choice. In Scidb's stockfish version UCI_Chess960 is still living, because in Scidb this is not a chess variant (for me it's obvious that Chess960 cannot be a chess variant), it is a super-set of positions. Note that in fact this option UCI_Chess960 is a bit superfluous, because it can be deduced from the FEN whether it's a Chess960 position or not. But of course this widely supported option shouldn't be cancelled. BTW: I think that the preferred name is "Chess960", not "Fischer Chess" (Fischer did not define the castling rules, and FIDE is naming it "Chess960", also Wikipedia favours "Chess960").

2. In newer Scidb version the modified stockfish engine supports UCI_Variant with the possible values "Three-Check" and "King-of-the-Hill". In older Scidb version I've implemented the option UCI_VariantThreeCheck, but I've cancelled this idea in favour of the more flexible UCI_Variant option.

3.

Piece drops are encoded as <token>*<square>, where <token> is the upper
case piece letter and <square> is the drop square.

Does this mean that a piece drop will be written as "N*f6"? I suggest the common notation "N@f6", why another notation style?

[Evert]

He lets the user define what each engine is capable of (i.e. UCI1, UCI2, WB1, WB2, Chess960, Capablanca, Gothic, etc) during engine installation.
When user is setting up tournament, GUI hides all unqualified engines.
If you choose say Gothic or Chess960 or ... at tournament setup, only suitable engines show up to choose from.

Ok, so say I wanted to set up Sjaak as an UCI engine for Capablanca chess.

Sjaak is a multi-variant engine, meaning it needs to be told that it has to play Capablanca. How is it told to do this? Do you need to set the engine options before you begin the tournament?

[Evert]

1. I strongly suggest not to handle Chess960 as a chess variant,

I agree. In fact, variant names "normal", "fischerandom", "ficherrandom", "chess960", "wildcastle" and "nocastle" are all just aliases for what Sjaak calls "chess".
The reason I have it listed as a variant is because XBoard has "fischerandom" as a variant.

BTW: I think that the preferred name is "Chess960", not "Fischer Chess" (Fischer did not define the castling rules, and FIDE is naming it "Chess960", also Wikipedia favours "Chess960").

Many sources do, some don't. I list both so it's clear (and XBoad uses "Fischer").

2. In newer Scidb version the modified stockfish engine supports UCI_Variant with the possible values "Three-Check" and "King-of-the-Hill". In older Scidb version I've implemented the option UCI_VariantThreeCheck, but I've cancelled this idea in favour of the more flexible UCI_Variant option.

Cool, I'll just accept that as a de-facto standard.

3.

Piece drops are encoded as <token>*<square>, where <token> is the upper
case piece letter and <square> is the drop square.

Does this mean that a piece drop will be written as "N*f6"? I suggest the common notation "N@f6", why another notation style?

I agree, but unfortunately Shogi (from USI) already uses "N*f6" notation, and it seemed a bad idea to offer up an alternative for something that already exists.
But Sjaak understands both.

[Evert]

Would be great if an engine knows what gui it is run to too.
Something like after receiving the uciok from engine, the gui will
send,

Code: Select all

id guiname ZZZ
id guiversion YYY

I disagree - it shouldn't matter to the engine what GUI it runs on, as long as the GUI (and the engine) follow the protocol correctly.

With this possibility if the gui does not send ucinewgame command at appropriate time, and if that command is critical for the engine to function properly,

But the UCI spec says "ucinewgame" is optional, so if the engine requires it, it's buggy, isn't it?

[Matthias Gemuh]

He lets the user define what each engine is capable of (i.e. UCI1, UCI2, WB1, WB2, Chess960, Capablanca, Gothic, etc) during engine installation.
When user is setting up tournament, GUI hides all unqualified engines.
If you choose say Gothic or Chess960 or ... at tournament setup, only suitable engines show up to choose from.

Ok, so say I wanted to set up Sjaak as an UCI engine for Capablanca chess.

Sjaak is a multi-variant engine, meaning it needs to be told that it has to play Capablanca. How is it told to do this? Do you need to set the engine options before you begin the tournament?

You tell the GUI (by enabling options in GUI) once at engine installation everything the engine is able to do.
The engine's UCI options may be set before each tournament, if necessary.

[Evert]

You tell the GUI (by enabling options in GUI) once at engine installation everything the engine is able to do.
The engine's UCI options may be set before each tournament, if necessary.

Does it matter whether I present my options as a combo-box, or should I send the variants as a series of checkboxes?

I can of course do both for maximum compatibility.