In previous KGS bot tournaments, players including EricaBot and housebot have been losing won games, through no fault of their own, because they do not support the game end protocol. As I wrote in my report of the September tournament:
EricaBot obtained a clearly won game against GnuGoAl. But the status of two stones was disputed. The stones belonged to EricaBot and were clearly dead, but EricaBot did not know how to say so, so the server marked them as alive on its behalf. EricaBot then did not know how to handle the resolution phase, timed out, and lost the game. This is not the way KGS was meant to work. I sent an email to William Shubert 'wms', the programmer of KGS, which I quote below. It seems I sent it at a good time for him, because he is implementing "PROPOSAL 1" below. He emailed me: "I put in a fix. Untested. Well, let's cross our fingers; but it looks simple enough, now the clients who don't support the feature will just accept their opponent's dead stone lists in tournaments... It should get released tomorrow [October 1st] if all goes well." So, once this server build gets installed, which should be before this Sunday's tournament, here is what ought to happen after both players pass. If they agree on all the dead stones, the game is scored accordingly. If they disagree on any dead stones, the game is resumed. If one of them makes a claim about dead stones and the other doesn't, the server believes the claim and scores accordingly. If neither of them makes a claim about dead stones, the server treats all stones on the board as alive, and scores accordingly. We'll see how it goes on Sunday. I think this must be an improvement. Nick >Dear Bill, > >Thank you for the support KGS continues to give to bot >tournaments. We had a particularly successful one last Sunday, >with a strong attendance: you can read my report at >http://www.weddslist.com/kgs/past/51/index.html > >Some of the results in the tournament, involving the bots >'housebot' and 'EricaBot', reminded me that there is a small >change you could make to the server code, to make its support for >bot/bot games even better. The problem arises when a bot does not >support the clean-up protocol at the game end. The intention was >that a bot not supporting this protocol would have a fair chance >of winning a game, unless there was a status dispute at the game >end. But this is not what happens the way things are: such a bot >loses many of its games undeservedly, as described below. > >Here is what happens at present. Suppose White is a strong player >that does not support clean-up, and Black is a weak player that >does support clean-up. White secures more than half the >territory; and as it knows it does not support clean-up, it >tidily captures all the black stones inside its territory before >passing. There is a dead white stone inside Black's territory. > >After both players pass, Black submits a dead-stone list listing >the one dead stone. White does not know how to submit a dead- >stone list, and does nothing. The server then acts on White's >behalf and marks the dead white stone as alive. The resumption >starts. Black captures the dead stone. White does not know what >it is meant to be doing, does nothing, times out, and loses. > >I have two proposals to make the clean-up give fairer results than >this, and allow White to win the game described above. > >PROPOSAL 1. >If the server receives a dead-stone list from only one player, >then the server believes that player, and counts, with no >resumption. (If it receives a dead-stone list from neither player, >then the server treats all stones as alive, and counts with no >resumption). > >PROPOSAL 2. >If, during the clean-up phase, a player times out, then the server >treats that player as passing for the rest of the clean-up. > >I hope that one of these changes to the server will be simple to >make. No change to the user interface is involved. It is sad to >see a strong bot like EricaBot lose won games just because it does >not support clean-up, when such support was meant to be voluntary. > >Best wishes, >Nick > -- Nick Wedd n...@maproom.co.uk _______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
