[ List Earliest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]
Comments/Ratings for a Single Item
Game Courier Tournament #1. A multi-variant tournament played on Game Courier.[All Comments] [Add Comment or Rating]I would like to add an 'excellent' for the proposed ability to clock games in Game Courier!
I would vote for time controls on the order of one move per day, and maybe a bit on the lenient side of that. On any given day, I shouldn't have much trouble making one move in each game, but making two moves or more would require my opponent and me to be online at roughly the same time. With the variety of schedules and time zones represented here, I don't think we can count on that happening in every game. Aside from the question of exactly how much time should be allowed, I think there is a problem with the idea of a time control as simple as 30 (or 60, or whatever) days. Suppose that my opponent and I are able to make one move per day, but our schedules work out in such a way that I move at 12:00 and he moves at 18:00. Then my clock would lose 18 hours each day, and his only six, even though we are both playing at the same rate. This hardly seems fair. I think a better idea would be to add a time increment to each player's clock with each move (maybe an initial time allotment of 15 days plus an increment of one day per move, just to pull some numbers out of a hat) or else a version of the system of time units used in last year's Multivariant Tournament.
Some of us may have some problems for make a move certain days, but it can be compensated with more moves other day, if both players agree. The idea of clocks is a good one, but it may need some adjusts to reallity, I think.
Thomas makes a good point. Even though both players might make moves at 24-hour intervals, the time that each chooses to move may favor one over the other. This would be unfair to one of the players. So the method I proposed for enforcing time controls is not a good one. The main goal behind time controls is to get games to finish in a timely manner, and a secondary goal is to get all games to finish by a specific deadline. The method I proposed meets both these goals, but it's unfair. The method used in the last multivariant tournament meets the main goal but does not meet the secondary goal. I suspect that there may be no fair method that meets the secondary goal, but if anyone can think of one, I would be pleased to hear it. I like the idea behind the one used in the last tournament, but it strikes me as being too liberal. Let me suggest this in its place. Each move that takes more than 72 hours costs a time unit plus one more time unit for each 24 hours beyond the initial 72, and a player would forfeit a game if he ran out of time units. I chose 72 hours, because it accomodates the person who plays from work and doesn't have access to the web over the weekend. As for the initial number of time units, 14 might be a good choice. One possible modification to this method would be to reward players for picking up the pace. For example, a player might get an extra point for making at least seven moves within a week's time. In that case, it might be okay to initially allot fewer time units to each player. I'm really not familiar with what other PBM systems do for timing tournaments. If there are some good methods I should know about, please report them here.
Given that the timing method I previously proposed was unfair, it has now become a moot point whether players are given 30 days or 60 days. The best timing method seems to be one that expects players to move within a particular time frame, and such a method is open-ended regarding the total time allowed for a game. Instead of allowing as much as 72 hours to make a move, as I previously suggested, something like 28 hours could work if combined with rewards for occasionally picking up the pace. In that way, people could make up for long interruptions by playing more quickly at other times. However, I'm thinking that this could be open to abuse by players who aren't subject to the same interruptions of time. For example, one player may be unable to play on the weekend, and the other player could take advantage of this by refusing to cooperate in picking up the pace during the week. This might be avoided by giving global time unit rewards that can be used in any game, but that may be too difficult to automate, and it would work best if it were automated. So I'm open to other suggestions how to handle time limits.
A nice simple formula for time control of the tournament: (maximum time length of tournament)/(maximum number of moves allowed in the particular game)=(maximum alloted response time) (number of moves allowed)=(total number of full turns allowed)*(number of players in the particular game) If a player fails to respond within the alloted time, they would automatically forfeit the game regardless of their current position or material gain. You've got to be cruel.
I agree that time limits are needed. Excessively liberal limits would lead to neglect. However, if the time limits are too rigid we may get few registrants. This kind of tournament does not attract a lot of players to start with. 14 voters is by far the best response the CVP has had for a tournament -- let's keep it! Besides that, I would venture to say that with rigid limits, the tournament might get lot of forfeitures, particularly as the tournament gets into its second or third month and longer. There is also the issue of enforcement, who is going to call a forfeit? Here's a thought, once the registrations are in offer various time limit alternatives, such as those suggested in these comments, to the registrants for selection by voting.
Okay, let's be nice. You could allow players to accumulate time during the tournament. Any time that they do not use to make a move would be alloted for their discretion in the subsequent moves. So a player who made short early moves at the beginning of the game could then use that excess time with later moves.
Whatever method is used for time controls, it will be an automated method. I will not be looking over each game making individual judgements on whether time limits have been exceeded. Instead, I will just program whatever method gets used into Game Courier before the tournament begins. As you make suggestions for how to handle time limits, keep this in mind.
I've since had more thoughts on how time limits could be handled. Generally, the idea behind the method used in the last tournament was a good one, but that particular method was designed for manual enforcement in games that were played strictly by email. At that time, the games in the tournament were played mainly through the old PBM system or by mailing ZSG files back and forth. Because of this, it made sense to use gross measurements of excess time. Since all games in this tournament will be played with Game Courier, which logs all games and doesn't depend upon email, it is possible to use precise measurements of time. Taking into consideration matters of fairness raised in previous comments, here is what I now propose. Each player will begin with a buffer of extra time equal to 24 days but measured in seconds, a total of 2073600 seconds. After your opponent moves, you will have a grace period of 24 hours, precisely 86400 seconds, to make your next move without any time penalty. If you take more than 24 hours to make your next move, each second you take beyond the free 24 hours will be subtracted from your buffer of extra time. If you use up your buffer of extra time, then you will automatically lose the game. Here is my rationale for this method. First, it encourages, without strictly enforcing, a pace of at least one move per day. As long as you check your games at the same time each day, making moves in any for which it is your turn, you should be able to play indefinately without incurring any time penalities. Second, it accomodates people who can't play on weekends by giving you enough extra time to play only on week days for a period of at least 12 weeks. If you make your moves at the same time Monday through Friday, there would be 72 hours between your Friday move and your Monday move. Your cost for skipping the weekend would be 72 hours minus the free 24 hours and whatever interval there was between your Friday move and your opponent's next move. So skipping the weekend would normally cost something close to but under 48 hours of time. A buffer of 24 days should also be ample for people who normally move regularly but have situtations that take them away from the web for a while, such as vacations, lots of homework for students, lots of grading for teachers, hospital stays, or whatever. It's important to allow for such things, but it's also important to set limits on how long anyone can hold up the tournament. An alternative way of doing this would be to initially offer a smaller buffer of extra time, then to reward players with extra hours of time each time they made a move within the grace period. For the sake of fairness, this reward would have to be the same amount no matter how late into the grace period a player moved. This may encourage players to quicken the pace when they are able.
Another matter we should discuss is the entrance fee. In the last tournament, it was $5.00. Although a small entrance fee may discourage fewer people from entering, a larger entrance fee would allow for bigger prizes, and that might encourage more people. What would you think about a $10.00 entrance fee?
David Howe wrote on Wed, Jan 21, 2004 02:07 AM UTC:I dropped the ball on that one. We have $25 from the entrance fees, and I'll pony up another $75. That makes $100 in prize money. Mike Howe, the 1st place winner will receive $70, John Lawson, the second place winner will receive $30. Both will receive award certificates. I apologize for dropping the ball on this. Hopefully my lack of action on this issue won't discourage others from joining in on other tournaments.
The kind of thing Michael proposes would be fine with me. David shouldn't have to kick in his own money.
I also think that a qualifying round of eight games is better than two qualifying rounds of four games, because a) it insures every player will play at least eight games b) it gives the players more flexibility for entering each move, say five days before beginning to consume time units c) all games retain full weight (in the proposed scheme, players are induced to keep their favorite games for the second round, when the qualifying spots will be much harder to secure, especially if there are nine or ten entrants).
Should I make an eight-game minimum a standard part of the tournament no matter how many people enter? What do the rest of you think? With nine or more players, it is easy to do this. Just loop the list of players, and have each person play the four before him and the four after him. With eight or fewer people, only some numbers easily allow eight games apiece. With two entries, the two players could play each other eight times. With three entries, each player could play each of the others four times. With five entries, each player can play every other player twice for a total of eight games. But for four, six, seven, or eight entries, a single round of eight games would not be as doable. With four players, everyone could play everyone else three times for a total of nine games. With six players, everyone could play everyone else twice for a total of ten games. With seven players, it might be better to have one round of six games, eliminate some players, then have another round. With eight players, it might be best to have a first round of seven games.
With the help of Stephen Eppley, the code for counting votes with the MAM method now works accurately. My own code handled some things wrong, but Stephen Eppley, the inventor of MAM, fixed what was wrong with it. There is one day left to vote in the poll. The deadline for any last minute votes or changes is Saturday night at midnight, Eastern Standard Time. After that time, the script will automatically refuse any new votes.
The 'Review votes' button tells me, 'There is no record of your votes.' Does this mean that my votes didn't go through, or simply that there is something wrong with the review function?
Judging by what the code says, it means that your password and userid both checked out, but your userid could not be matched with any ballot. Your ballot does exist. I saw crazytom.php in the directory for the ballots. My best guess is that you did not type your userid in all lowercase. When I capitalized my userid as an experiment, it gave me the same error message.
To prevent the possibility of multiplying votes by entering your userid in various mixed-case forms, I have now added code that converts every userid to lowercase. This will also allow you to enter mixed-case forms of your userid without getting an error message.
I have begun work on implementing time controls, but I have not completed it yet. Since there was more silence than discussion on the subject here, I expect I will use the method I last described. Let me know if it poses any problems for you.
<P>Here is how the time controls will work. The time controls will have three parameters. These are $timelimit, $gracetime, and $bonustime. All of these will be measured in seconds. $timelimit is the total amount of time you will initially be given for making your moves during a game. Each time you move, the amount of time you have left will be calculated. At the beginning of the game, your time left will be equal to $timelimit. On the first move, the time difference between your first move and the creation of the log will be calculated, and for each subsequent move, the time difference between that move and the previous move will be calculated. This difference will then have $gracetime substracted from it. When this result is greater than zero, it will be subtracted from the amount of time left for the current player. When it is less than or equal to zero, the value of $bonustime will (assuming time has not already run out) be added to the amount of time left for that player. In this manner, the amount of time left for a player could grow greater than the value of $timelimit. Once time runs out for a player, that player will lose the game and be unable to increase his time left.</P>
<P>Here are the values I propose for the time control parameters:</P>
<PRE>
$timelimit = 2073600; // 24 days
$gracetime = 86400; // 24 hours
$bonustime = 21600; // 6 hours
</PRE>
<P>And here is the code I've written for enforcing time controls:</P>
<PRE>
// Check time
// The parameters used for time controls are $timelimit, $gracetime, and $bonustime. A record of the times
// when the game begins and when each player moves are stored in $timeline. $timestamps is an array of the
// values in $timeline, and $timeleft is an array of how much time is left for each player. The values for
// both these arrays are calculated fresh each time and are not stored in the log.
if ($timelimit > 0) {
if ($submit == 'Send') {
$now = time();
$timeline .= ' {$now}'; // $timeline was previously initialized to the log's creation time
}
$timestamps = explode(' ', $timeline);
// 1 = odd number, used for first player
// 0 = even number, used for second player
$timeleft[0] = $timeleft[1] = $timelimit;
for ($i = 1; $i < count($timestamps); $i++) {
$timeused = ($timestamps[$i] - $timestamps[$i-1]) - $gracetime;
$timeleft[$i & 1] -= $timeused;
if (($timeleft[$i & 1] < 0) && ($submit == 'Send')) {
// First player has run out of time && it is first player's turn := opponent wins
// First player has run out of time && it is second player's turn := player wins
// Second player has run out of time && it is first player's turn := player wins
// Second player has run out of time && it is second player's turn := opponent wins
$status = sprintf ('%s has won.', (($i & 1) ^ ($side != $first)) ? $opponent : $player);
break;
}
if (($timeleft[$i & 1] >= 0) && ($timeused <= 0))
$timeleft[$i & 1] += $bonustime;
}
}
</PRE>
That sounds fair. The system is much the same as is used in the Internet Chess Club under certain options.
I'm working on changes to the time control methods I previously described. One cosmetic change is that $timelimit has been renamed $sparetime. One minor change, which probably won't affect the tournament, is that getting bonus time will be dependent on moving within a specified bonus period instead of within the grace period. I say it probably won't affect the tournament, because I plan to set the bonus period equal to the grace period. I am just making them different for the sake of more flexible time controls. The more significant change is the addition of extra time. This is an amount of additional time that is unconditionally added to a player's total time for each turn into the game. In summary, the time controls will use four types of time keeping. These are spare time, grace time, extra time, and bonus time. And here is how I'm thinking of assigning them. $sparetime = 7 days $gracetime = 24 hours $extratime = 24 hours $bonustime = 24 hours for moving within 24 hours. I'll first point out that this is more liberal than what I posted last time. $gracetime remains the same, while bonus time is now more generous. Although $sparetime has shrunk considerably, this is more than made up for by 24 hours of extra time for each move. In any game of average length, all the spare time I trimmed off will be given back as extra time, and there will be more extra time besides that. These time controls will allow an average pace of 2 to 3 days per move while encouraging the faster pace of one move per day. They should also accomodate players who need to take several days off from time to time. I'll post more details when time controls are fully implemented and documented.
<P>Time controls are now described in the User's Guide. Here is what the code for checking time presently looks like:</p>
<PRE>
// Check time
// The parameters used for time controls are $sparetime, $gracetime, $extratime, $bonustime, and $bonusperiod.
// A record of the times when the game begins and when each player moves are stored in $timeline.
// $timestamps is an array of the values in $timeline.
// $timeleft is an array of how much time is left for each player.
// The values for both these arrays are calculated fresh each time and are not stored in the log.
// $yourtime is the amount of time left for the player who is moving.
if (!empty($timeline)) {
if ($submit == 'Send') {
$now = time();
$timeline .= ' {$now}'; // $timeline was previously initialized
}
$timestamps = explode(' ', $timeline);
// 1 = odd number, used for first player
// 0 = even number, used for second player
$timeleft[0] = $timeleft[1] = $sparetime;
$stamps = count($timestamps);
for ($i = 1; $i < $stamps; $i++) {
$timeused = ($timestamps[$i] - $timestamps[$i-1]);
$timeused = max(0, $timeused - $gracetime);
$timeleft[$i & 1] -= $timeused;
if (($timeleft[$i & 1] < 0) && ($submit == 'Send')) {
// First player has run out of time && it is first player's turn := opponent wins
// First player has run out of time && it is second player's turn := player wins
// Second player has run out of time && it is first player's turn := player wins
// Second player has run out of time && it is second player's turn := opponent wins
$status = sprintf ('%s has won.', (($i & 1) ^ ($side != $first)) ? $opponent : $player);
break;
}
// The $extratime and $bonustime you get for a move are awarded after your move.
// So they do not figure into determining whether you have run out of time.
$timeleft[$i & 1] += $extratime;
if ($timeused < $bonusperiod)
$timeleft[$i & 1] += $bonustime;
}
$yourtime = ($submit == 'Send') ? $timeleft[($stamps - 1) & 1] : $timeleft[$stamps & 1];
}
</pre>
The suggested mechanism looks fine, but just in case some players feel swamped, it might be worthwhile to let them propose their opponents a common raise of $sparetime, perhaps limited to $sumofcommonraisesinagame. Surely some of these would accept the offer. It also depends on how many games we play simultaneously, of course. And what about illegal moves? Three days for the opponent, loss on the third offence?
25 comments displayed
Permalink to the exact comments currently displayed.