Proposal for Linux engine standard

[hgm]

But as I know the UCI doesn't support chess variants at all (except Chess960, but it has option to ask for and set to play), so no need to answer your last question.

(cough...)

The World's strongest Xiangqi engine, Cyclone, is UCI

The World's strongest Seirawan-Chess engine is UCI.

None of them tells this through the protocol, as in both cases it is the only variant they play. So they have no need for an option to seect the variant.

[gbtami]

But as I know the UCI doesn't support chess variants at all (except Chess960, but it has option to ask for and set to play), so no need to answer your last question.

(cough...)

The World's strongest Xiangqi engine, Cyclone, is UCI

The World's strongest Seirawan-Chess engine is UCI.

None of them tells this through the protocol, as in both cases it is the only variant they play. So they have no need for an option to seect the variant.

"UCI is also used by some Xiangqi engines, mainly commercial ones such as Cyclone or ggChess (Gaga). The detailed command use differs a bit from the UCI protocol used in Chess, and is known as the Cyclone dialect. "
Fom http://home.hccnet.nl/h.g.muller/XQwinboard.html

It seems to me this is not the original UCI, but something based on it, or extending it. Not the same thing. On the other hand, you can handle these engines in /usr/share/games/xiangqi/* , especially koz they can use UCI Cyclone, Qianhong or UCCI dialects too.

[hgm]

No, it is not an extension, and in fact more a subset. The only difference is that 'position start' is not understood, but any position-go command always has to start with a fen. (Perhaps because 'start' is supposed to be the initial position for Chess, not Xiangqi.) But unfortunately the Cyclone GUI had a bug, sending ' fen' in stead of 'position fen' for each move. Because the Cyclone GUI is very popular, people wanted their engines to be able to play on it, and thus for most Xiangqi engines sending 'position' is optional, and they don't hang if you omit it. That is the only difference.

The S-Chess engine is 100% compliant with standard UCI.

There obviously is a competition here to what info to put in the file, and what info to derive from the path name of the file. In principle you just use empty files, and put all information in the path name, as file and directory names can be arbitrary strings.

But I think using the pathname to encode information is bad practice, and should be avoided if there isn't a special reason why you would want to group the files for access reasons. Othrwise it would just complicate matters for the GUIs, which would have to do a recursive tree walk to find if there is anything you can use. Life would be much easier for them if they could limit the search to just all files in a single directory.

Especially grouping by variant sees a bad idea, because the variant names could be ill defined, and some GUIs might recognize variants that others would have to play as something else, with legality testing switched off. E.g. older XBoard versions did not support Spartan Chess as a separate variant, and had to use the catchall variant fairy without legality testing to let Fairy-Max play it. But newer versions do support it. So if engines that play only Spartan Chess would would then have to put their info file in a directory engines/spartan. But older XBoards would not know what spartan means, and to know that the engine in there is really an engine that uses WB protocol variant fairy to play it, so that it is good for them, would have no way to know that other than opening every info file of every directory of an unknown variant, to see what protocol they use, and if they can use one of their catchall variants to play it. That is very inconvenient.

So it would be most logical to make the primary subdivision by protocol. If an engine is QH, and a GUI supports only UCI, then that is pretty much it, as there is no way it could run the engine. There is no such thing as a 'catchall' protocol. (Of course there are adapters, which from the viewpoint of the GUI are also engines, so they could add their info files in the tree as well.)

Now the directory for a certain protocol, say engines/uci, could be further subdivided by variant. But, as I mentioned, variants are a bit fuzzy. Most GUIs that only support Chess would have no problem to support Losers and 3Checks as well, and perhaps even Suicide. Some variants are pretty compatible, they are not all as different as Chess and Xiangqi.

So I think there is a good case for putting all UCI engines in the engines/uci directory, and declare the variant as text in the info file, so that GUIs don't have to needlessly scan many directories of unspecified names.

[gbtami]

No, it is not an extension, and in fact more a subset. The only difference is that 'position start' is not understood, but any position-go command always has to start with a fen. (Perhaps because 'start' is supposed to be the initial position for Chess, not Xiangqi.) But unfortunately the Cyclone GUI had a bug, sending ' fen' in stead of 'position fen' for each move. Because the Cyclone GUI is very popular, people wanted their engines to be able to play on it, and thus for most Xiangqi engines sending 'position' is optional, and they don't hang if you omit it. That is the only difference.

The S-Chess engine is 100% compliant with standard UCI.

There obviously is a competition here to what info to put in the file, and what info to derive from the path name of the file. In principle you just use empty files, and put all information in the path name, as file and directory names can be arbitrary strings.

But I think using the pathname to encode information is bad practice, and should be avoided if there isn't a special reason why you would want to group the files for access reasons. Othrwise it would just complicate matters for the GUIs, which would have to do a recursive tree walk to find if there is anything you can use. Life would be much easier for them if they could limit the search to just all files in a single directory.

Especially grouping by variant sees a bad idea, because the variant names could be ill defined, and some GUIs might recognize variants that others would have to play as something else, with legality testing switched off. E.g. older XBoard versions did not support Spartan Chess as a separate variant, and had to use the catchall variant fairy without legality testing to let Fairy-Max play it. But newer versions do support it. So if engines that play only Spartan Chess would would then have to put their info file in a directory engines/spartan. But older XBoards would not know what spartan means, and to know that the engine in there is really an engine that uses WB protocol variant fairy to play it, so that it is good for them, would have no way to know that other than opening every info file of every directory of an unknown variant, to see what protocol they use, and if they can use one of their catchall variants to play it. That is very inconvenient.

So it would be most logical to make the primary subdivision by protocol. If an engine is QH, and a GUI supports only UCI, then that is pretty much it, as there is no way it could run the engine. There is no such thing as a 'catchall' protocol. (Of course there are adapters, which from the viewpoint of the GUI are also engines, so they could add their info files in the tree as well.)

Now the directory for a certain protocol, say engines/uci, could be further subdivided by variant. But, as I mentioned, variants are a bit fuzzy. Most GUIs that only support Chess would have no problem to support Losers and 3Checks as well, and perhaps even Suicide. Some variants are pretty compatible, they are not all as different as Chess and Xiangqi.

So I think there is a good case for putting all UCI engines in the engines/uci directory, and declare the variant as text in the info file, so that GUIs don't have to needlessly scan many directories of unspecified names.

Seems reasonable. The remaining question what is better? To put all variant the engine supports into separate files, or just use one file, with a string listing supported variants.

[hgm]

I guess it woud have to depend on the capabilities of the engine. If it can be switched through the protocol interface between the various variants, such as Fairy-Max, Pulsar, NebiyuChess, Sjeng (WB) or between Chess and Chess960 (UCI), I guess it would be most convenient if the info-file contained a comma-separated list of variant names.

OTOH, if it was an engine where the variant has to be specified through command-line options, (I think Dababba required this), or by setting a non-standard engine option through the protocol interface (by instructing the GUI with a GUI option to do so, like for Fairy-Max playing Cambodian Chess), they would need variant-dependent engine start command, or different GUI options on the engine line. Rather than designing some complex syntax to be able to have such variant-dependent engine commands or GUI options, it would be simpler to just supply a different file for each such variant the engine plays.

The systems could even be mixed. E.g. for Fairy-Max there could be one info-file containing

Game = chess
Variant = normal, gothic, seirawan, makruk, knightmate, super
Command = fairymax

And then several info-files dedicated eah to a single non-standard variant, like

Game = chess
Variant = ouk
Name = Fairy-Max 4.8 (Cambodian)
Command = fairymax
[GUI options]
xboard = -variant makruk -testLegality false -firstOptions "Play makruk with Cambodian rules=1"

and since the fairymax Debian package also contains a dedicated binary for playing xiangqi, it would also install an info file:

Game = chess
Variant = xiangqi
Command = maxqi

Like it is a different engine (which it is; it just came in the same package).

The question is if there should be conventions for naming the files. There should be something to prevent collisions, so having the engine or package name as part of the name of the info file seems logical. Perhaps we could prescribe 'extensions' to distinguish multiple info-files of the same (engine, protocol) combination, in the rare cases where multi-variant engines need those. I am not sure they would have to mean anything. E.g. the info-file for Ouk could be called fairymax.ouk, and that for MaxQi fairymax.xq.

[gbtami]

I guess it woud have to depend on the capabilities of the engine. If it can be switched through the protocol interface between the various variants, such as Fairy-Max, Pulsar, NebiyuChess, Sjeng (WB) or between Chess and Chess960 (UCI), I guess it would be most convenient if the info-file contained a comma-separated list of variant names.

OTOH, if it was an engine where the variant has to be specified through command-line options, (I think Dababba required this), or by setting a non-standard engine option through the protocol interface (by instructing the GUI with a GUI option to do so, like for Fairy-Max playing Cambodian Chess), they would need variant-dependent engine start command, or different GUI options on the engine line. Rather than designing some complex syntax to be able to have such variant-dependent engine commands or GUI options, it would be simpler to just supply a different file for each such variant the engine plays.

The systems could even be mixed. E.g. for Fairy-Max there could be one info-file containing

Game = chess
Variant = normal, gothic, seirawan, makruk, knightmate, super
Command = fairymax

And then several info-files dedicated eah to a single non-standard variant, like

Game = chess
Variant = ouk
Name = Fairy-Max 4.8 (Cambodian)
Command = fairymax
[GUI options]
xboard = -variant makruk -testLegality false -firstOptions "Play makruk with Cambodian rules=1"

and since the fairymax Debian package also contains a dedicated binary for playing xiangqi, it would also install an info file:

Game = chess
Variant = xiangqi
Command = maxqi

Like it is a different engine (which it is; it just came in the same package).

The question is if there should be conventions for naming the files. There should be something to prevent collisions, so having the engine or package name as part of the name of the info file seems logical. Perhaps we could prescribe 'extensions' to distinguish multiple info-files of the same (engine, protocol) combination, in the rare cases where multi-variant engines need those. I am not sure they would have to mean anything. E.g. the info-file for Ouk could be called fairymax.ouk, and that for MaxQi fairymax.xq.

I like this solution. (The info file names don't have to mean anything, of course.)

[hgm]

What perhaps is still missing, is that an engine that supports various protocols (like UCI and WB) should have a way to indicate which the preferred mode is, in case a GUI also supports both protocols. In any case such engines would have to install info files both in the engines/uci and engines/cecp folder. Perhaps this is a case where the name could be made to mean something. Like that if there is a preference, that info file should have the shortest name. So that, say, GNU Chess could install info-files engines/uci/gnuchess6 and engines/cecp/gnuchess6.xb, so that UCI would be the preferred mode to install it.

[Michel]

Why not just an option in gnuchess.xb:

preferred=uci

This would direct a gui who knows about uci to load gnuchess.uci....