Computer Chess Club Archives




Subject: Re: Extensible Chess Interface (XCI) : updated draft

Author: Lance Perkins

Date: 15:14:16 03/14/05

Go up one level in this thread

Before defining the protocol, I think you should first analyze what the personas
of the endpoints are, and then define the scenarios that you want to support.

Here is one example of how this can be approached.

I'm defining an entity called a "chess agent". A chess agent is capable of
playing chess and requires a protocol to do so with another chess agent.

The persona of this chess agent can be:

1. The chess agent is interested playing a "complete" chess game with another
chess agent.
2. The chess agent is interested in completing a chess game in a reasonable
amount of time.
3. The chess agent is interested in winning chess games. The implication of this
is that the chess agent might require all the legal/valid information that it
needs to best play the game (like who is the oponent, what is the best opening
lines agains such an oponent, etc.).
4. The chess agent is interested in improving its chess playing abilites. This
can mean book learning for engines, or position analysis for humans.
5. The chess agent is interested in using the aid of another chess agent to play
a chess game. This can mean a human using a chess engine, or chess engine using
another chess engine.
6. etc., etc., etc

Now, the scenarios that could come up from the list above could include:

1. A chess agent starts a chess game against another chess agent. The two chess
agents exchange game settings, exchanges moves, and ends the game.
2. Two chess agents are in the middle of a game. The connection gets terminated.
The connection gets resumged and the game is played to its completion.
3. Two chess agents are in the middle of a game. Both agents deteremined that
the game is drawn. Both agree to end the game.
4. A chess agent uses another chess agent to analyze a position. As a result,
the chess agent improves its playing abilities. This can be a human directing a
chess engine to analyze a position. This can also be a chess engine direting
another (stronger) chess engine and then updating the score for a book move
based on the result of the analysis.
5. etc. etc., etc

Some form of analysis should have been done and documented for xboard (and UCI,
especially that it came later). Had it been so, we would probably not be making
this redesign now (unless the personas and scenarios have drastically changed).


On March 14, 2005 at 12:45:22, Michael Yee wrote:

>The protocol proposal has been updated to reflect several good
>(1) There is now a table of what commands are valid in each state. This makes
>the protocol clearer and even look simpler than it did before (at least to me
>:). Thanks to Harald for this suggestion.
>(2) New commands from GUI to engine : getstartpos, getmovelist, getresult
>This enables the protocol to be truly extensible since variants that aren't
>officially supported by the GUI can still be supported by letting one engine be
>the "referee" or "arbiter". This interesting idea came from Reinhard (also the
>source of the move and position formats for officially supported variants
>(3) New command from engine to GUI : error
>Even if people are dead set against introducing a new protocol into the mix, I'm
>curious what UCI fans think about some of the extensions. Specifically,
>- describing what options mean,
>- custom thinking output, and even
>- getstartpos, getmovelist, getresult
>could be added without too much fuss (while maintaining the core philosophy of a
>stateless engine)...

This page took 0.02 seconds to execute

Last modified: Thu, 07 Jul 11 08:48:38 -0700

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