Bill Shubert wrote:
GTP Goals version 3
Part I - Functional Requirements. These are the actions that our command list must allow go programs to perform.
- Usable to play games vs. other programs head to head. If the
protocol requires some kind of arbiter, that's OK, but see III.1. 2. Usable for regression tests on programs. 3. Usable for playing go on a server. 4. Usable to write full featured interfaces.
This depends on what is meant by full featured. As other people have discussed it's unreasonable to hope that a protocol like this could ever do all the fancy things that many programs have in their native interfaces. But if we're talking about a more limited interpretation of "full featured", and there seems to be some consensus about this, it's a worthwhile goal. Well, my point is that this needs some clarification.
Part II - Implementation Goals. Constraints that we must follow when designing the exact command list.
- Simple to implement, debug and understand; all commands are ASCII,
all human text (comments etc.) is UTF-8, exactly one line per command, each command gets an exactly one line response.
No, one line responses do not suffice. This is why the protocol specifies a double newline to finish the response.
- Possible to create bridges that let GMP programs play head to head
vs. GTP programs in tournaments. Note that GTP and GMP will not necessarily have the same feature set - just the possibility of playing against each other is necessary. 3. There must be a "tournament command set" that is designed to be a small enough set of commands to be extremely easy to implement but complete enough to make go program tournaments efficient to operate. All commands needed only for regression tests, server play, or "full featured" front ends are optional extensions that programmers need not implement if they plan on using GTP only for tournaments. 4. It should be possible to design software that gracefully deals with unimplemented GTP commands/features when using GTP to communicate with other programs that have not implemented quite the same feature set.
Part III - Necessary Auxiliary Programs. These are programs that we (the GTP designers) must write for GTP to be successful. All must be open source.
- An example program that implements the minimal GTP command set
properly and can play a legal game (similar to the goDummy program for GMP). 2. An arbiter to be used in head-to-head games, communicating to both programs, judging legal/illegal rules, etc. Should the arbiter know how to score a game?
Scoring in the arbiter is not critical.
- A GMP-to-GTP bridge to allow GMP programs and GTP programs to play
against each other.
Part IV - Additional Programs. These are programs that are not necessary for us to call GTP "done" but would be useful to have publicly available.
- A sample GTP program that understands all of the commands.
- GTP bridges for various servers.
- GUIs and other human-usable front ends so that programmers who
write GTP programs can automatically play against their programs, query their programs as to evaluations, etc. 4. A GTP test system/test library to determine whether or not a program is emitting legal GTP.
Except for my comments, I'm happy with this.
/Gunnar