Author: Dan Newman
Date: 23:12:43 06/01/98
Go up one level in this thread
Hi,
I think such a protocol will be a good thing for many of
us programmers--especially if it fixes some of those
limitations of the xboard/Winboard protocol imposed by
its compatibility requirements. Here are some comments
and suggestions for modifications and additions:
1) I think the timecontrol stuff should be separated out of
the "go" command. Suppose you want to play a game between
two programs. It seems to me that you would first want
to give both of the programs the time control numbers, and
then give just one of them the "go" command. (Winboard, of
course, gives each program the remaining time on its clocks
on every move--this might also be something to add.)
For example you could have:
go {parameterless, just tells the
program to start playing}
tc 5:00 {5 min, 0 second time control
period}
nmoves 40 {40 moves must be made in
the tc period}
increment 10 {add 10 seconds to the clock
on each move}
2) Perhaps moves could be prefaced with a tag like all the
other commands, e.g. "move e2e4", though obviously this
isn't strictly necessary. It would, however, make this
system more consistent. Also, suppose you don't implement
all the commands in your chess engine: with no special
tags for moves, how do you distinguish moves from
unimplemented commands (other than the fact that command
tags generally aren't legal move strings)?
3) It would be nice to have a command (from the chess engine)
to indicate that it is ready for a game--something that is
missing (I think) from the Winboard protocol. (My program
sits there and churns for 2 or 3 seconds when it is first
loaded and loses a few seconds on Winboard's clock when
started in match mode--it would be nice if it waited until
my program was ready.)
4) More handshaking would be good. The ping and pong commands
are a great idea along that line. If something really gets
hung it can be detected and the controlling program can
kill it.
5) Commands for resigning, offering/accepting draw, etc. are
needed as well as commands for setting the side (color)
of the engine(s) (though the "pos" command might be enough
for some purposes).
6) Some specification of what comes first in sequences of
commands that typically come together, e.g.., which comes
first, "pv" or "score"? If one order is expected and a
program sends them in reverse order, the wrong score
might become attached to a PV on a GUI display.
7) Along with ponder on/off perhaps other commands for common
features of programs could be added. Something to set the
maximum size of transposition tables for instance.
8) I was going to suggest that the "pos" command use EPD or
FEN, but upon thinking about it, I like your scheme better.
It's simpler to interpret or generate than EPD or FEN and
is only for inter-program communication anyway.
9) My current program doesn't do undo at present. If it is
sent an "undo" it needs some way of telling the sender
that it wasn't able to perform the command--maybe an
"illegal" or "na" (not available) message/command could
be added to handle cases like this. (This gets back to
the "more handshaking" idea.)
Anyway, that's all I can think of for now. I hope these
comments are useful.
-Dan.
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.