Hellwig wrote:
- Does the engine have to have the notion of a "current
player"? I remember having read in the archives that Gunnar objects.
No, the protocol should allow moves by either player at any time. For tournament use the moves would always be alternating of course. An engine which is written in a way which can't cope with moves out of turn should keep track of color to play and return error if requested to make a move it can't handle.
- If there is a "current player", why is white the default?
Shouln't it be black?
Black usually starts, so if there had been a current player it should have been black to start with.
- Is "fixed_handicap 0" a legal command? (It should be.)
Yes, letting "fixed_handicap 0" leave the board empty is no problem. What's worse is "fixed_handicap 1". This is quite a bit degenerated. Current GNU Go doesn't accept it.
- The fixed_handicap command description should contain
a statement that on success, the handicap stones are placed onto the board.
Agreed. The specification should also tell exactly where the handicap stones should go. (I don't know if this is controversial. I believe at least GMP, IGS, NNGS, and GNU Go have compatible placement.)
If indeed present, should the current player then change to white?
No current player, but had there been one it should have changed to white for handicap>0.
- Are the coordinates which constitute the response to a
fixed_handicap command output in separate lines?
No, only one line with space between each move.
- The 'state defaults' section should contain the statement
"The board is empty".
This and "no captured stones" are incidentally the only defaults needed in the specification. If the controller has any specific opinions on boardsize, komi, and so on, it should tell the engines explicitly.
- Case insensitivity in color specification, how far goes this?
Is "wHiTE" really ok? Or can a more restrictive set be specified, such as e.g. "one of 'w', 'white', 'W', or 'WHITE'"?
In terms of implementation the straightforward solution is to change the whole string to lower case and then do the comparison, so then also the sillycapsed versions would be accepted. For serious use "w", "W", "white", "WHITE", and possibly "White" should suffice. Would this simplify the formal specification?
- If a move command is successfully completed, the spec does
not say anything about a) current move number (updated?) b) current player (toggled?)
Neither state needs to be specified in the protocol.
- Is "pass" a legal 'coordinate' everywhere (e.g. in setup)?
It doesn't seem useful there. I don't think it should be legal. (Btw, does SGF allow an "AB[]" property? It's not clear to me from a quick look at the spec.)
- In a response in which the engine gives a move, does case
matter?
No, either case should be okay.
- The current specification does not give the engine the
possibility to include any comments into responses. This is of course not really necessary, but would have allowed, e.g., the debugging output of my protocol exerciser to be put into the responses. This feature would not in my opinion complicate response analysis unduly. What's your opinion?
I must admit I haven't even considered this possibility. It certainly wouldn't be a big problem to filter out comments at the controller end of the link.
/Gunnar