[computer-go] A thought about Bot-server communications

[Nick Wedd]

In message <475DADCB.7060505 at lysator.liu.se>, Gunnar Farnebäck 
<gunnar at lysator.liu.se> writes
>Nick Wedd wrote:
>> When I play Go on a Go server, I do not try to remember the board
>> position.  I can always find out what it is by looking at the client
>> window on my screen.
>>
>> When a bot plays on a Go server, it does remember the position. This is
>> something that programs are good at, so it seems reasonable to require
>> them to do it.
>>
>> But there can be, very rarely, circumstances where a bot would like to
>> ask the server "what is the current board position?".  Here are some
>> examples.
>>     (1)  My bot's opponent has just made a suicide move.  My bot does
>> not realise that, under the ruleset we are using, suicide is permitted.
>> Therefore its board-update routine fails.  It knows that its opponent
>> has moved, and it knows that it does not know the current position.  It
>> would like to ask the server to send the current position.
>
>Sorry, but I can't take this seriously. If your board update routine
>fails, just fix it. As long as you trust the controller to send legal
>moves, it's well defined how the board will look. The same board
>update logic can be used for all rulesets. If you don't agree about
>the legality, complain in a logfile. If you don't trust the controller
>to send legal moves, you have a problem that is hardly properly solved
>by asking it for a different board state description.

I agree that the server knows better than me about the legality.  I 
trust the server to make legal moves.  I just might not know how to 
update the board state after a move I had not realised was possible.

In 1998, running the Ing Cup, I tested all the entrants for their 
behaviour when someone played a suicide move at them.  Many Faces put up 
a polite dialog box explaining that this was an illegal move.  Go++ was 
more amusing:  it allowed the move (which you would approve) but left 
the suicided stones on the board, where they became almost unkillable, 
it could not capture them by removing their last liberty as they didn't 
have one, the only way to lose them was to capture exactly one of their 
surrounding stones, in a perverted kind of snapback.  I would have 
preferred these programs to have been able to respond "wtf is going on, 
please tell me the current board state".

>>     (2)  As (1), but with a move that my bot thinks, wrongly, is
>> forbidden by superko.
>
>Same as (1).
>
>>     (3)  My bot, or the platform on which it is running, has had a
>> serious accident.  I have relaunched my bot and it wants to resume its
>> game but has no knowledge of the position.
>
>It's standard practice for the controller to send "play" commands up
>to the point of resumption. If the engine has to be restarted the
>controller knows that it has lost state, there's no need for the
>engine to ask. KgsGtp knows how to do this, the CGOS client knows how
>to do this.

It's good to know that.

>> If my understanding of the GTP spec at
>> http://www.lysator.liu.se/~gunnar/gtp/gtp2-spec-draft2/gtp2-spec.html is
>> correct, it is not possible for a bot to say "please tell me the
>> position".  Should it be possible?
>
>No it shouldn't. GTP is designed to make it easy for engine authors to
>implement what the engine needs to play a game. For a go server
>protocol it can be useful to have methods to negotiate komi, negotiate
>opponents, ask the server all kinds of questions, and so on, but this
>is out of scope for GTP.
>
>> A similar question applies to time.  When I play in a tournament, I am
>> allowed to look at my clock to find out how much time I have left.  I am
>> surprised to find that GTP provides no way for a bot to ask this. (Maybe
>> I am misunderstanding the spec.  I see that there are commands
>> 'time_settings' and 'time-left' that the server can use to inform the
>> bot of its remaining time, but I can find no indication of when, if
>> ever, these commands will be issued.)
>
>For a game with time controls the controller is expected to send
>time_left commands once per move to keep the engine informed about the
>time situation. While thinking on a move the engine is expected to
>keep track of time by itself.

I see.  And that is up to the controller, so it's not mentioned in the 
GTP spec.

>By the way, if this has anything to do with KGS, the real problem
>there is that people who want to do advanced things with bots cannot
>modify kgsGtp, nor speak the server protocol themselves, since those
>are both proprietary.
>
>And just to be clear, the normal mode of communication between a bot
>and a server, if GTP is involved, is
>
>Server <---server protocol---> Client <---GTP---> Engine

>The server protocol and GTP have very different roles, capabilities,
>and complexities. In some cases the server protocol can be near GTP in
>complexity (CGOS), in some cases the server protocol is not available
>(KGS), and in some cases the server protocol can be hugely complex
>(IGS and NNGS clones). For the best result the client should have open
>code and be very configurable.

Thank you for the explanations.

Nick

>/Gunnar
>_______________________________________________
>computer-go mailing list
>computer-go at computer-go.org
>http://www.computer-go.org/mailman/listinfo/computer-go/

-- 
Nick Wedd    nick at maproom.co.uk