Ugly UCI

[Evert]

Disclaimer: UCI vs CECP is ultimately a personal preference. Either protocol is functional.

What I think is quite elegant in the uci design is that with just one pair of simple commands ("position" and "go") an uci engine can already make moves in a game, accept take back, setup and play from a new position, swap sides, accept new time controls, reset and start a new game and analyse random positions.

But it is a fraud: they are not simple commands at all. They are multiple commands written on the same line. They are exactly the same commands as in CECP. "positon startpos" = "new", "position fen" = "setboard", "moves" = "force", "wtime/btime" = "time/otim".

I wanted to say that the single "position\ngo" command is much simpler, but I was waiting for the best opportunity.

I disagree: I prefer simple commands that do exactly one thing. In UCI the "go" command does a bunch of different things, controlled by options that are passed along with it. It's actually (marginally) harder to parse because of this.

uci.html is 26kB, xboard.html is 96kB. Both are equally useful documentation for their standard. Where does the size difference come from? Not only the resign and draw commands. It is also unneeded complexity: multiple ways to do the same thing. It is things like this: when I go back in xboard, I don't receive "force" and "setboard" with all the things you mention. I get "undo". Undo is a redundant command and yet it is mandatory to implement to get full functionality. Or if I retract a move while playing, I don't get 2 times "undo", I get ... "remove"! Such convoluted things are the reason that when you start with uci you have full functionality quicker and can focus on search and evaluation sooner. And your users can run under any GUI of their choosing ofcourse. One more such thing: you can send "feature setboard=1", but as long as the GUI is allowed to send "rejected setboard", you must still support "edit" and all its drama. But some GUIs need "setboard" and won't do "edit", so you must still have both. Argh. With uci the gui has no such weird freedoms and that makes life easier for everyone. If you intend to give the user the full experience, you must implement the whole standard, not just the subset that lets you play a single game.

I don't think anyone wants to argue that the CECP "specs" are well written; I started with UCI precisely because I found the specifications more readable.
A large part of the size of the CECP specs is due to bloat. Dropping all of the historical cruft (or moving it to an appendix) will do wonders to make the protocol more accessible. If and when you do that it turns out that there is really very little functional difference between the two protocols.

I disagree about "undo": the "force/setboard" combination isn't equivalent because it doesn't retain the game history. Sure, you can send the full move list afterwards, which is functionally the same as what UCI does. I'll take a simple "undo" instead, thanks. It's not like the ability to undo a move is something that needs to be added specially in the engine, it does that during the search anyway. "Remove" instead of 2x"undo" is a bit unintuitive, but is a logical consequence of the engine not being in "force" mode. It's not too much trouble to deal with it.

I will grant you "rejected setboard" as a theoretical problem, but in practice I don't think there are any GUIs that would send that, and I would personally consider a GUI that does as defective. None of my engines support the "edit" command and I have no plans to add support for it in the future either.

[Evert]

For my taste this is the most powerful and deep idea that the author of UCI got. It is amazing to me how this single assumption is able to get rid of tons of cruft and special cases: from software engeneering point of view this is pure brillancy.

For the amateurish programmer simple == what seems simple for human point of view

For the talented programmer simple == concise, self-contained, robust, consistent, general

Well, to each his own, but I find resending a bunch of data at every move rather inelegant, from a protocol design point of view. Sure, it may well simplify some other things, but it's a trade-off.

[mar]

In XBoard all scores of the form (+/-) 100000+N are recognized as mate(d) in N, and displayed as #N in the engine output.

This is interesting, alas it would also break the method (actually hack) I proposed, so it would have to also process a mate in 2, but that's only a cosmetic change.
I agree that a standard way is better, however there are engines that are no longer actively developed so they can't comply to a new standard.

What I like about what you propose is that it produces human readable output and existing engines can be modified to do so easily,
so if I ever release a new version of my engine I will most likely report mate scores this way in xboard mode.

Since I prefer to use xboard mode (because of its low verbosity) to analyze positions via console/terminal, this will also help me to identify mate scores easily.

[hgm]

Indeed, this was motivated by my dislike for subtraction, and the wish that even GUIs not supporting the standard would produce useful output from it, where 10000 could just be considered a funny spelling for 'mate in'.

Joker has actually be printing mate scores like that from the beginning, except that it used 10000+N instead of 100000+N. It seemed better to use a score above 32K cP for this, however. To my shame I must admit that none of my engines actually supports this standard. I really should put that on my to-do list. Polyglot uses it, however, which takes care of all UCI engines.

Your proposal involves what I call 'catering to non-compliancy', and my policy forcefully rejects that. Use of options to cure non-compliancy is acceptable, however. So I could add options -first/secondMateScore that users could install with the engine to translate the printed scores to the new standard.

[stegemma]

[...]Joker has actually be printing mate scores like that from the beginning, except that it used 10000+N instead of 100000+N[...]

In standard chess games maybe you can consider any value in the ranges 100/1000/10000/100000 +-/N as a "mate in N", with a little change in the graphical interface, so that you can handle the most of the engines. Of course that's not true for any engine.

I don't like UCI protocol but even WinBoard is not perfect. Writing my interface, I've found that it would be useful to have some command that the interface itself can send to engine, to get its board state. This would eliminates the needing of handling move validation for any kind of chess variant, in the interface itself. In my interface, I use my satana engine to validate moves from the two players. Of course I call directly my internal function, to test for legality. If the winboard/uci standard would have this simple command, I could use any external engine to test for legality:

GETFEN -> gets the actual FEN string
VALIDATE move -> returns TRUE/FALSE if the move is legal

In the interface, when engine A sends back its move, I would simply have to send that move to my external reference engine:

---> VALIDATE move
<--- TRUE
---> move
---> GETFEN
<--- "fen string"

Of course it can be simplified:

---> VALIDATE move
<--- FALSE or "fen string"

Why this? Because this way the interface simply send VALIDATE move to reference external engine, sending the move received from player A. if the interface gets back a FEN string, this means that the move is legal. The interface can use the FEN to update the graphical chessboard and then sends the move to engine B. The interface programmer should only choose a reference engine to play any kind of chess (and non chess...) variant.

Of course this is true for winboard protocol but still for UCI you just have to send a variation to the engine:

---> VALIDATE startpos moves_list

It would be enough to have a single reliable engine that play the variant that we like, to handle that variant in graphical interface. if we don't have one... we could use one of the two players.

[bob]

but I dont like UCI. In each move, the GUI send something like:

position startpos moves e2e4 e7e6 g1f3 d7d5 e4d5 e6d5 d2d4 b8c6 c2c4 f8b4 b1c3

For my undestanding, this is very ugly.

For my taste this is the most powerful and deep idea that the author of UCI got. It is amazing to me how this single assumption is able to get rid of tons of cruft and special cases: from software engeneering point of view this is pure brillancy.

For the amateurish programmer simple == what seems simple for human point of view

For the talented programmer simple == concise, self-contained, robust, consistent, general

You and I have COMPLETELY different ideas about simplicity. Chess is NOT stateless. Yet UCI pretends it is and introduces the kludge of sending the entire set of moves. That's NOT "brilliant".

[mcostalba]

You and I have COMPLETELY different ideas about simplicity. Chess is NOT stateless. Yet UCI pretends it is and introduces the kludge of sending the entire set of moves. That's NOT "brilliant".

You don't have to focus in the protocol per-se but in how this affects the code needed to parse/handle it.

The protocol is brilliant (and you can clearly realize it was designed by a very good programmer) because allows the code needed to handle it to be:

- Straightforward

- Simple (meaning with the minimal number of 'if' branches and logic)

- General (meaning the same algorithm can handle all the different cases in an uniform fashion).

The aim of the UCI protocol is to make the code simple, that's why I think it was made for programmers by a (great) programmer.

[Steve Maughan]

You and I have COMPLETELY different ideas about simplicity. Chess is NOT stateless. Yet UCI pretends it is and introduces the kludge of sending the entire set of moves. That's NOT "brilliant".

You don't have to focus in the protocol per-se but in how this affects the code needed to parse/handle it.

The protocol is brilliant (and you can clearly realize it was designed by a very good programmer) because allows the code needed to handle it to be:

- Straightforward

- Simple (meaning with the minimal number of 'if' branches and logic)

- General (meaning the same algorithm can handle all the different cases in an uniform fashion).

The aim of the UCI protocol is to make the code simple, that's why I think it was made for programmers by a (great) programmer.

I agree 100%. I'm actually surprised so many are voicing concerns about UCI in this thread. I know Bob and H.G. are not fans, but I thought the debate was basically over. I thought winboard, as a protocol, was dead. Are there any new engines implementing winboard?

If you take a 35,000 ft perspective - all the top engines use UCI as their main (only?) protocol. So it can't be all that bad.

- Steve

[hgm]

I don't like UCI protocol but even WinBoard is not perfect. Writing my interface, I've found that it would be useful to have some command that the interface itself can send to engine, to get its board state. This would eliminates the needing of handling move validation for any kind of chess variant, in the interface itself.

I am not sure I understand that; move validation seems to be something completely different and independent from getting the board state.

Note that WB protocol already provides move validation by the engine: engines can reject the input move with an "Illegal move" response, and if they don't you know the move was legal. (You can use 'ping' to make sure that they are not going to complain later because they were slow.)

Furthermore, WB protocol allows you to get all legal moves from the engine: just send the engine 'lift SQR' and it will respond with a color-FEN indicating all possible squares the piece on SQR could move to. A GUI could do that for all pieces to collect the complete list of legal moves. Although usually it would only need that info for the piece the user 'picks up'.

As to getting a board update after a move, this has also been taken care of, but only in 'variant alien'. The engine then will reply to any move with a "setup FEN" command to indicate the board state after the move. This is useful for moves that have side effects, such as in the weird capture modes of Ultima. For regular variants, where moves are just displacement of a single piece between the mentioned squares, replacing a previous occupant, this info is of no interest, as the GUI can calculate it by itself without any rule knowledge. Decoding a FEN received from the engine is far more work than clearing the from-square of a move, and putting the piece that used to be there on the to-square...

Usually none of this is needed, though, because the GUI can know in any variant the general rules by which each of the pieces moves, because the engine told it so, through "piece" commands. This proved the most practical and satisfactory method for doing things. All the methods requiring on-demand enginne-GUI communication cause perceptible delays, as due to process scheduling response is never instantaneous. Furthermore it would be extremely cumbersome to convert PVs to SAN, or parse SAN PVs to piece moves if every move in it required an exchange between GUI and engine. Letting the GUI know for once and for all how each piece moves at the beginning of the game doesn't suffer from that.

[Evert]

I agree 100%. I'm actually surprised so many are voicing concerns about UCI in this thread. I know Bob and H.G. are not fans, but I thought the debate was basically over. I thought winboard, as a protocol, was dead. Are there any new engines implementing winboard?

I never understand why people seem to think it's some sort of popularity contest. There are two protocols that do more or less the same thing; you pick the one that suits you best, for whatever reason. I really don't get why (some) UCI fans feel the need to put down CECP or people who prefer that as a protocol.
As for new engines that support CECP, there's probably some. Variant engines certainly, but there's only a handful of those. Either way, the communication protocol is by far the least interesting aspect of a chess program.

If you take a 35,000 ft perspective - all the top engines use UCI as their main (only?) protocol. So it can't be all that bad.

I find this type of comment equally strange. The strength of a program does not depend on the communication protocol it uses.
The most popular commercial chess GUIs use UCI as their native protocol, which by itself is sufficient reason for the top engines to implement UCI.

UCI and CECP are both perfectly serviceable and mostly interchangeable. UCI has some limitations that CECP doesn't have, if you find those important you can pick CECP. CECP has some peculiar quirks that UCI doesn't, if those irk you you pick UCI.

People say that there is a philosophical difference between the two: if you think the GUI is in control of everything and the chess engine is just a dumb piece of software that does what it's told, then go for UCI. If you think the chess program is in control and it's the GUI's job to communicate with the user on the program's behalf, then go for CECP. Perhaps there's something to that.