I started this subject but unfortunately I've been absorbed by some unexpected real-world problems.
Apart from the rule-set question, I think all the others are related to querying the engine for its adminisrtative status. I've been thinking about this a little bit and I think there are two views one can take:
1) Leave this kind of stuff to the controller and not burden the protocol with it. 2) Allow for the possibility of making a simpler front-end by using some functionality that an engine is bound to have anyway.
I suspect that it may depend on which side you're writing what you're view is in this matter.
An argument for 1) is that it should be made as easy as possible to write an engine, as it's hard enough already. On the other hand: I don't see how you can make a serious engine without this stuff on the engine side. If you allow access it you have the opportunity of not duplicating the effort.
Maybe some very simple engines can do without it, like some random players. To be honest I don't see much value in encouraging more random engines to be written than there already are. Maybe it's fun for someone as a pet-project but it's not going to advance computer Go in any meaningful manner.
But I can see the value in keeping the protocol simple. If I'm going to be developing just the engine-side, I may not care how much effort goes in the front-end.
Hopefully I'll be able to continue work on this soon (maybe a few weeks, I hope sooner) and things will settle within my mind some more.
Mark Boon
On Mar 27, 2006, at 7:28 PM, Gunnar Farnebäck wrote:
[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 _______________________________________________ gtp mailing list gtp@lists.lysator.liu.se http://lists.lysator.liu.se/mailman/listinfo/gtp