I just finished up a GTP client for KGS. With it, any GTP go engine can connect to KGS and play there. This has been a problem for KGS for a long time - one of the big advantages that IGS and NNGS have with their open protocol is of course that people could easily write a GTP (or any other kind of client for it). Now that I've finally written the GTP client for KGS, I wish I'd done it sooner - it was much easier than I'd expected.
I've been using GnuGo to test with. About 20 games have been played in the past 24 hours, so it seems that the major bugs are gone. I have not tested with any other engine, so problems may show up due to small variations in the way that GTP is used.
If you have a GTP go engine, please go to http://www.igoweb.org/~wms/upload/ and try downloading it. I'd be really interested in what people think of it.
From: "William M. Shubert" wms@igoweb.org Date: 30 Dec 2003 23:24:13 -0800
I just finished up a GTP client for KGS. With it, any GTP go engine can connect to KGS and play there. This has been a problem for KGS for a long time - one of the big advantages that IGS and NNGS have with their open protocol is of course that people could easily write a GTP (or any other kind of client for it). Now that I've finally written the GTP client for KGS, I wish I'd done it sooner - it was much easier than I'd expected.
I've been using GnuGo to test with. About 20 games have been played in the past 24 hours, so it seems that the major bugs are gone. I have not tested with any other engine, so problems may show up due to small variations in the way that GTP is used.
William,
It worked the very first time for me. I have never compared my GTP implementation against any other piece of software so this surprises me to a certain extent.
Very nice. I was hoping you would do something like this eventually.
It does crash at the end of some games. I think it's because my engine doesn't know 'final_status_list dead' But the other unkonwn commands do not crash it, so you might have a minor bug here.
I am now moitivated to implement a few more GTP commands since my engine only recognizes a few.
- Don
Here is a log of where it crashed in case you are interested:
FINEST: Response to "time_left w 185 0": = unknown command Dec 31, 2003 12:04:47 PM V d FINEST: Sending queued GTP command: final_status_list dead Dec 31, 2003 12:04:47 PM V d FINEST: Response to "final_status_list dead": = unknown command Dec 31, 2003 12:04:47 PM V f SEVERE: Fatal error in GTP reader thread java.lang.RuntimeException: Cannot recognize vertex "unknown" that came from engine. at V.a(kgsgtp:384) at l.b(kgsgtp:535) at l.a(kgsgtp:37) at D.a(kgsgtp:447) at V.d(kgsgtp:349) at V.f(kgsgtp:222) at V.a(kgsgtp:33) at y.run(kgsgtp:125) at java.lang.Thread.run(Thread.java:534)
Bill wrote:
I just finished up a GTP client for KGS. With it, any GTP go engine can connect to KGS and play there. This has been a problem for KGS for a long time - one of the big advantages that IGS and NNGS have with their open protocol is of course that people could easily write a GTP (or any other kind of client for it). Now that I've finally written the GTP client for KGS, I wish I'd done it sooner - it was much easier than I'd expected.
Nice.
If you have a GTP go engine, please go to http://www.igoweb.org/~wms/upload/ and try downloading it. I'd be really interested in what people think of it.
I haven't tried running it yet but I can give some comments on the documentation.
| undo | If your engine supports this command, you will get it as | normal. If your engine does not list undo as a response to | list_commands, then any undos that your opponents request will | be denied, so this command is optional from kgsGtp's point of | view.
With some extra work undo can be simulated by clear_board + play commands. On the other hand, allowing undo at all has potential cheating problems. GNU Go on NNGS never accepts any undo, for good and for bad. Even if the engine supports undo it would be good to have a config option not to accept undos.
| final_status_list | After the game enters scoring kgsGtp will send this command. If | you return a list of dead stones, then kgsGtp will mark those | on the board. If you return an error, then kgsGtp will not mark | any stones dead and your opponent will have to do that instead.
Do you ever ask for seki stones? I seem to recall that KGS tries to identify such when Japanese rules are used.
| clear_board | Used after each game to start over. If you don't support this, | then you will be limited to one game for each time you run | kgsGtp.
If you don't already do that, clear_board should be issued also at the start of the first game. Although many engines will start with an empty board that is not guaranteed.
| * Free games only. Right now it has no way to argue over dead stones | at the end of the game, so if your opponent changes the stones | that you mark dead, kgsGtp simply accepts the changes. This makes | it very easy to cheat a kgsGtp player, so only free games are | allowed right now.
GNU Go on NNGS insists on adjourning the game if the opponent does not agree on dead stones. The opponent is left with the options to a) accept GNU Go's judgment, b) resign, or c) complain to me that GNU Go gets it wrong (and then I either resign the game or fix the bug, or both). The latter happens occasionally but we're talking of far less than 1% of the games.
This is probably not practical for kgsGTP and the understanding of life and death status will of course vary significantly between different engines. What could be interesting is an option to ask another engine, e.g. GNU Go, for the final status.
| * Engine cannot refuse game settings. If somebody sets up a game | that is 9×9 and your engine only supports 19×19, all you can do is | resign immediately. Eventually I hope to add a kgs-specific | command that asks the engine if the settings are OK, then accepts | the game only if it agrees.
In the specific case of board size, kgsGTP should at least check whether boardsize returns an error before accepting the game.
| * No way to resume games.
I assume there are no principal difficulties implementing this and just a question of time.
/Gunnar