Computer Chess Club Archives




Subject: UCI Issues

Author: Peter McKenzie

Date: 11:06:31 02/25/01

The UCI is a protocol for communicating between a chess GUI and an engine, for a
description and specification see:

Over the last few days I've been implementing UCI support in LambChop, it has
gone ok and yesterday LambChop managed to play a complete game using UCI.

There are a few things in the spec that aren't clear, so I thought I'd bring
them up here for discussion (Rudolf Huber, one of the co-authors of the UCI
suggested this).

The time control commands in UCI are:
btime - black time remaining
wtime - white time remaining
binc  - black increment
winc  - white increment
movestogo - moves until next time control.

There is little in the spec that talks about the general usage of these
commands, which is a little confusing.  In fact it seems hard to use these
commands without making certain assumptions...

After logging the UCI commands, I noticed that the various time control commands
are sent AFTER the "go" command.  Is this always the case?

Here is one problem: the note with movestogo says this: "there are x moves to
the next time control, this will only be sent if x > 0, if you don't get this
and get the wtime and btime it's sudden death"

This last bit "if you don't get this and get the wtime and btime it's sudden
death", does that mean that if I haven't received a movestogo command SINCE THE
LAST GO COMMAND, and I receive a wtime or btime command, then I can assume it is
sudden death?  In other words, should I reset movestogo to assume sudden deatch
after each go command??

Perhaps SIMPLER would have been for UCI to just send 'movestogo 0' for sudden

Also, I noticed that the binc and winc commands seem to be sent after the wtime
and btime commands.  This gets tricky because it also seems that when there is
zero increment, the binc and winc commands are not sent at all!  This point
isn't mentioned in the specification by the way.  MUCH SIMPLER would be so send
'binc 0' and 'winc 0' when there is no increment.  Also, MUCH SIMPLER would be
to send the increment commands between the go command and the wtime and btime

Consider the following scenario:

movestogo 2
wtime 5000
btime 5000
winc 3
binc 3

ok, say my engine is playing white, so after getting 'wtime 5000' I must set my
engine's thinking time to approx 5000millisec/2.  But then the winc command
comes in, so I must immediately change my engines thinking time - seems a bit

Perhaps I should remember the previous winc and binc settings?  But this
approach would be very dangerous for the following 2 reasons
- there is nothing in the UCI to indicate that a new game has started
- the binc or winc settings may have been changed between 2 games (and if they
are changed to zero, we are not told this explicitly!)

This last point goes for the movestogo command to: when the time control changes
between one game and the next eg: from 40/5min to game/5min, then we are not
explicitly told about it.  We must somehow figure it out because the movestogo
command hasn't been sent for a while, quite unclear I think.

Overall the UCI is a nice protocol, but the time control handling in UCI seems
worse than in the xboard protocol.  Perhaps I missed something?  Or perhaps
there are some unstated rules missing from the spec?


This page took 0.05 seconds to execute

Last modified: Thu, 15 Apr 21 08:11:13 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.