If more than one venue is mandatory I probably won't be able to join, since I want to spend my limited programming time making the engine stronger, not programming multiple time controls. Please allow me to play with just a singe time limit without changing my cgos interface code.
David From: computer-go-boun...@computer-go.org [mailto:computer-go-boun...@computer-go.org] On Behalf Of Don Dailey Sent: Monday, June 15, 2009 7:02 PM To: computer-go Subject: Re: [computer-go] New CGOS - need your thoughts. On Mon, Jun 15, 2009 at 9:43 PM, Jason House <jason.james.ho...@gmail.com> wrote: Given all the negative reaction to nested time control, I have to say I like it. The pool won't be diluted as long as there's an obvious main venue. A good compromise might be to have only 2 venues, one such as David suggested and another one that is quite a bit faster. Another possibility is to make BOTH venues mandatory - but my fear is that some programs may not be able to play fast enough and would always time out. Or they may not implement a proper time control algorithm and thus would not be able to adapt to 2 different time controls without being reinitialized with different parameters. Sent from my iPhone On Jun 15, 2009, at 7:20 PM, Don Dailey <dailey....@gmail.com> wrote: I've been working on the new server and I'm almost at the point where I can think about time controls - and since this is primarily for developers, I would like to get your thoughts. First, a brief explanation of how the time control works. When the client starts up it will inform the server of which venues it is willing to play in. It must choose an available boardsize and then any of N different time controls. Initially, N will probably be 2 or 3. For each board size, a time control is called a "venue." Let's assume there are 3 venues for boardsize 9x9. The time control for each venue will be significantly different from the others. One will be very fast, one will be very slow and there will be one in between. Each time control will be in sync with the others and the process will be recursive. So the basic scheduling algorithm is to NOT start a new round for a given venue until any players who have registered to play in this venue and are currently playing in FASTER venues are available for scheduling. In addition to this, new rounds are not scheduled for any particular venue as long as the next slower venue is stalled waiting for these faster venues to complete. I hope this idea allows more choice and keeps players busy a greater percentage of the time by allowing them to fill dead space with fast games. Each bot can choose which venues to play in. If you only want to play fast games, then you can. Now the questions I pose to you are these: How many venues for each boardsize? (two, three, more?) What time controls should they be? It's almost certainly the case that certain combinations of time control venues will work together better than others. There will always be the issue of waiting for games to complete and in fact this may make the problem a bit worse for those programs that only want to play in the longest venue. I suggest that each venue is spaced at least a factor of 2 apart in time. For instance 1 minute, 2 minutes, 4 minutes, etc. My own suggestion for 9x9 is to have 3 venues of 1 minute, 5 minutes and 15 minutes per game per player. It's also not too late to change our minds and not have venues if we think the disadvantages outweigh the advantages. - Don _______________________________________________ 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/
