Author: Peter McKenzie
Date: 11:06:31 02/25/01
Hi, The UCI is a protocol for communicating between a chess GUI and an engine, for a description and specification see: http://amateurschach.in-trier.de/news_41a.htm 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 death!? 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 commands. Consider the following scenario: go 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 silly! 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? cheers, Peter
This page took 0 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.