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 >comments/suggestions. > >(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 >FRC/CRC). > >(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)... > >Thanks, >Michael
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.