UCI extensions for kibitzing

[Aaron Becker]

I think it would be nice for UCI engines to have an easy way to control kibitzing and other chatting behavior when playing online. To this end, I'd like to propose a few simple extensions. Just as "info string <str>" indicates a string to be displayed to the user, these commands provide a literal string which will be conveyed to opponents and/or observers.

Code: Select all

info kibbitz <str>: relay <str> to the opponent and all observers
info say <str>: relay <str> to the opponent
info whisper <str>: relay <str> to observers

I'd like input from the community into this issue. Are these commands a good idea? Should the commands be modified, added to, or combined? Any spec extension is tough because it has to be implemented by both gui authors and engine authors to be useful. To get things rolling, I'd like to implement support in polyglot that will translate these commands into tellics strings and provide de facto support for Winboard and other compatible guis.

[hgm]

I don't really want to get involved with UCI protocol, but this seems not a good idea:

Your protocol extensions won't work on GUIs that are not equiped to handle them anyway. They require programming from the GUI developer to make them work. But they might break operation with GUIs that do not recognize the new commands.

A much better alternative is to use an existing command, that is harmless on existing GUIs. In this case, you could use:

info string %ICS% kibitz MESSAGE

Old GUIs would react to this by displaying "%ICS% kibitz MESSAGE" to the user on the local machine. That would not be the intended action, but it woud certainly not break them. GUI developers could match any info string for starting with the word "%ICS%", which is unlikely to start any genuine info string in existing engines by accident. And if they have a match, simply send the rest of the line to the ICS, in stead of displaying it to the user.

This way you can avoid protocol extensions (which are always troublesome in view of compatibility issues), and make in a simple matter of GUI implemetaton. I think I can promise that it would be implemented in Polyglot, translating it to the applicabe WB protocol command (tellall, tellothers, tellics), so that UCI engines running under WinBoard could use it.

Of course having engines kibitz their PVs and evaluations is really something that should be _strongly_ discouraged. For the sake of uniformity this should be a GUI task. Having engines do it would only lead to every engine using its own format, unintellegible to the ICS and the opponent's GUI. So it would break the very desirable feature of having the depth/score information of _both_ engines in the PGN file, which you would have if you would let the GUI kibitz in the standard format.

Of course it is OK to use such a new GUI feature as discussed here to send info to the ICS that would not be automatically kibitzed by the GUI. E.g. like wishing your opponent a nice day, thanking him for the game, etc. But when you must kibitz thinking output, _PLEASE_ use the standard format.

[Aaron Becker]

Of course having engines kibitz their PVs and evaluations is really something that should be _strongly_ discouraged. For the sake of uniformity this should be a GUI task. Having engines do it would only lead to every engine using its own format, unintellegible to the ICS and the opponent's GUI. So it would break the very desirable feature of having the depth/score information of _both_ engines in the PGN file, which you would have if you would let the GUI kibitz in the standard format.

Your point about compatibility is reasonable. I wanted to avoid just using "info string" to do the job, since it's ugly and explicitly breaks the semantics of the command, but maybe it's worth it for compatibility. What is your view on kibitzing moves from an engine's own book? I think I remember that you proposed sending an info string with a pv that indicates that it's a book move, but I'm afraid that also breaks most UCI parsers.

[hgm]

I don't really know UCI, but isn't the info string supposed to be a free-format message? I thought the semantics was to tell the user something. Well, sometimes the user is at the other end of an ICS.

In fact, it would be nice if the entire chain

user <-> GUI <-> ICS <-> GUI <-> engine

would behave like it is just a single GUI:

user <-> GUI <-> engine

I.e. everything that would normally presented to the user in local mode would be packed into standardized kibitz messages and sent to the ICS, which would relay it to the other GUI, which would then unpack it, and react to it in exacty the same way as it would have when receiving it from a local engine.

[Aaron Becker]

Having thought about this a little more, how about the following form:

Code: Select all

info kibbitz string <str>: relay <str> to the opponent and all observers 
info say string <str>: relay <str> to the opponent 
info whisper string <str>: relay <str> to observers

I believe that the UCI spec explicitly requires that existing conforming parsers will parse each of these commands as a plain info string, due to this requirement:

* if the engine or the GUI receives an unknown command or token it should just ignore it and try to parse the rest of the string in this line.
Examples: "joho debug on\n" should switch the debug mode on given that joho is not defined, "debug joho on\n" will be undefined however.

In principle you can embed whatever info you want in a plain info string without modifying UCI whatsoever, but this leads to an informally specified, conceptually messy format that requires a separate parse of the resulting string to figure out what it means. I think that should be avoided if at all possible.

[hgm]

I am not so sure this is undesirable at all. What you propose is tantamount to mixing layers in a communication protocol. The task of UCI is to provide engine-GUI communication. It should make no difference to the engine if it is communicating with its opponent on the same GUI or that there is an ICS in between. The engine should simply do its thing and report about it, without having to worry where it eventually goes.

It is quite normal in the design of layered protocols that what is the data part of a packet in one layer would actually be a header of a packet from another layer.

[Aaron Becker]

No other UCI authors seem to care about this, so I suppose I'll abandon the idea of protocol extensions for now. I'll just do one-offs for anything I need in Daydreamer unless there's more interest in this idea in the future.