Thanks to Phil for getting this written up, it's good place to start from. Below are various comments and suggestions, and lots of questions.
(1) Optional id --------------- What's the purpose of these optional id numbers? As I understand it, the engine is simply echoing them, it can't base any of its decisions on these numbers. So how are they helping the controller program? How are these numbers used in GNU Go, and what would the protocol lose if these were removed from the standard?
(2) Error messages ------------------ Page 5 states that the error message should return "not implemented". So it seems that this error message is standardized, but not others. I'd suggest we standardize a list of error messages, and make them single words, e.g. "not_implemented", "illegal_move", and "invalid_coordinate". Controllers may then be able to make smarter decisions depending on the error message returned.
(3) Command sets ---------------- In my opinion, the tournament command set should be the core set. Every Go program should at least implement the commands necessary to play in a computer-computer tournament. We need to keep that command set simple enough that this is not a burden, but I don't see a benefit in splitting up the tournament and the core command set.
(4) Missing commands -------------------- - Need a way to set up a position (as discussed previously, playing moves is not a substitute). - Need to know under what rules the game is being played. - Need a way to know how much time to spend on a move or on the whole game, and how much time is left. - Query position: There should be a way for the controller to get the current board position from the engine. (Not necessarily a core command, but would help a lot with debugging and verifying engines.)
(5) Argument definitions ------------------------ - For coordinates, both lowercase and uppercase coordinates should be acceptable. The standard coordinates are most often given in uppercase, and GTP shouldn't require people to change coordinate notation. (I know, I made that mistake in SGF.)
- Real: No need for everybody to deal with numbers like 1.7E308. Real numbers will only be used for things like komi, score, and time left, so a simpler definition will do.
- Date: Why not use the standard YYYY-MM-DD format that's used in SGF? (Doesn't seem to be used by any commands yet, though.)
(6) What to do on failure ------------------------- The GTP standard should clearly state that anytime failure is returned, the state of the Go program must remain unchanged. That simplifies the description of the "On Failure" section for each command, that section simply needs to list the standard error messages that can be returned.
(7) Specific commands --------------------- - 'boardsize': The Notes section is clearly part of the definition of this command, and should thus be moved to the On Success section.
- 'fixed_handicap': What if this command is not sent at the beginning of the game? Is the only purpose of this command to get the coordinates of fixed handicap stones, or does it also play them on the board? Why include this in the core set of commands, why not put the responsibility for figuring out where to put handicap stones in the controller?
- 'komi': I don't think the standard should specify a default komi. Why 5.5 and not 6.5 or 7.5? The komi should be zero unless specified. I think it will be easier to get all the controllers to always send a komi command than to make sure they remember to set the komi to zero (or 0.5) for handicap games.
- 'is_legal': I like this command, but why does it specify color and coordinate while other commands use separate commands for each color? Why not have 'genmove' and 'move' commands rather than 'genmove_black', 'genmove_white', 'black', and 'white'?
- 'all_legal': Instead of providing a command that returns a huge number of legal points to play, we should define a command (e.g. 'illegal_points') to return the empty points that are illegal to play on. This will just be a few points, much more manageable.
(8) State changes ----------------- The specification is vague on some points, for example: - Does 'loadsgf' change boardsize and komi? Does it reset the number of prisoners? - 'boardsize' probably resets the number of prisoners?
I think explicitly specifying the state maintained by each engine would make it clearer, and would make it easier to implement GTP correctly. For example, board_size, komi, and (optional) number_of_prisoners are clearly part of the state. Apparently, the current player is not (I think it should be, which would simplify many commands, but that's a different matter). Every command affecting this state should specify that.
(9) Timeouts ------------ What happens when the controller sends a genmove_black command and then waits for a reply, and waits, and waits, and waits? Should there be a way to query the engine whether it's still thinking?
Enough for now. This should get some discussions started. :-)
Anders Kierulf www.smartgo.com