[Moved from computer-go.]
Mark Boon wrote:
At the moment only category 2 is of interest now, the other two categories I could deal with myself. I'll list them below. Most of them are related to the state of the game. Although the GTP definition explicitly states a certain amount of state is expected to be kept by the engine (like the number of stones captured, history etc.), it doesnt provide commands to query this state. Although it is not strictly necessary to provide means to extract this information, it can be very convenient. After all, for an engine to work meaningfully, it needs to implement a minimal administration of the game and knowledge about legal moves. By exposing this knowledge, a front-end could trust the engine to provide this information correctly, thereby reducing the complexity of the front-end.
This is what I also thought once. In fact there's an entire outcommented section "Introspective Commands" in the LaTeX source for the second draft, containing the commands all_legal, is_legal, captures, color, countlib, findlib, get_handicap, get_komi, list_stones, query_boardsize.
Today I'm more doubtful. The idea of a thin front-end doesn't seem all that attractive. I'd rather add board logic to a front-end than increasing the minimum requirements on the engines to interface to it.
Still some commands of this kind may be worth standardizing. New people to the GTP list should be aware that the plan is to finalize GTP version 2 as is so this discussion applies to version 3.
# 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.
There are two reasons why this is missing. The first one is that it's not clear how to best design this and how to specify the different rules. The second one is that it's reasonable to assume that rules are relatively fixed, so that it's feasible to set them by other means, e.g. command line options or GUI settings, for a whole session. (This reasoning obviously didn't take the multiple rulesets of KGS into account.)
Anyway, I consider this a priority item for GTP version 3 but I don't think the right approach is to enumerate a number of rulesets by name. Rather I'd like to have the rules defined by their properties, e.g. suicide allowed or disallowed, type of ko rule, territory or area scoring, points for seki or not, and so on.
# 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
GNU Go has the (private) command captures which takes a color as argument. I'm somewhat doubtful about the usefulness of this.
# is_legal arguments vertex color effects none output whether a move played by color would be a legal move (boolean) fails never
This is also available in GNU Go but as has already been pointed out it takes a "move" which is "color vertex" as argument. I think this is worth standardizing.
# next_move_nr arguments none effects none output number of the next move to be played (int) fails never
I think the front-end is better suited to keep track of this than the engine. Nobody has even bothered implementing a command of this kind in GNU Go, which is some kind of sign. (There are 136 commands in GNU Go, asking the engine for all sorts of things.)
# color_to_move arguments none effects none output color of the next move to be played (b|w) fails never
As pointed out before the engine is not expected to have an opinion about who plays when and in any case this is mostly redundant with the following command (with the possible exception of the first move).
# last_move arguments none effects none output vertex color (b|w) of the move that was last played fails never
Implemented in GNU Go (but with a "move" as output). I'm somewhat doubtful about the value of standardizing this. For GNU Go it's mostly used in conjunction with loadsgf.
# nr_passes arguments none effects none output number of consecutive passes played (int) fails never
This is trivial for the controller to keep track of.
# adjust_status arguments vertex* status (alive,seki or dead) effects the next call to final_score will return the score with the status adjusted at the list of points passed output none fails never
I'm negative. If the controller wants to do fancy stuff with scoring it can count the score itself.
# 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 absolutely doesn't fit with the GTP communication model. As commands must be responded to in order, this can't be answered in time to be useful. Rather if a genmove command has been issued but has not had a response the engine is thinking on a move, otherwise not.
/Gunnar