[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: computer-go: Go Text Protocol (GTP)



Don Dailey wrote:

> First of  all, to answer your  question, what I have implement between
> my interface and my go program is very  minimal and is just a subset
> of what is in gnugo:
> 
>      black
>      boardsize,
>      genmove_black
>      genmove_white
>      komi
>      new_score	
>      quit
>      showboard
>      size
>      white

This is almost the same set of commands needed to run twogtp. When
I added gtp support to GNU Go 2.6 I added the following commands:

    black
    boardsize
    fixed_handicap
    genmove_black
    genmove_white
    help
    komi
    name
    new_score
    quit
    showboard
    version
    white

> What I would  suggest   is that a    "minimal  set" of  commands   get
> documented.  A minimal set   would guarantee that your  software works
> with  anyone elses interface, autoplayer,  etc, and any external tools
> should be  designed to  work without  trouble using  this set.   There
> should not be  commands in this set  that require an unusual amount of
> effort to implement and this should  just include the basic mechanisms
> of  making moves, taking them back   and reporting starting parameters
> such as "boardsize."

What we seem to be close to being able to standardize immediately
would be a small set of commands that can be obeyed by a Go
program. 

The ability to respond to commands is not in itself enough to
allow two programs to interact without the intervention of a third
party unless one adds also the ability to issue them. Thus as the
protocol is currently implemented in GNU Go we cannot (as one does
using the gmp) cable together two computers by their serial ports
and expect them to play together without involving a client.

In order to achieve that, at least one of the two programs
would have to be able to issue commands as well as to obey
them. The protocol could be made symmetrical so that the same
channel is used to issue commands as to recieve them, or the
protocol could be left asymmetrical. I believe the latter is
Gunnar's intention but the documentation does not say this
explicitly.

In the GMP the same channel is used to reply to commands as to 
issue them, and there is no clear distinction between a command
and a reply. In a sense every GMP message is a command. Thus the
GMP protocol is symmetrical where the GTP as implemented in
GNU Go and other current examples is not.

The goal of allowing two computers to play together without a
third program mediating can still be achieved in the context
of an asymmetrical protocol if one program assumes the role of
a teacher (master) and the other that of a student
(slave). Thus one program issues commands and the other one
obeys them. They can still play a game.

Thus to there are three possibilities:

(1) Play only with the aid of a mediator such as twogtp.

(2) Add a mode to each program allowing it to issue GTP
commands as well as to receive them; for a game to commence
one program is the master, the other the student.

(3) Try to make the protocol symmetrical like the GMP;

My guess is that (3) would be a bad decision. My first
thought was that this means that a GMP/GTP translator is
not possible but I now think that it actually could be done.

Leaving aside these problems for another time, the following might
be a reasonable first set of commands:

black
boardsize
echo
final_score
fixed_handicap
genmove_black
genmove_white
help
is_legal
komi
loadsgf
name
new_score [but rename this estimate_score]
prisoners [but rename this captures]
protocol_version
quit
showboard
version
white

A further set of commands useful for a testsuite might
also be easy to standardize.

Dan