Adriaan wrote:
Personally, I am using gnugo as a "reference implementation" for GTP. I am writing a nngs <--> gtp interface (unix: pipe+fork+exec) so that i can use nngs as primary interface for go-programs.
I assume you are aware that there already exists two go server to GTP bridges, gnugoclient by me and gtpclient.c by Tristan Cazenave. How does your program differ? Will it be publically available?
There are two things, I would like to be changed in gtp:
- a reserved namespace for "local" additions, eg all commands starting with [xyz] are reserved for local command extension.
This is addressed in my new specification draft. The relevant section looks like this, in the LaTeX source format (when I put it up it will also be available as HTML, postscript, and pdf):
| \subsection{Private Extensions} | \label{sec:private-extensions} | The protocol is trivial to extend with new commands. Obviously there is | a risk for conflicts if multiple engines make incompatible private | extensions of the protocol or if an engine makes a private extension | which turns out to be incompatible with a future extension of the | standard protocol. | | In order to avoid this problem, standard commands do not include the | dash (\texttt{-}) character. Private extensions are recommended to be of | the form \texttt{XXX-YYYYY}, where \texttt{XXX} is a prefix which is | sufficiently unique for the engine or controller in question, and | \texttt{YYYYY} describes the command. E.g.\ a private variant of the | \texttt{genmove} command used by GNU Go could be called | \texttt{gg-genmove}. | | Engines are allowed to use private extensions without a dash in the | name, but then they do it at their own risk and must be prepared to | change if the name later becomes used for a standard command.
- gnugo should *not* pollute the existing namespace with redundant commands. eg: genmove_black is equivalent to "genmove b". this is protocolbloat to avoid.
There is no "genmove" command in GNU Go. You may be thinking of "gg_genmove" which exists in addition to "genmove_black" and "genmove_white". These differ in gg_genmove being appropriate for regression testing and genmove_* for actual play. The main distinction is that gg_genmove always generates the same move in a given position while genmove_* chooses randomly between equally valued moves.
In version two of the protocol genmove_black and genmove_white will be replaced by a single genmove command. There will also be a command reg_genmove for regression purposes.
- gnugo extends the error messages with descriptive text, eg: out_of_range: point d33 is outside the board.
I'd like a concrete (and real) example to comment on that.
- some features still seem to bi missing : the equivalents of sgf MN, PL , some timecontrol.
How would MN be useful? PL follows implicitly from the issued genmove commands. Time control commands are included in the new draft.
- at the moment, the protocol is practically stateless. this allows for the goprogram to accept and generate moves , without having a notion of a game (or gamestate). Maybe a "game" or "session" layer should be added in a next version of the protocol.
To solve what problems?
/Gunnar