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,
--
Andrew D. Balsa
andrebalsa(a)mailingaddress.org
