What should I support, UCI or Winboard?

[hgm]

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?

You should ask that to the authors of these engines. What motivates others is of no interest to me, even if I were an esper that could read other peoples mind (which I cannot). Only facts are of interest, what people think is irrelevant...

[Evert]

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?

There is no relation between the choice of protocol and the strength of a chess engine. It is also not true that new engines only use UCI.

What is true is that some wide-spread and commercial GUI-interfaces use UCI. What is also true is that there are many engines that either start as a fork from an existing engine, or have their design based on or modelled after an existing engine (typically Fruit). The UCI documentation is easier to get into, which also makes it easier to start with it.
These things act as a bias for when deciding what protocol to support initially. Once you have a working program, there's little incentive to switch to a different protocol, so you stick with what you have.

[Don]

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

I hope this does not degrade to a protocol war.

I don't have an answer for you, but for a time I have seriously considered creating a new protocol, to address the weaknesses of both protocols. Now before you say, "we don't need yet another protocol" read on.

The new protocol would have built in support to interface with both UCI and WINBOARD. Although you could build GUI's and tools to interface directly with it, you would not be obligated to. So if nothing else it would make it easier for programs to support all three protocols.

The new protocol would be designed with the goal in mind of making it as easy as possible for the chess engine author as well as the tool designer. And based on our experience with protocols so far and what has been posted on this forum we would explicitly address all the warts we have encountered and any questions that have come up with a definite answer. For example, how do you do multiPV? There should not be multiple ways to do things that are ill-defined. Can you send a null move? If so, how? All of those things should have an answer.

The reason I have considered this at all is that I personally have a lot of my own criticisms of both protocols. Although I definitely prefer UCI (and I have worked with both) I see some strengths and weaknesses in both protocols.

The protocol would be implemented as a library for C/C++ and if used simply to provide both winboard and UCI support it would in effect be like an adapter build in to your chess program and it would essentially provide a reference implementation for those protocols sp I would try to make it as conforming as possible.

Anyway, I am not going to start anything like this anytime soon, but if any chess program authors are interested, please contact me privately. I don't pretend that I have thought everything through. For example the very biggest question for a new protocol would be one that is already hotly debated and this is how to define the role of the engine. Is it servant or master? Can a protocol be designed that allows for both without making GUI and/or protocol design really complicated?

[hgm]

I think that a versatile protocol should allow the engine to be servant as well as master. I don't see why one should exclude the other. The difference is really only in what the GUI does with the info an engine sends it. In servant mode, refusing a move as illegal is a capital crime, forfeiting the engine. In master mode, the GUI would side with the engine, and take back the move. To run in master mode, the engine can offer the service of sending a list of legal moves, on GUI request. In servant mode the engine should have no say in the matter, and the GUI would just not use the command to request the list.

Note that a list of legal moves is not logically needed in a GUI, even if it wants to leave the engine in total control. It is just the awkward design of the UCI 'searchmoves' that makes this necessary. With separate commands for excluding and including moves, that also understand the qualifier 'all', the same job can be done entirely without knowledge of the full move list.

In the WinBoard 'Alien Edition' we even have extended WB protocol with commands to allow the engine to highlight squares (by sending a 'color FEN' to the GUI), in response to 'lift' and 'hover' commands sent by the GUI to inform the engine when the user grabs a piece with the mouse, or drags it over a square where it can make a capture. The engine can also send 'click' commands in response to a 'lift', to implement one-click moving. You really should try the Nebiyu engine once, for playing Ultima, to see how well this works!

[Don]

I think that a versatile protocol should allow the engine to be servant as well as master. I don't see why one should exclude the other. The difference is really only in what the GUI does with the info an engine sends it. In servant mode, refusing a move as illegal is a capital crime, forfeiting the engine. In master mode, the GUI would side with the engine, and take back the move. To run in master mode, the engine can offer the service of sending a list of legal moves, on GUI request. In servant mode the engine should have no say in the matter, and the GUI would just not use the command to request the list.

Note that a list of legal moves is not logically needed in a GUI, even if it wants to leave the engine in total control. It is just the awkward design of the UCI 'searchmoves' that makes this necessary. With separate commands for excluding and including moves, that also understand the qualifier 'all', the same job can be done entirely without knowledge of the full move list.

I think this illustrates why no matter what you do, not everyone will be pleased. I am a strong believer that you should not duplicated functionality that can be derived from other functionality unless there is a pretty good reason. So for example "include" or "exclude" in my way of thinking is the same command. I would not wish to require the engine author be required to implement BOTH. I understand of course that not everyone shares my view and I'm ok with that.

I think you tend to see things from the point of view of the GUI designer, so you prefer things that make your life easier just as I prefer to make it as easy as possible for the engine author. But this is justified, because one GUI can serve an infinite number of programs. In other words the GUI designer will have to put extra time into it, but it's a positive tradeoff if it saves a million chess authors even a few minutes each. And it makes it much more likely that will be able to produce bug-free implementations which also benefits the GUI designer.

If I design my protocol it will be minimalistic and provide the lowest barrier of entry possible for an engine author. We have talked about this before and we don't agree, but I feel that "feature count" is not the most important issue, especially if it's not built on a solid foundation. But I do not dispute the fact that it IS important and I would define a minimal conforming subset of commands, then a more complete advisory set and the ability for the User Interface to gracefully deal with missing features (perhaps by being able to query for them.)

We grappled with these same issues in computer go several years ago, and there was a lot of resistance to the GTP protocol for go when it first came out to the point that some people were angry and said they would "never" move to it and that they didn't need 2 protocols. It was so superior to the previous (gmp) protocol that it quickly took hold and every program supports it now.

GTP also has it's warts but there are some good ideas that could be borrowed from it too.

In the WinBoard 'Alien Edition' we even have extended WB protocol with commands to allow the engine to highlight squares (by sending a 'color FEN' to the GUI), in response to 'lift' and 'hover' commands sent by the GUI to inform the engine when the user grabs a piece with the mouse, or drags it over a square where it can make a capture. The engine can also send 'click' commands in response to a 'lift', to implement one-click moving. You really should try the Nebiyu engine once, for playing Ultima, to see how well this works!

[hgm]

I think this illustrates why no matter what you do, not everyone will be pleased. I am a strong believer that you should not duplicated functionality that can be derived from other functionality unless there is a pretty good reason. So for example "include" or "exclude" in my way of thinking is the same command. I would not wish to require the engine author be required to implement BOTH.

Well, they are not the same functionality, but actually opposite functionality. I guess your thinking is affected by the notion that commands that undo each others effect are not needed, because of the idea of statelessness: there is one single command that resets everything at once, and thus makes the individual resets unnecessary. And then you simply set everything again that was reset as 'collateral damage', feeding the complete state to the engine again by 'unidirectional' commands.

But in practice the collateral damage can be very real, even huge. Resetting the state of the exclude map in UCI can only be done by terminating the seach, because they are both coupled to this same giant 'reset switch'. This could make you lose hours of analysis work, for no reason. It is a bit like having a text editor without backspace command. Because you can get back in the state with the last-typed character deleted by simply clearing the page, and retype all preceding characters. This operation is logically equivalent to pressing backspace, so backspace really 'duplicates functionality'.

Requiring the root move set to be sent at the beginning of a search is simply a very bad, counterproductive idea, which in many cases severely decrades performance. In most cases it would be perfectly possible to exclude moves, or re-include them, without disturbing the search in progress. This cannot be written off as a simple preference matter for stateless versus incremental protocols.

But even within the concept of statelessness the UCI 'searchmoves' command is badly designed. Because it requires the engine to receive exactly the opposite info from what the user typically supplies. As the default situation is that an engine searches all legal moves, he will start indicating a number of moves to be excluded from the search. While the engine needs to be sent the moves that should be included. This puts a totally unnecessary burdon on the GUI.

I think you tend to see things from the point of view of the GUI designer, so you prefer things that make your life easier just as I prefer to make it as easy as possible for the engine author.

You are aware that I wrote 5 engines, plus the protocol driver for 5 engines from other authors, (SMIRF, ChessV, GNU Shogi, Bonanza, TSIO) and only a small part of a single GUI?

But this is justified, because one GUI can serve an infinite number of programs. In other words the GUI designer will have to put extra time into it, but it's a positive tradeoff if it saves a million chess authors even a few minutes each. And it makes it much more likely that will be able to produce bug-free implementations which also benefits the GUI designer.

This logic seems severely flawed. A single engine can also run on a million different GUIs, so with this line of reasoning you could also 'prove' the exact opposite.

The real trade-off to consider is this one: should we require from everyone that programs an engine for a new game that he would write his own GUI with it from scratch (knowing that this multiplies the amount of work he needs to do by a factor 10 to 100), or would we allow him to connect his engine to an existing GUI, that without any modification then can run his engine 'out of the box'. Because it does not need to know details of the game rules to provide the user with a fully functional interface. The overwhelming majority of games is only supported by a single engine, occasionally by 2 or 3. To have 10 or more engines is a rare exception. You should know this better than anyone! How many C-Chess engines are there, for instance?

If I design my protocol it will be minimalistic and provide the lowest barrier of entry possible for an engine author.

Well, that seems to describe the actual situation w.r.t. WB protocol pretty well. Frequently new people report here that have written an engine using some custom interface. I advice them to implement the WB "new" & "go" command, (usually their engine already contains that functionality under another name), prefix the move they print with "move ", and 5 min later they are playing automated matches with other WB engines. This is no theory. It has happened many times in the past.

When they later want to have a more complete implementation of WB protocol, they simply grab my 'model WB protocol driver' from WinBoard forum, and they have a fully compliant WB engine. The most common problem that requires them to work on it is that they usually do not support the required time-control types, but think fixed depth. Otherwise it is really nearly a 'zero-effort' job.

[syzygy]

But this is justified, because one GUI can serve an infinite number of programs. In other words the GUI designer will have to put extra time into it, but it's a positive tradeoff if it saves a million chess authors even a few minutes each. And it makes it much more likely that will be able to produce bug-free implementations which also benefits the GUI designer.

This logic seems severely flawed. A single engine can also run on a million different GUIs, so with this line of reasoning you could also 'prove' the exact opposite.

Who cares if you can use the same argument to prove the opposite point? What Don writes is simply very very reasonable. I don't find it very productive to sweep away all such advice without actually considering it.

Btw, you might even agree that one or at most two guis suffice for most people, while many people would like to have as many engines as possible. So your reversed logic does not even apply.

The real trade-off to consider is this one: should we require from everyone that programs an engine for a new game that he would write his own GUI with it from scratch (knowing that this multiplies the amount of work he needs to do by a factor 10 to 100), or would we allow him to connect his engine to an existing GUI, that without any modification then can run his engine 'out of the box'.

This not the real trade-off. How many engines are there for variants? How many engines are there for chess?

It is great if xboard/winboard provides a solution for variant engines, but this should not come to the detriment of the original purpose of the gui. And it need not. Just extend the WB or UCI protocol with some special commands that only need to be implemented by variants and you're fine.

And please, at least take well-meant advice seriously and don't just sweep it away with references to people's imagination and/or tricks of logic.

[Don]

Just a couple of points highlighted below. I don't want to go any farther after this because you get upset quickly when anything other than glowing praise for winboard is discussed but of course you can feel free to respond. I wold like to mention that I don't have any problem with winboard and in fact it has some impressive features that I would probably even give glowing praise too except that you always push back so hard unless it's completely unqualified praise. I just like UCI better and I'm sorry that I cannot say that without upsetting you.

I think this illustrates why no matter what you do, not everyone will be pleased. I am a strong believer that you should not duplicated functionality that can be derived from other functionality unless there is a pretty good reason. So for example "include" or "exclude" in my way of thinking is the same command. I would not wish to require the engine author be required to implement BOTH.

Well, they are not the same functionality, but actually opposite functionality. I guess your thinking is affected by the notion that commands that undo each others effect are not needed, because of the idea of statelessness: there is one single command that resets everything at once, and thus makes the individual resets unnecessary. And then you simply set everything again that was reset as 'collateral damage', feeding the complete state to the engine again by 'unidirectional' commands.

But in practice the collateral damage can be very real, even huge. Resetting the state of the exclude map in UCI can only be done by terminating the seach, because they are both coupled to this same giant 'reset switch'. This could make you lose hours of analysis work, for no reason. It is a bit like having a text editor without backspace command. Because you can get back in the state with the last-typed character deleted by simply clearing the page, and retype all preceding characters. This operation is logically equivalent to pressing backspace, so backspace really 'duplicates functionality'.

I disagree completely. What the editor does internally is a hidden implementation detail than need not concern the person doing the editing. As long as the user can press backspace and get expected behavior that is what matters.

So when it comes to "exclude" and "include" the user interface SHOULD provide both. Basic software engineering principles tell us that we should not duplicate functionality, we provide the tools to do whatever we need to by construction and no more, at least within reason. I do violate that principle some in Komodo for reasons of performance, but as I will comment later that is not an issue here.

Requiring the root move set to be sent at the beginning of a search is simply a very bad, counterproductive idea, which in many cases severely decrades performance.

Again, I don't see why you even mention that. Why would any protocol need to require the root moves to be sent when they can generate them on their own?

But even if the root move list WAS sent it would not be a performance issue. I don't see why everyone obsesses over the amount of data being sent over a pipe in a chess program. It's just not a big deal. As I have mentioned before I can play several COMPLETE games per second even on 1 core with UCI sending complete moves lists, PV's going back and forth, current move numbers and all sorts of other crap. The issue is only in the GUI when you try to put all that information on the display using graphics calls and such and that has nothing to do with the protocol. With a graphical user interface I doubt I could play more than 1 game every 5 or 10 seconds even if both programs were playing instantly. That's where the overhead and drain is.

Just for fun I took a file that is 8.5 MB and piped it through a utility to count the number of characters in the file. A pipe is the same thing that happens when a chess program is connected to a user interface. It took about 0.2 of a second to send 8.5 MB and the data had to first be read from disk which is ridiculously expensive compared to just spitting out data already available to a chess program. And then it had to also be processed and counted and a program loaded up to do that! But 8.5 MB is orders of magnitude more data than a chess program will send even for the entire game. That would be the overhead of several games. This obsession with "too much data" has no place in this discussion.

In most cases it would be perfectly possible to exclude moves, or re-include them, without disturbing the search in progress. This cannot be written off as a simple preference matter for stateless versus incremental protocols.

But even within the concept of statelessness the UCI 'searchmoves' command is badly designed. Because it requires the engine to receive exactly the opposite info from what the user typically supplies. As the default situation is that an engine searches all legal moves, he will start indicating a number of moves to be excluded from the search. While the engine needs to be sent the moves that should be included. This puts a totally unnecessary burdon on the GUI.

There is no appreciable burden except perhaps in the programming of the GUI, but as stated I very strongly believe that is where the work should be focused. I don't believe the engine author should writing low level crufty code designed to accommodate things the GUI could be doing. Like mentioned above, the idea of sending a move list to the GUI, we both agree that is complete nonsense because the GUI can do that.

There was an issue that came up with GTP protocol for computer go which is eerily similar to the backspace editor example you mentioned. The protocol calls for an undo command. But it was possible for a GUI to simulate the same functionality without the undo command, simply by resetting the engine to the start position and forcing the moves. I was a reasonable decision to support and explicit undo command in my opinion but not strictly necessary. I don't believe we have to be completely unreasonable about things like that when there is an obvious shortcut, but imagine the same protocol needing to have a way to say, "take back 2 moves to get to the same side's turn" and then adding even more variations of the undo command. And the go engine author having to support every one of them. It would just be silly.

I think you tend to see things from the point of view of the GUI designer, so you prefer things that make your life easier just as I prefer to make it as easy as possible for the engine author.

You are aware that I wrote 5 engines, plus the protocol driver for 5 engines from other authors, (SMIRF, ChessV, GNU Shogi, Bonanza, TSIO) and only a small part of a single GUI?

Of course I am, but your heart and soul is in the GUI and that is where your primary focus is.

But this is justified, because one GUI can serve an infinite number of programs. In other words the GUI designer will have to put extra time into it, but it's a positive tradeoff if it saves a million chess authors even a few minutes each. And it makes it much more likely that will be able to produce bug-free implementations which also benefits the GUI designer.

This logic seems severely flawed. A single engine can also run on a million different GUIs, so with this line of reasoning you could also 'prove' the exact opposite.

Well that is just plain ridiculous. There are hundreds of engines that can run with xboard and UCI, there are probably 4 or 5 GUI's that comprise probably 99% of all GUI use. So to optimize man-hours of effort you optimize the protocol for the engine author, not the GUI author. I hope you are not saying that hundreds of engine authors should work extra hard to make it easy for those 4 or 5 GUI programmers.

The real trade-off to consider is this one: should we require from everyone that programs an engine for a new game that he would write his own GUI with it from scratch (knowing that this multiplies the amount of work he needs to do by a factor 10 to 100), or would we allow him to connect his engine to an existing GUI, that without any modification then can run his engine 'out of the box'. Because it does not need to know details of the game rules to provide the user with a fully functional interface. The overwhelming majority of games is only supported by a single engine, occasionally by 2 or 3. To have 10 or more engines is a rare exception. You should know this better than anyone! How many C-Chess engines are there, for instance?

I am only talking about western chess, not a million variants and the context of the discussion concerns the 2 major protocols in common use.

I agree things change when you are building a GUI to support any number of unknown new games that may come along. Then it's reasonable that the authors of these games and engines should have to work harder to build a product with a compatible interface, like you and I are doing together with camchess and schess.

If I design my protocol it will be minimalistic and provide the lowest barrier of entry possible for an engine author.

Well, that seems to describe the actual situation w.r.t. WB protocol pretty well. Frequently new people report here that have written an engine using some custom interface. I advice them to implement the WB "new" & "go" command, (usually their engine already contains that functionality under another name), prefix the move they print with "move ", and 5 min later they are playing automated matches with other WB engines. This is no theory. It has happened many times in the past.

When they later want to have a more complete implementation of WB protocol, they simply grab my 'model WB protocol driver' from WinBoard forum, and they have a fully compliant WB engine. The most common problem that requires them to work on it is that they usually do not support the required time-control types, but think fixed depth. Otherwise it is really nearly a 'zero-effort' job.

[hgm]

Who cares if you can use the same argument to prove the opposite point?

Everyone in his right mind. It is usually understood to imply the argument utterly and ultimately sucks. That is called 'logic'...

This not the real trade-off. How many engines are there for variants? How many engines are there for chess?

Well, I only wrote two serious Chess engines in recent times (counting micro-Max). Next to one dediated Shogi, two dedicated Xiangqi, and two multi-variant engines. And I converted another Shogi, Xiangqi and two multi-variant engines by others to WB protocol. That sounds like variants:8, Chess:2. When I count the multi-variant engines for 1, that is. When I count them for the number of variants they play, it would be more like 53-6. Does that answer your questions?

But now the more relevant question: How many GUIs are there for Chess? And how many for variants?

[syzygy]

Who cares if you can use the same argument to prove the opposite point?

Everyone in his right mind. It is usually understood to imply the argument utterly and ultimately sucks. That is called 'logic'...

Do you want to communicate, or are you just here to show that you're smarter than everyone else? Because really, I have better things to do than play word games with someone who does not want to listen.

But now the more relevant question: How many GUIs are there for Chess? And how many for variants?

Yes I know that I should give up on xboard, or rather, that a fork is in order.