Hi,
I would like to make a few suggestions for the next draft of the GTP version 2 spec. Just my $0.02:
a) For consistency reasons, is it possible to rename showboard to show_board? There is already clear_board.
b) In section 6.2 Protocol Subsets, could we add subsection 6.2.3 Debug? That would be: --------------------------------------------- 6.2.3 Debug The debug subset adds the commands: show_board ---------------------------------------------
c) In subsection 6.2.2 Regression, I would suggest the addition of: get_random_seed, set_random_seed Both commands are already implemented in GNU Go and I assume most, if not all engines would introduce a degree of randomness based on a seed. An engine that does not use pseudo-randomness (?) should output 1 for the get_random_seed command and save the parameter of the set_random_seed command in an otherwise unused variable, returning it if requested by the get_random_seed command.
d) For the showboard (or show_board) command, I would like to suggest the following description: * show_board arguments none effects none output the board in human-readable format. See Gnu Go output for example. fails board not cleared comments This command should fail if sent before the board is properly initialized (i.e. using the clear_board command).
e) I had some doubts about whether Wallyplus should output the string "pass" or "resign" when it wants to pass. In the end, I implemented "pass", even though I was under the impression that the present spec is "resign". I would be grateful if this issue could be clarified (in the genmove command description).
f) Is there a command that tells GNU Go to **explain** why it generated a specific move? Could such a command be included in the protocol? That would be in the Debug command subset, I believe. It could be something like: * comment_last_move arguments none effects none output reason, explanation or comments about the last move generated by the engine. fails no move generated comments This command should fail if sent before the engine is asked to generate any move. Returns an empty string if the engine cannot or does not want to comment its move.
I guess that last suggestion could be the matter of some debate, so I would like to explain why I am making it. Wallyplus can output a few lines of comments for every move it generates. I could save these comments in a string variable and just output them as a reply to the above command. It could prove quite useful to understand why an engine makes a particular move, without actually using a debugger while the engine is playing.
Again, these are just my $0.02. Please take with a ton of salt, flames to /dev/null, etc.
Greetings,