This is a long and rambling posting. As I write it, I am confused about
some of the issues. So if you cannot follow it, it is my fault, not
yours: I have misunderstood something, or explained it badly, or both.
At present, in the Computer Go Tournaments that I run on KGS, the
game-end procedure is as follows.
(1.) The game continues until both bots pass on successive turns.
(2.) Each bot makes an assertion about which stones are alive.
(3a.) If they agree, the game is counted by KGS scoring software, and
the result automatically goes through to the KGS tournament software.
(3b.) If they disagree, the tournament organiser (which so far has
always been myself) decides which groups are alive, counts the score,
and presses the big button on his tournEditor program. This overrides
any opinions that the bots and the KGS scoring software may have, and is
accepted by the KGS tournament software.
Now, this is obviously not ideal. I don't mind the work involved, it is
not difficult. But it is possible that some day a position will arise
which is difficult to score, and I will get it wrong. I would prefer to
avoid this.
William Shubert (wms), who runs KGS, has proposed an alternative scheme.
As I understand it, it goes like this:
(1, 2, 3a.) as above.
(3b.) If they disagree, KGS issues a command to each of the, saying,
"sorry, you are invited to carry on playing. And now, any stones still
on the board after successive passes will be counted as alive." It
decides (I don't know how) which one should move next, and tells it.
(4.) The game continues until both bots pass on successive turns.
(5.) The KGS scoring software counts the score assuming that all
stones still on the board are alive, and the result automatically goes
through to the KGS tournament software.
This does not happen yet, because
(A.) The kgsGtp interface, through which all bots connect to KGS,
does not yet support the passing of this command to the bots.
(B.) No bots yet respond appropriately when this command is issued.
Now, (A.) has been addressed. wms has provided me with a version of
kgsGtp.jar which _does_ handle the "kgs-genmove_cleanup" command. It is
a beta version, and has not yet been tested. I am not making it
generally available, because I fear that this might cause confusion.
However I will email it to anyone who explicitly requests it and appears
to understand why he wants it, and that it is a currently unsupported
beta version.
This version of kgsGtp.jar needs testing. Peter McKenzie and "Aloril"
have both agreed to help with the testing, connecting their bots to the
beta version of the KGS server, to play in a mini-tournament for test
purposes. I can also cause GNU Go to take part. Other volunteers will
be most welcome.
Note that what is being tested here, as far as wms and I are
concerned, is the protocol, and the new version of kgsGtp.jar which
should handle it. If Peter and Aloril, and others, want to use the
opportunity to also test various versions of their bots, which handle or
fail to handle the "kgs-genmove_cleanup" command in various ways, that
is fine with us.
A snag with this is that I do not have the power to create a
tournament on the beta server, as I do on the main server. wms will
have to create the tournament and enter the bots that are to play in it.
And he is, I understand, particularly busy at present, as well as being
asleep during the hours when us Europeans decide it would be good to
have a tournament soon. No doubt we will soon find a way of getting
round this (although not until August, I am off to Prague soon).
A more serious problem, in my opinion, is that the bots that enter these
tournaments do not support this game-end protocol, or do not support it
correctly. And I don't think it is going to be easy to get them to
support it. While I have huge respect for the ability of computer Go
programmers to accomplish very difficult tasks, I am somewhat sceptical
about the ability of some to perform mundane tasks correctly. If you
have read my tournament reports at
http://www.weddslist.com/kgs/past/index.html you will understand why I
am sceptical.
Now, what will happen if I require support for the game-end
protocol, and some bots which enter the next tournament fail to
implement it, or fail to do so correctly? As I understand it, here is
what will happen if one implements the game-end protocol correctly and
the other doesn't:
(1, 2, 3a.) as above.
(3b.) If they disagree, the "kgs-genmove_cleanup" is issued. The
well-behaved bot then sets about capturing all its opponent's dead
stones, while the old-style bot passes, or fails to respond, or does
something unhelpful. Eventually, the game probably gets awarded to the
well-behaved bot.
As tournament organiser, I then have two options. I can accept the
result and let the well-behaved bot keep its win. This has the
advantage that it will act as an incentive to programmers to implement
the game-end protocol correctly. But it will also annoy people who have
so far failed to implement it correctly, maybe to the extent that they
stop taking part.
Alternatively, I can override the result manually, as I do at
present. This will be slightly harder than it is now, as I will have to
step back through the game to the point where the first two successive
passes were made.
This whole issue has already been debated here at length, in a thread
titled "Re: [computer-go] Third KGS tournament: game-end protocol". I
started by being opposed to making support for the game-end protocol
compulsory, wanting to introduce it gradually and voluntarily, or not at
all. However I was persuaded by Don Dailey that it was a good thing and
its support should be made compulsory (or rather, the rules changed so
that bots not supporting it were very likely to lose).
Don then totally confused me with this exchange:
NW> I have been persuaded by posters to this list that I should
NW> eventually require bots playing in KGS computer Go tournaments to
NW> support the game-end protocol.
DD> I think there is a misunderstanding here. This should not be a
DD> requirement.
DD> According the rules of Go, a player can pass whenever he wants to.
DD> kgs-genmove_cleanup is just "genmove" with a request attached to it.
DD> The request is, "please try to capture your opponents dead stones."
DD> It is up to the program whether it wants to honor this request,
DD> because it is not illegal to pass.
DD> Therefore the kgs-genmove_protocol command is a request at best, not
DD> an enforcable demand (according to the rules of GO anyway.)
DD> That's why this whole business of having a human step in to clean up
DD> the results is so unatural and ugly (in my opinion.)
Don seems to me, here, to start by saying that support for the game-end
protocol should not be a requirement; and to end by wanting to get rid
of the human intervention step (which is necessary if the game-end
protocol is not supported).
Nick