What should I support, UCI or Winboard?

[michiguel]

I expected you to defend your protocol !

Why? It did not design most of it, and as a scientist I am usually very objective.

However, UCI has only one move format, while WB will use combinations of the following scenarios :

- move in SAN format
- move in coordinate format
- move preceded by "usermove"
- move not preceded by "usermove"
- move preceded by "..."
- move not preceded by "..."
- etc.

Well the "..." are of course an abomination. Actually, I dont think they are really part of WB protocol. They are merely documented tolerance of WinBoard for the non-compliancy of GNU Chess. I would strongly recommend no other GUI implements that, and I am severely tempted to remove it from WinBoard as well. I am strongly against catering to non-compliant engines. (But I am too busy adding things to be bothered by removing things...)

I suggest to remove them from the documentation, and put them in a historic appendix (and make it difficult to find ). You do not need to remove the code.
New programmers should be reading only what is WBII w/o the WBI clutter.

The cluttered documentation of the protocol is the worst aspect of it. Most people that are scared of the protocol and think than UCI is simple (from the engine perspective) is because they are overwhelmed by unnecessary stuff.

UCI is not simpler, it just have a simpler documentation.

Miguel

The 'usermove' is a very good feature, and in the Alien Edition it proved essential for letting engines that support a wide variety of games with different move formats reliably generate Illegal-move messages. Unfortunately it was not in the protocol from the beginning. I admit the cost of maintaining backward compatibility can sometimes be high. But that is nothing compared to abandoning it.

... and move formats are not the only issue with WB.

You probably know that better than I: I never implemented WB protocol from the GUI side. From browsing through existing WB code, I got the expression that most of the complexity comes from going the extra lightyear to cater to non-compliant engines. I don't really consider that WB protocol, and if I wre to write a GUI from scratch that supported WB protocol, I would certainly not do such things. (E.g. sending 'hard' before 'easy', using 'white' + 'a2a3' to avoid using 'black'.) Basically all the 'idiom' stuff mentioned in the specs is obnoxious, and I would abandon it without hesitation. The 'black' and 'white' commands are superfluous for engines that support 'setboard', and I would never send them to such engines. If there are egines that would not work because of that, it must mean that they implemented other commands in a way that violated the specs, and that would just be to bad for them. Out they go!

UCI is simple.

Yeah, micro-Max is simple too. But it plays very poorly...

[Christopher Conkie]

Hi,

I am planning to include engine support in my Chess apps.
I have never worked on UCI or Winboard protocols before and hence wanted your opinion on what protocol should I support, to begin with.
Which protocol will be easier to work with?

Note I am NOT planning to write my own engine but just provide an interface to existing popular engines.

Regards,
Asim

Arena is a supporter of the UCI protocol but we also support older, more archaic protocols.

For example......we have been waiting upon Winboard 3 for some time now.

A brief but simplified understanding may look like this......

UCI is simple to implement. Winboard, more difficult.
UCI is extensible, Winboard less so (until otherwise advised)
Winboard caters for older engines (UCI is relatively new)
Winboard has been customised for variant chess, UCI less so.
Winboard is more stringent, UCI less so.

I think the only people qualified to answer your question are those who have implemented both.

You might want to ask the Greko author for example.

He could tell you the pro's and con's of what he found.

Better still.....implement them both. In that way you will be "backward compatible".



Chris

[syzygy]

(E.g. sending 'hard' before 'easy', using 'white' + 'a2a3' to avoid using 'black'.)

Funny, just a moment ago I was wondering what the following lines were doing in my old engine, just before declaring a move illegal:

Code: Select all

#if defined(WILD5) || defined(THAI)
  if (from == 8 && to == 16) {
#ifdef WILD5
    MakeMove(0x3e2d);
#else
    MakeMove(0x1018);
#endif
    return;
  }
#endif

Now I understand

[Elorejano]

Please, implement both.
WB protocoll is more better, but UCI are implemented in ChessBase gui, seems that this are the important for much people here.

[Christopher Conkie]

Please, implement both.
WB protocoll is more better, but UCI are implemented in ChessBase gui, seems that this are the important for much people here.

Smart comment. We cannot be sure. Both do the same thing......in different ways and to different degrees.

[Evert]

I suggest to remove them from the documentation, and put them in a historic appendix (and make it difficult to find ). You do not need to remove the code.
New programmers should be reading only what is WBII w/o the WBI clutter.

The cluttered documentation of the protocol is the worst aspect of it. Most people that are scared of the protocol and think than UCI is simple (from the engine perspective) is because they are overwhelmed by unnecessary stuff.

UCI is not simpler, it just have a simpler documentation.

This.

I started with UCI because it's fairly obvious from the documentation what you need to do to get things working. Of course, the only decent GUI I could get my hands on was XBoard and after using polyglot for a while (which is really not very ideal when you're developing and debugging an engine) I decided to implement the XBoard protocol. Sjaak, of course, used XBoard from the beginning (being a variant engine).

[hgm]

... after using polyglot for a while (which is really not very ideal when you're developing and debugging an engine)

This advice probably comes a bit late for you, but I think it woul be much more convenient to use UCI2WB when developing an engine than Polyglot. In debug mode, UCI2WB sends all engine->adapter communication as engine debug output to the GUI, so it will appear in the xboard.debug file.

[hgm]

Arena is a supporter of the UCI protocol but we also support older, more archaic protocols.

For example......we have been waiting upon Winboard 3 for some time now.

You are waiting for archaic protocols that still have to be developed?

Why are you waiting? That doesn't seem a good way to make fast progress. Especially when you are waiting for things that are not scheduled to happen... If there are WB protocol features you need for proper Arena functioning, which are currently not implemented, you can propose them, and if thet are not very ridiculous, they will likely be added within the week...

That is actually the major advantage of WB protocol over UCI: it is a living protocol, that can be extended in any direction, to meet novel demands. UCI, OTOH, is static and unchangeable. It is basically a dead protocol, tailored to meet the needs of a single engine and a single GUI.

A brief but simplified understanding may look like this......

UCI is simple to implement. Winboard, more difficult.
UCI is extensible, Winboard less so (until otherwise advised)
Winboard caters for older engines (UCI is relatively new)
Winboard has been customised for variant chess, UCI less so.
Winboard is more stringent, UCI less so.

Not sure what you mean by the 'extensible' thing. I would say it is just the other thing around. The only attempt to extend UCI I am aware of is UCI3 by Rybka, and they did so far not manage to get that extension in the UCI protocol specs, so that no one supports it. The WB protocol specs, however, are updated all the time with new extensions. WB protocol is of course more flexible, in this respect, because it incorporates a formalized mechanism for extending the protocol without breaking backward compatibility, through the 'feature' handshaking at engine startup.

This is a pity, because extensions of UCI are sorely needed. There are so many things you cannot do in UCI that have been standard in WB protocol for decades.

I'm also not sure what you mean by 'stringent'. Can you give an example?

I think the only people qualified to answer your question are those who have implemented both.

You might want to ask the Greko author for example.

Remind me, what GUI did he implement?

He could tell you the pro's and con's of what he found.

Better still.....implement them both. In that way you will be "backward compatible".

Yeah, and do twice the work...

[Evert]

This advice probably comes a bit late for you, but I think it woul be much more convenient to use UCI2WB when developing an engine than Polyglot. In debug mode, UCI2WB sends all engine->adapter communication as engine debug output to the GUI, so it will appear in the xboard.debug file.

Probably.
Not sure if UCI2WB existed when I started; if it did it wasn't as well-advertised/documented as polyglot.
At this point it doesn't really matter to me anymore though, I'm not planning to switch back to UCI as a "main" protocol.

[kinderchocolate]

Well if Winboard protocol is really better than UCI, why wouldn't the top and new engines use it? Its not as common as UCI, there must be a reason. Can you explain?

Arena is a supporter of the UCI protocol but we also support older, more archaic protocols.

For example......we have been waiting upon Winboard 3 for some time now.

You are waiting for archaic protocols that still have to be developed?

Why are you waiting? That doesn't seem a good way to make fast progress. Especially when you are waiting for things that are not scheduled to happen... If there are WB protocol features you need for proper Arena functioning, which are currently not implemented, you can propose them, and if thet are not very ridiculous, they will likely be added within the week...

That is actually the major advantage of WB protocol over UCI: it is a living protocol, that can be extended in any direction, to meet novel demands. UCI, OTOH, is static and unchangeable. It is basically a dead protocol, tailored to meet the needs of a single engine and a single GUI.

A brief but simplified understanding may look like this......

UCI is simple to implement. Winboard, more difficult.
UCI is extensible, Winboard less so (until otherwise advised)
Winboard caters for older engines (UCI is relatively new)
Winboard has been customised for variant chess, UCI less so.
Winboard is more stringent, UCI less so.

Not sure what you mean by the 'extensible' thing. I would say it is just the other thing around. The only attempt to extend UCI I am aware of is UCI3 by Rybka, and they did so far not manage to get that extension in the UCI protocol specs, so that no one supports it. The WB protocol specs, however, are updated all the time with new extensions. WB protocol is of course more flexible, in this respect, because it incorporates a formalized mechanism for extending the protocol without breaking backward compatibility, through the 'feature' handshaking at engine startup.

This is a pity, because extensions of UCI are sorely needed. There are so many things you cannot do in UCI that have been standard in WB protocol for decades.

I'm also not sure what you mean by 'stringent'. Can you give an example?

I think the only people qualified to answer your question are those who have implemented both.

You might want to ask the Greko author for example.

Remind me, what GUI did he implement?

He could tell you the pro's and con's of what he found.

Better still.....implement them both. In that way you will be "backward compatible".

Yeah, and do twice the work...