Winboard verus UCI - The Big debate

Home |Articles | Links | Guestbook| Chat | Bookmark|
Monitor page
for changes

   it's private   

by ChangeDetection
Note: The UCI protocol has being amended in April 2004  and July 2005 with the commands ucinewgame and ponder, so some of the comments here about pondering and difficulty of book learning no longer apply. But not many uci interfaces implement this yet.


Note: This article is basically a semi-serious look at the "Standards Wars" between Winboard and UCI protocols.Readers who are not sure what UCI/WInboard protocols are, should refer to my beginning article on Chess engine protocols.

A interesting standards war is brewing in the Computer Chess World. For a long time, Tim Mann's Xboard/Winboard protocol has reigned as the only free and open Chess Communication Protocol for Chess engines.From relatively humble beginnings when it was used only to communicate between GNUChess and Xboard in 94, it has grown today to support over 100 Winboard engines and is supported by almost all major commercial interfaces.Indeed it's position as the sole and undisputed Chess engine protocol of choice appears to be unchallenged.

All this changed in Jan 2002, when Chessbase the Powerhouse Computer Chess company, began to throw their support behind Rudolf Huber and Stefan Meyer-Kahlen's relatively newer open protocol that was dubbed the "Universal Chess Interface" or UCI for short.

Which protocol will finally prevail or whether they will coexist side by side is a tricky matter to predict. This article will attempt to make a educated guess.

Much as being said and written about network economics and how to win a standards wars. Writers acknowledge that the best technical standard doesn't necessarily win the war.The standard that eventually wins out is as much a matter of luck, as well as superior skill/quality

Even so debates about which protocol is "better" have so far raged in terms of technical merit. This article will be broken into 2 parts. The first will discuss the technical superiority if any of Winboard over UCI or vice versa. Given the fact that this author is a programming idiot, this discussion will be mostly wrong :)

The second part of the article will focus on other non technical factors that might impact on the success of each protocol,followed by a review/summary of the rise in UCI in the last 6 months.[Jan 2002 to June 2002].

Technical quality

Much has being said about the technical advantages of the UCI standards compared to Winboard or Vice Versa. Here is a quick summary.

UCI is superior to Winboard because:

Winboard is superior to UCI because

UCI superior to Winboard?

The first two points above (about the lack of multi-variant mode and richer search information) are hardly disputed by defenders of the Winboard protocol (besides adding that such features are being discussed).

However, some have pointed out, the third point of configuring engine options within the GUI is a GUI problem, not a protocol problem. I think this is only partially correct, while it is possible to make installing Winboard/Xboard engines easier then in Winboard (for example Arena,Chessmaster,Chess Assistant do that nicely compared to the command level style in Winboard), the main objection that the protocol does not give any provision for changing engine options within the GUI holds.

Regardless of how it is done, you can only change engine options by altering their respective engine text configuration files.This can be a pain since the file extension varies from engine to engine (Crafty.rc, Yace.ini,comet.ics e.g) and you will have to search for the documentation to see which features are supported and the different syntaxes on how to set them.

For example, to set tablebases in Crafty, you need the line tbpath= endgamepath but in Yace it's tbldir= endgame path .

UCI is superior in that it standardises some options like hash size,endgame tablepaths/hash and even allows the GUI to control opening books.

All the opening book handling is done by the GUI, but there is an option for the engine to use its own book[From the UCI technical specification]

Although the above quote seems to imply that using it's own book is merely a option, in practice most UCI Chess engines except for Shredder use there own books and don't necessarily need to rely on GUI books. One reason why this is so is most UCI engines support Winboard as well (most were Winboard engines first anyway see later) , and as the Winboard protocol doesn't have the provision for providing opening books to remain functional in Winboard.

The idea for the GUI to provide opening books was discussed before in the Winboard Chess engines mailing list, but as I recall, this idea wasn't very popular with some , who wanted the GUI to remain neutral and not take over the various functions of Chess engines as many GUIs such as Fritz (which provide GUI Books and when a endgame tablebase position is reached the GUI will take over regardless of whether the Chess engine has support or not) and Arena (which can resign or declare draws on the behalf of the engine much to the chargin of some chess engine authors) has done.

It was suggested though instead of implementing a full book control system in Winboard, a command would be set to allow one engine to feed moves to both engines using it's book, before allowing both engines to take over. Nothing came of this.

To users though, the ability to standard opening books can be useful, especially when one side (usually a commercial) has a much superior opening book and using the same opening book can help remove this effect on the results.

More importantly though, UCI also provides the option of adding various engine options that are settable within the GUI using the option name value. In this way , the programmer can allow users to set and change various options within the UCI. All the author of the Chess engine needs to do is to send the options and the type of display (whether in buttons/checkboxes/Spin Wheels /Strings etc) to the GUI and the GUI will display them nicely.

If you think this is just a "trick option" , take a look below.

Crafty as a UCI engine using WbtoUCI adaptor
By converting Crafty to UCI using Odd Malin's Wbtouci adaptor you can see and change all the options at a glance.

The above was achieved by using Crafty and Odd Malin's ingenious WbtoUCI adaptor, which allows one to simulate a UCI engine. As you can see, when used in UCI mode, customising Crafty within the GUI is a snap, since you can see all the various options available at a glance. True you still need to dig through the readme file to understand what they do, but this form of presentation, is easier for many users who are not comfortable with typing in commands.

The fourth point, which allows UCI engines to implement secondary time controls is also a point that cannot be disputed.Currently on the Winboard protocol, you cannot set time controls like say 40 moves in 2 hours followed by 20 moves in 1 hour and 20 minutes for the rest of the game. ( Some Winboard engines accept multiple level commands already, as you can see when using them in Arena, but this is technically not a required function in the protocol)

Similarly UCI specifies a crafty style time control setting of nodes searched which is currently not defined in Winboard.

However the proposal to extend the level command to allow this for Winboard engines has being discussed and all but added to the new protocol. Arena for example supports this informal standard.

The last point is with regards to the legacy of Xboard/Winboard. In Xboard/Winboard certain commands have being implemented solely to keep compatibility with GNUChess and to a lesser degree Crafty (or so some claim). However the implementation of the protover and feature system, helps mitigates this somewhat.

Winboard Superior to UCI

The first thing to note about UCI is that it is based on a completely different design philosophy compared to Winboard. It is basically a system where the GUI is king, and engines are not supposed to do anything without consulting the GUI.

* The engine will always be in forced mode which means it should never start calculating or pondering without receiving a "go" command first.
* The engine should never execute a move on its internal chess board without being asked to do so by the GUI, e.g. the engine should not execute the best move after a search.
* Before the engine is asked to search on a position, there will always be a position command to tell the engine about the current position.

From the UCI Technical specification

Whether this is superior to Winboard's looser system of control is not a matter I'm qualified to comment on.

However the last point is interesting.UCI actually sends the entire movelist each move in the game. This design feature is not only inelegant and inefficient (imagine playing chess each turn, where instead of remembering the moves from position to positions, but having to be reminded all the moves played since the last for ALL moves), it directly creates 2 problems that is universally acknowledged

Firstly, book learning is hard. By sending the entire move list each turn (aka "stateless system"), it's difficult for the Chess engine to figure out when a game ends or begins.

Secondly it's not possible to play UCI engines in console mode for testing, because without the GUI to keep track of the position, you need to enter the whole movelist each turn! This is not a problem with Xboard/Winboard since all you need to do is to send the new move from move to move.

The third disadvantage is that while UCI interface is more restricting and less flexible then the Winboard protocol. For example pondering is standardised and controlled by the GUI, so other forms of pondering if the author wants to try new ideas are not possible.(This is not just a theoretical point, old versions of Aristarch by Stefan Zipproth disables pondering in UCI but not Winboard mode, because it uses uses a way of pondering that is unique and impossible(for UCI)) This standardisation makes it easy for users to set uniform settings for all UCI engines, but makes it hard/impossible for Chess engine authors to try new ideas,

On the other hand, Xboard/Winboard is a more flexible protocol. As mentioned before, with the protover/feature commands, it allows Xboard/Winboard to be extended easily, and for authors to pick and choose which features of which protover they intend to implement. While progress has is slow, there are provisions for and discussions about extensions to the xboard/Winboard protocol being carrying out at the mailing list. No such facility exists yet in UCI.

The ability to innovate is one of the key factors deciding the success of a standard. While Xboard/Winboard currently appears to be the more flexible one, much depends on how the maintainers of Winboard (Tim Mann) and UCI (Stefan Meyer-Kahlen ) work to extend their protocols.

The last point regarding the lack of a Non-Windows alternative UCI GUI unfortunately does not relate to the technical quality of Xboard/Winboard. However it does point to a serious problem, for people who test only on Linux for example.

new [21-01-2003] Knights a Linux/KDE 3.x ICS interface not only supports Winboard protocol but also supports UCI now!Also see my interface listing for a more complete list of guis.

To Part 2


Aaron Tay