A van Kessel wrote:
> > ... , but I consider the draft 2 of GTP
> > version 2 as the current version.
>
> IIRC gunnar backed out some "tournament" (sp?) commands,
> because there were too much fuzzy semantics involved, which
> he wanted to be settled out.
>
> IMO gtp is not ready for "automated" tournament use.
> too many things regarding starting up games, refereeing
> (communication with supervisor pgm) are not taken care of.
> This will effectively lead to "ad-hoc" modification of
> driver programs, operator intervention, or worse: program
> failure.
I can see only one thing that is not taken care of: rule set
(chinese/japanese/whatever) as long as you speak about GTP 2.
Everything else: handicaps, komi, timing (Canadian overtime)
is implemented. There is no support for say Japanese byo-yomi,
but I doubt any program supports it anyway and that it will be
used in tournaments, at least in the nearest future.
In any case, information about rule set can be passed via
command line. And even if it is not, difference between chinese
and japanese scoring is so insignificant that it hardly will
influence playing style of any engine.
Rules make a huge difference. With Chinese rules there is no problem with
tryingAbout referee. If it is another engine (beleived to score
correctly often enough), it can be communicated via GTP as
well. If it is human, I wonder how you imagine communication
with him built into GTP? In the latter case, reviewing of the
games is necessary anyway.
And I suggest that you try and implement GTP 2 (required
commands plus tournament subset). Then take a twogtp script
from GNU Go distribution (either Perl, Python or Pike one,
whichever you prefer) and play against GNU Go. I'm sure
you'll have no problems.
What about those of use with Windows programs? If there a referee that