OK here's draft 4. Mostly this is the changes Gunnar recommended, plus one more thing that I realized Must be possible for programs to implement their own extensions to GTP in a clean manner". I've heard lots of people talk about this, I don't think it will cause much dissent - obviously if GTP is good, most programs won't /need /to implement their own extensions, but we know that some will have to. ******************** GTP Goals version 4
Part I - Functional Requirements. These are the actions that our command list must allow go programs to perform.
1. Usable to play games vs. other programs head to head. If the protocol requires some kind of arbiter, that's OK, but see III.2. 2. Usable for regression tests on programs. 3. Usable for playing go on a server. 4. Usable to write a GUI or control program for a go playing engine. 5. Must be possible for programs to implement their own extensions to GTP in a clean manner.
Part II - Implementation Goals. Constraints that we must follow when designing the exact command list.
1. 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 easily delimited block of text in return. 2. 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.
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.
1. An example program that implements the tournament 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. 3. 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.
1. A sample GTP program that understands all of the commands. 2. GTP bridges for various servers. 3. 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.