As someone who might write programs that will play on the server, I
would like to put my 2 cents in:
As long as the final score is simply the difference in the number of
intersections controlled by each of the players, adjusted by komi,
then I will be happy. Whatever compensation for the handicap stones
is decided upon, it should be accounted for in the komi value sent by
the server, which should be exactly the komi value that is used to
adjust the final Tromp-Taylor score. (This is clearly what Dave
Hillis has in mind. Am I correct in inferring that this is also what
Don Dailey has in mind, but with no compensation for the handicap
stones?)
If I understand correctly, kgsGtp relies on some mechanism where the
compensation is implicit; so, either the komi value is not specified
by the server, or the komi value that is used to adjust the final
score is not the same as the value that is sent by the server. (I am
not aware which is the case, since I have never used kgsGtp.) This
might be incompatible with the mechanism that I describe above. If
that is the case, it would be nice to have both of the GTP controller
programs would have special commands (say, "kgs_rules" and/or
"cgos_rules") that would be sent to the programs, in order to
explicitly inform them of the rules that are in effect. (These could
take version numbers of the rule sets, as arguments, in order to allow
for future changes to the rules.)
Aside from this, I have one very minor complaint about simply asking
one player for multiple consecutive moves. In my opinion, the player
should know ahead of time how many consecutive moves will be
requested. The proposed method should only be used as a fallback, if
there are programs that we would like to participate on CGOS, but for
some reason these cannot be easily made to provide a
place_free_handicap command. Even in that event, I would personally
prefer to simply wrap those programs behind adapter programs that will
automatically perform the translation of place_free_handicap to
multiple genmove commands. (Does gtpadapter, available in gogui,
already do it?)
This latter point is minor. If I don't get what I want, it really
won't bother me much. However, at the moment it seems to me that it
should be such a small burden on developers to support the command,
that it is worthwhile to ask.
Weston
On 12/29/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
This seems clean and reasonable to me. (Or you could just as easily
have the server do the adjustment and set Komi to 3.5; that would also be
consistent with TT rules). If my bot sees 2 black moves in a row, it can
figure out it's in a handicap game.
A bigger question to me is, how large a handicap might be encountered.
Will we see Mogo playing Random with 100 stone handicap, or will excessive
mismatches be disallowed altogether?
Dave Hillis
-----Original Message-----
From: [EMAIL PROTECTED]
On Fri, 2006-
....
If your program is taking black you would get someting
like this from the GTP channel:
clear_board
komi 0.5
boardsize 19
genmove black
genmove black
genmove black
for a 3 stone handicap game. The opponent would get the
corresponding consecutive play commands.
I know this won't make everyone happy - but I believe it is
more in the spirit of a simple logical rule-set and is what
drew me to Tromp/Taylor rules in the first place. Might as
well stick close to it.
We can call this rule-set "CGOS" - which is exactly tromp/taylor
without suicide.
- Don
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
________________________________
Check Out the new free AIM(R) Mail -- 2 GB of storage and industry-leading
spam and email virus protection.
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
_______________________________________________
computer-go mailing list
computer-go@computer-go.org
http://www.computer-go.org/mailman/listinfo/computer-go/
