Although this appealed to me at first, I have this feeling that whatever we do on the first pass, will end up being the defacto standard and nothing beyond this will likely get implemented. We will live with it for years! Maybe we should make some effort to make it complete enough to serve us well?
I agree. This is the time to get it right. The command set needs to be sufficiently complete to allow sophisticated arbiter programs. If the command set is too minimal and e.g. requires manual setup of the programs between games, we've lost a lot of the advantages the GTP could offer over GMP.
So what if we add something like this? (I need feedback here)
ko setup ruleset set_level version
[...]
Don
This is a good start. A comment to set_level: SmartGo doesn't use levels, it uses the time available to determine how much time to spend on a move. So for generating a move, SmartGo needs to know whether this is part of a game being played (and how much time is left in the game), or whether it's just an individual move to generate within a given amount of time, such as 20 seconds.
One thing that has not been discussed much so far is the state we expect each program to maintain. Once we define the minimal state a Go program has to maintain, it may be easier to identify the appropriate commands, and it may also help define each command more precisely in terms of how it affects that state.
At a minimum, I'd expect each Go program talking GTP to know the following: (A) Board size. (B) Komi. (C) Handicap (fixed handicap, or remaining moves to play using arbitrary placement of handicap stones). (D) The ko and scoring rules in effect. (E) Board position. (F) Whose turn it is to play. (G) Enough knowledge of the history of the game to identify ko and repeated positions.
(A)-(D) get set up at the beginning of the game, while (E)-(G) change with each move played.
For each move to be played, the program needs to be told: (H) Time left (if this is a game rather than a problem position), or time to use for generating this move.
In addition, the program must be told (or have a way to request) the following information: (I) The time and overtime rules in effect (e.g. need to complete the first 250 moves within one hour). (J) If playing a game, the name of the opponent program. Many programs may ignore this information and will just play as fast as possible and not make any distinction between opponents, but if GTP is used to fully automate computer Go tournaments, I think this is needed.
Comments?
Anders Kierulf www.smartgo.com