using gen_move to place handicap stones seems unreasonable to me when there is a command intended for that purpose. The point of GTP is to make it easy to implement the protocol. Anything that either breaks programs that are written to the specification (as in using gen_move instead of free_place_handicap) or makes GTP more complicated works. "Implicit" handicaps are rediculous. Send it as the komi. The following steps will always make it clear to any bot that implements GTP correctly what they should do:
1) send a komi 2) use the handicap functions built into GTP if they are supported 3) else, use gen_move 4) send play_move to other client 5) play out the game until both players pass 6) ask engines what stones are dead 7) if they disagree, keep playing if they support that 8) when both players pass again, ask them both to score the game 9) programs can score however they want, but it should be consistent with the following: black wins if (# of black stones on board + # of spaces black has as territory) > (komi + # of white stones on board + # of spaces white has as territory) chinese rules are consistent with this approach as are japanese rules if both players pass an equal number of times. Further, the komi should include all compensation given because then programs don't need to be programmed to support various different sets of compensation. kgsGTP should either have a layer put on top or itself altered so that komi includes all compensation. This was a mistake imho in how GTP talks with KGS and it should be fixed. These are just my thoughts. - Nick On 12/29/06, Weston Markham <[EMAIL PROTECTED]> wrote:
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/
_______________________________________________ computer-go mailing list computer-go@computer-go.org http://www.computer-go.org/mailman/listinfo/computer-go/
