|
|
| Monitor page for changes |
by ChangeDetection |
|
|
|
||||||
|
|
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].
Much has being said about the technical advantages of the UCI standards compared to Winboard or Vice Versa. Here is a quick summary.
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.
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.
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 acknowledgedFirstly, 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.
[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
