Extensible Chess Interface (XCI)

Last updated : 2005.03.14

1 Introduction

If there already exist two or more chess communication protocols, why bother with another?

Protocol Draw Offers Resign Full Knowledge of Time Control Full Knowledge of Game Result Modes Configurable Options Standardized Output Extensible Output FRC/CRC Support
WinBoard x x ~ x x o o o o
UCI o o o o o x x o o
XCI x x x x o x x x x

It will become very obvious that the proposed protocol borrows heavily from the syntax of the UCI protocol (created by Stefan Meyer-Kahlen and Rudolf Huber). It was tempting to make XCI backwards compatible with UCI, however it would have gone against some of the design goals. The similarities to UCI are intended to make XCI easy to implement. Furthermore, XCI borrows from several "concepts" and goals from WinBoard, such as giving the engine nearly full control over all aspects of a game of chess.

2 Design Goals

The following are the guiding principles for the protocol:

3 Key Differences From XBoard/WinBoard

4 Key Differences From UCI

5 Engine States

There are 4 possible states the engine can be in: The following table illustrates what commands are valid in each state and what the engine should do when receiving a given command.

State Command Engine Activity/Output Next State
START xci action : initialization, identification, and notification of supported options/custom info

id name
id author
id country
id about
...
id about
option
...
option
info name
...
info name
readyok
WAIT
WAIT position action : set new position (and assume in new game/fragment)
WAIT
move action : make move on internal board
WAIT
level action : inform engine of full time control
WAIT
setoption action : set option to specified value
note : if option is XCI_Variant, can assume that will get a new position command before next go command
WAIT
isready action : synchronize GUI and engine

readyok
WAIT
result action : inform engine of game result
WAIT
getbook action : get book info

info book ...
WAIT
getstartpos action : get start position (useful for new variants currently without official GUI support)

info startpos ...
WAIT
getmovelist action : get legal move list for current position

info movelist ...
WAIT
getresult action : get result for current position (i.e., win, loss, draw, inprogress)

info result ...
WAIT
go ponder action : start pondering (optional)

info ...
PONDER
go infinite action : start analyzing (which might be different from THINK-style computation, e.g., symmetric vs asymmetric eval)

info ...
ANALYZE
go (without ponder or infinite) action : start thinking (with goal to produce best move given current position and current state of the game)

info ...
offerdraw (optional)
acceptdraw (optionl; only if go command contained drawoffer)
THINK
quit action : shut down as soon as possible
END
THINK stop action : stop thinking and send best move

bestmove ...
WAIT
bestmove (from engine) action : engine sends best move and stops computation
WAIT
resign (from engine) action : engine resigns and stops computation
WAIT
isready action : synchronize GUI and engine

readyok
THINK
PONDER stop action : stop pondering

readyok ...
WAIT
isready action : synchronize GUI and engine

readyok
PONDER
ANALYZE stop action : stop analyzing

bestmove ...
WAIT
isready action : synchronize GUI and engine

readyok
ANALYZE
(any) error (from engine) action : engine has error (although shouldn't really happen too much)
WAIT

Note that options set with the setoption command also have an impact on the engine's internal state (especially XCI_Variant).

6 Commands From GUI to Engine

6.x xci

6.x position

6.x move

6.x level

6.x setoption

6.x go

6.x getbook

6.x getstartpos

6.x getmovelist

6.x getresult

6.x stop

6.x isready

6.x result

6.x quit

7 Commands From Engine to GUI

7.x id

7.x acceptdraw

7.x bestmove

7.x info

7.x option

7.x offerdraw

7.x resign

7.x readyok

7.x error

8 Move Format (for Standard and FRC/CRC)

9 Position Format (for Standard and FRC/CRC)

10 Sample Sessions