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. > (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. > 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. 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. /Gunnar _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
