Chess Programming Wiki
Chess Programming Wiki

UCI

Home * Protocols * UCI

UCI, (Universal Chess Interface)

an open communication protocol for chess engines to play games automatically, that is to communicate with other programs including Graphical User Interfaces. UCI was designed and developed by Rudolf Huber and Stefan Meyer-Kahlen [1], and released in November 2000 [2] . It has, by-in-large, replaced the older Chess Engine Communication Protocol ( WinBoard/ XBoard).

Critique

While the UCI design makes it simple for engine programmers to integrate a “stateless” chess engine, it was also disputed by various chess programmers, since it subsumes engine control parameters and delegates possibly game decisive stuff to the GUI.

Contra

  • GUIs may send very long commands (for chess positions) to chess engines
  • It is hard for chess engines to process input/output without an extra thread for that duty
  • Missing some useful commands/info: inform chess engines the results, no information about after movestogo GUIs will reset clock or not

Excerpt concerning UCI from a Robert Hyatt interview by Frank Quisinsky in 2002 [3] :

I simply don't like UCI. It subsumes **all** engine control parameters. It tells the engine when to [ponder](Pondering "Pondering"), when to [search](Search "Search"), when to stop, etc. That is contrary to my design and I have no interest in hacking [Crafty](Crafty "Crafty") to support something that is so different from the [WinBoard/XBoard](Chess_Engine_Communication_Protocol "Chess Engine Communication Protocol") protocol that has been around for a **long** time and which works **perfectly**.
It removes several critical engine-decisions that are best made by the engine, not the GUI.

Harm Geert Muller wrote on a Talkchess thread [4]

IMO statelessness w.r.t. the game state (including clocks) in UCI was a very bad idea. It is not only that it makes the communication unnecessarily verbose, but w.r.t. clocks there is a real problem: in classical TC the timing info accompanying the 'go' command does not specify how much time will be added after the 'movestogo' have been played. With movestogo=1 and wtime/btime=59000 you could be in a 40moves/hour game, at the brink of receiving another hour for the next 40 moves, in which case it would be wise to completely spend the remaining 59 sec on the upcoming move, as this is already below average. But you could also be in a 40moves/min game, where you got out of book after 39 moves, and receive only 1 new minute for the next 40. Wasting the 59 sec on a single move now effectively reduces your time for the second session by a factor 2, which would be very sub-optimal. The time management in this case should act like you have 1:59 for 41 moves (but be aware of a 'cold-turkey deadline' for the upcoming move). There is no way a UCI engine could know this.

Pro

  • Statelessness. That reduces unsynchronised problems between chess GUIs and engines
  • Chess systems (chess GUIs and chess engines) may work more stably
  • Remove the need of having extra configuration/init files for engines
  • Easier for chess engine developers to support: easy to parse, create commands, almost no ambiguous, straight/simple code since it is almost not required automatic algorithms
  • Easier for debugging: easy to start a match from the middle of a game (using various opening types); easy to pick up a position from long logs (for debugging purposes)
  • Almost all new and/or strong chess engines support UCI
  • Almost all chess GUIs support

Fabien Letouzey emphasize the ease of implementation in a Quisinsky interview, April 05, 2005 [5] :

The choice of UCI is based on software-design principles that are not easy to explain. It's a programmer's thing really, I don't expect engine users to understand. Let me give you a clue though: think about young WinBoard engines that you have tried; how many handled pondering ... without bugs??? Another clue might be that surely, [Stefan Meyer-Kahlen](Stefan_Meyer-Kahlen "Stefan Meyer-Kahlen") knows a lot about good programming, right? So trust him if not me, UCI is good for programmers because it leads to fewer bugs in the code ...

Fabien wrote a protocol translation program, PolyGlot to allow use of the new protocol on Linux, though this is now supported natively by the powerful Scid vs. PC toolkit. Scid vs. PC itself includes Polyglot code to enable support for Polyglot opening books.

Marco Costalba replied Robert Hyatt on a Talkchess thread [6]

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.

Nguyen Pham replied Harm Geert Muller on a Talkchess thread [7]

UCI's statelessness is surely not a bad idea. Your example did not prove that (it is a bad idea) but just point out a flawed detail on UCI design.
A stateless protocol means a chess GUI must provide enough information each time an engine starts thinking. In your example, it cannot send enough information about the timer since the protocol does not mention it. It is not a big deal since programmers can solve that issue easily by adding some assumes. Of course, it is better one day we can fix those flawed details in the protocol (version 2?).
I have written engines with both protocols (UCI, WB) and now support them all in my own chess GUI. Thus I have my own ideas about the strong points of each. Both are so good and can do so well their jobs. The stateless idea is the central point of UCI, which makes it a bit more suitable for modern computers and programming - that is why recently it becomes very popular.

Engines

GUIs

CLIs

Utilities

See also

Forum Posts

2000 …

2005 …

2010 …

2011

2012

2013

2014

2015 …

Re: Ugly UCI by Marcel van Kervinck, CCC, November 27, 2015 2016

2017

2018

2019

2020 …

2021

Interviews

Implementations

JavaScript

node-uci Documentation

Video Tutorials

References

  1. ↑ Interview with SOS programmer Rudolf Huber in German language! by Frank Quisinsky, Arena Chess GUI 3.0 - Archive 9, 132, May 10, 2005 ( Wayback Machine
  2. ↑ Universal Chess Interface From Wikipedia
  3. ↑ Arena, Interviews mit Prof. Dr. Robert Hyatt, Tim Mann und Martin Blume by Frank Quisinsky for ChessBits, No. 18, May 2002 ( Wayback Machine)
  4. ↑ Re: PGN standard, its improvement and standardization by Nguyen Pham, CCC, October 14, 2019 » from Portable Game Notation to Protocols
  5. ↑ The alternative to Crafty, Interview with Fabien Letouzey by Frank Quisinsky, Arena Chess GUI 3.0 - Archive , Page 7, 96, April 05, 2005
  6. ↑ Re: Ugly UCI by Kempelen, CCC, November 29, 2015 » Protocols
  7. ↑ Re: PGN standard, its improvement and standardization by Nguyen Pham, CCC, October 14, 2019 » from Portable Game Notation to Protocols
  8. ↑ Javascript Universal Chess Interface | Free software downloads at SourceForge.net by Edmund Moshammer
  9. ↑ 中国象棋电脑应用规范(五)：中国象棋通用引擎协议 Universal Chinese Chess Protocol (UCCI)
  10. ↑ 3 interviews about engine protocols with T. Mann, R. Hyatt and M. Blume by Frank Quisinsky, CCC, August 15, 2002
  11. ↑ Node.js from Wikipedia

Up one Level

Edit this page on GitHub
Prev
Ubaldo Andrea Farina
Next
UCI2WB