[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [computer-go] Third KGS tournament: game-end protocol
On Tue, 2005-06-07 at 23:23 +0200, Gunnar FarnebXck wrote:
> Nick wrote:
> > There is a weakness in the kgsGtp program. When it disagrees with its
> > opponent about the final score of the game, it will not budge until
> > either the opponent resumes play, or agrees with it. This means that
> > when there is a score disagreement between two computer programs, they
> > will sit and argue until an admin kills the game.
> >
> > Fixing this is harder than it sounds. Once the TD (Nick) has set the
> > winner in the tournament system, there is no point in continuing the
> > argument [...]
>
> Was there any point in continuing the argument before the winner was
> set? If we assume that the programs are mostly deterministic in this
> phase of the game, there is no chance to get anywhere if they disagree
> about status and neither manages to resume playing right away.
>
> Would it be difficult for the server to detect this situation and
> automatically kill the game?
It would be difficult, both because the server doesn't really track
information at the level that counts as an argument and because just
knowing that the argument is happening doesn't help much in actually
solving the argument. The server accepts requests to mark stones alive
and/or dead and informs your opponent of the change you made. When it
sees several changes to a group of stones, it doesn't know whether this
is an "argument" or the correction to a mistake. Furthermore, once the
server does decide that it is two computer programs disagreeing, what is
it to do? It can't mark the score one way or the other because it
doesn't know which of the disagreeing programs is correct, and there is
currently no way for any human other than the players to set the score
of a game. (Again, notice that when Nick sets the winner of a tournament
game, this doesn't actually change the score of the game on KGS - it
simply marks the tournament database by saying that one side or the
other forfeited, and the "real" game outcome should be ignored).
> While I'm writing I also have a tournament related wishlist item,
> which I have no idea how difficult it would be to implement. Currently
> you have to restart kgsGtp with appropriate options to accept
> tournament games and decline other games before a tournament starts,
> and afterwards restart kgsGtp with reverted options to resume playing
> normal games. This seems kind of unnecessary. It would be more
> convenient if the server simply adjourned any ongoing game (with a
> message explaining that the bot will be occupied by a tournament)
> right before the start of each tournament game.
Yes, this would mean you didn't have to restart your program, but I
didn't do it because in the downtime between rounds there would be a
good chance that people would (not knowing about the tournament) start
games with the robots, then get them cut off when the next round starts.
By forcing people to set their robots to "only play in tournament
games," I was trying to make sure that this didn't happen.
> /Gunnar
> _______________________________________________
> computer-go mailing list
> computer-go@xxxxxxxxxxxxxxxxx
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/