"Sanghyeon Seo" sanxiyn@gmail.com writes:

Mark Boon proposed number of additions to GTP commands. The original post can be found here: http://computer-go.org/pipermail/computer-go/2006-March/004962.html

FWIW, one of the arguments for providing some of the commands was that the engine must know, and therefore it was easier for a UI to ask the engine than to remember for itself. However, I'm not sure I agree. Surely it is the (main ?) job of the UI or controller to remember which player has the next turn. Also, I think it is perfectly possible to construct an engine which can suggest the next move for a particular colour without having any notion of the history of the game. On those grounds I would disagree with

# next_move_nr arguments none effects none output number of the next move to be played (int) fails never

# color_to_move arguments none effects none output color of the next move to be played (b|w) fails never

# last_move arguments none effects none output vertex color (b|w) of the move that was last played fails never

# last_move arguments none effects none output vertex color (b|w) of the move that was last played fails never

# nr_passes arguments none effects none output number of consecutive passes played (int) fails never

Also, the protocol says that for the play command, "Consecutive moves of the same color are not considered illegal from the protocol point of view." So it may not make sense for the engine to attempt to track the notion of whose turn is next. Do we need both last_move and color_to_move - isn't one always the inverse of the other ?

I might suggest combining

# captured_by_black arguments none effects none output number of stones captured by the black player (int) fails never

# captured_by_white arguments none effects none output number of stones captured by the white player (int) fails never

into one command. Either pass colour as a parameter, or just return both scores with one query. But not a big deal.

In chinese scoring, the engine might not bother tracking this anyway. I agree that this is something that is trivial for the engine to do, and hard for a UI to do. However, a UI has to also figure out *which* stones to remove, and so just knowing the number may not be enough.

Perhaps a slightly more general question might be to ask the engine to estimate the score. This might include the captured stones, but might also give the engines current estimate of the score, if that makes sense.

# set_rules arguments rules (string) effects the engine will return moves and score according to these rules. output none fails when rules are not supported by the engine comments The engine needs to know by which rules the game is played, it seems strange this command is missing.

Passing as a string might be contentious... Presumably the value can only be one of a fixed set of ruleset names, so the rulesets have to be enumerated in the spec. So perhaps just pass a number.

Alternateively, if the rules can be encoded as a set of independent properties (suicide allowed ; scoring by area / territory ; must capture all prisoners ; etc) then passing those values might be useful ?

# thinking arguments none effects none output whether the engine is currently thinking about its next move (boolean) fails never comment this can be very useful to prevent undesirable re-entry of the engine

This assumes a multi-threaded engine which can check the comms channel while it is thinking. At least some engines will just ignore the query until they have finished their move, and will then always answer no.

This would violate 2.8 of the spec : the engine must respond to commands in the same order they come in.

I guess this could be added as a protocol proxy - most queries it passes onto the engine directly, but this one it can answer itself.

dd