Re: [computer-go] re: Computer Go tournament thoughts

[Evan Daniel <evanbd@xxxxxxxxx>]

On Tue, 15 Feb 2005 00:55:30 -0800 (PST), steve uurtamo
<apoxonpoo@xxxxxxxxxxxxxxxxx> wrote:
> > Lets separate the issues of running formal
> > tournaments from
> > having a convenient place to play practice games
> > as part of
> > the develepment process.
> 
> well said.
> 
> i'm happy to write some code.  my thinking is
> that this isn't a big project, except:
> 
> a) it's not useful unless people will use it.
> b) there are a few technical points that i'm
>    curious about, mostly with respect to a)
> 
>   i) will most people's* code "pass"?  this is related
>      to my earlier question about finishing games.
>      if not, i'm open to suggestions about how to end
>      games.

Mine can, though it has occasionally done so from less-than-opportune
positions ;)

> 
>  ii) can most people* write/are most people willing
>      to write simple client socket code and/or link
>      against client socket libraries that i have no
>      interest in supporting beyond whatever OS they're
>      written for?  if not, something already written
>      will have to get used. (even if it's Expect).

My favorite would be if there was a cross-platform client side GTP
bridge available.  I may be available to help write such depending
upon time constraints.  If such isn't available, I will probably write
one, assuming the relevant protocol is simple and sane enough.  Might
take a while for me to get to that, though.

> 
> iii) can people* live with one ruleset, one timeset,
>      playing whomever happens to be in the queue next
>      as opposed to setting up a tournament-style
>      challenge/response system, playing fair, being
>      nice and generally not requiring 10 miles of
>      code to try to guarantee that they're not
>      cheating in some way?  (not that there's any
>      way to know, of course).

Sure, provided that the timeset is sufficiently long and that 9x9
games are supported.  I would want at least 45 mins absolute time,
preferably 60 or more.  My preference would be to support flexible
times and sizes, or maybe just have a few different standard settings
and have each program allow / disallow each one.

I'm fine with the queue idea, though some code to try to ensure
pairing variation would be a good thing.

I have no particular need for anti-cheating measures; I really doubt
it will be a problem.

> 
> my predilection would be to implement this
> minimally with hard-coded options on the server
> side and modify it later only if there were major
> problems with using it.  getting something up
> and running that people could connect to sounds
> more useful in the short term than debating (too
> much) the merits of features that don't yet exist.

I'm definitely agreed on that point, though I'd need at a minimum 9x9
and long time limits in order to play.

Evan Daniel
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/