Jeff wrote:
Would it be useful to know whether the engine thinks the game is over
Then it should answer a genmove_* command with PASS.
and perhaps thinks itself the winner? IE handing the scoring phase, perhaps including declarations of the life/death status of groups?
Yes, I think we should have optional commands to ask the engine about its opinion on score and group status at the end of the game. Such commands are implemented in GNU Go as final_score, final_status, and final_status_list.
The commands you've listed allow a game to be played through a smart referee, presumably a human, who could handle cases where one engine thinks it has killed a group but another has not (ie an engine bug) and who could really determine such things as the game has endend. Without these smarts, full automation of a set of games (for learning or competition) may not be possible.
The referee could also use a program, e.g. current versions of GNU Go would do a decent job at automatic scoring. To make it more clear what I mean I have the following setup in mind:
A <-- Arbiter --> B | v scorer
The arbiter communicates with engines A and B through GTP channels and relays moves until both program passes. Then it opens a third GTP channel to another engine to which it passes the position and asks it to score.
Furthermore it's of course always possible to use strict Tromp-Taylor rules and let the engines suffer their mistakes if they fail to remove dead stones. In that case the counting could easily be coded in the arbiter.
Anyway it's true that the protocol doesn't try to implement any agreement phase. If someone can come up with an elegant design of this it may be included in some later revision of the protocol, but hardly in the first one.
For instance I've seen instances where an engine is trying to make a move the other thinks isn't possible. This happens in programs using machine learning techniques, depending on how much expertise is coded into the engine. Handling automated game playing required us in OpenGo to put intelligence into the 'referee' to cope with this -- thus the protocol required some way to tell an engine that it's move is rejected and the game is over (it can cleanup or do what it has to do then)...
Taking a step away from gnugo itself, are these issues you want to concern yourself with?
Maybe, depending on whether I understand you correctly. In my opinion the arbiter has two reasonable responses for handling differing opinions on legal moves:
1. Stop the game and declare a loss for the program breaking the rules. (Either by determining this itself or asking a human to investigate.) 2. Stop the game, let a human operator fix the bug causing an illegal move to be made, and restart the game.
If an engine does need help identifying legal moves, this can be done by letting it open a GTP connection to a program with this capability, which it can ask about move legality. This would require some command like is_legal or all_legal, which are available in GNU Go. Probably these commands should be standardized but not required from every engine.
Also a question: does the protocol include the negotiation of these terms with the engine (ie a request for it's capabilities in the first place, and an ack or something implying it can play to the terms requested) (sorry if this should be obvious in the documentation, but i've not really gone through it...)
Again I'm not fully certain I understand the question, but one of the basics of the protocol is that a command from the arbiter is answered either on the form "=[id] result" or "?[id] error_message", where the former case indicates success and the latter case failure.
The only exact specification of results and error messages is currently the GNU Go source code. This needs of course be addressed by the standard. I'll try to specify the syntax and semantics of all the basic commands as they are understood by GNU Go in a later message.
issues like cr & crlf can be finessed by requiring an end statement, such as semi-colon, so that cr & crlf can be ignored. but then it isn't quite so elegant. but then what is the goal of the text: ie it seems that you want some sort of readability in the protocol, but why?
Primarily for two reasons: 1. Make it easy to debug the protocol, e.g. by inspecting a log to see what part failed to follow the protocol if the communication breaks down. 2. GTP commands can be written as scripts for regression testing, which was the first application of GTP in GNU Go. These test suites are more easily maintained if the protocol is readable.
/Gunnar