[ List Earliest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]
Comments by FergusDuniho
Game Courier Tournament #1. A multi-variant tournament played on Game Courier.[All Comments] [Add Comment or Rating]Ideally, everyone would get to play everyone else. This is desirable from a social perspective, because it allows everyone to meet everyone. It is also desirable from the perspective of fairness, because it is more fair to declare someone the winner if he has played everyone else. This means that he has played the same opponents as others and that he has played against each of the losers. With large numbers of players, having everyone play everyone else becomes less desirable, because it may overload the players with too many games to play. In that case, the social goal may be compromised, since it is not critical. Instead of fully meeting it, it may be maximally met by giving a player a new opponent for each game. But the goal of fairness still remains as important as before, and it should not be compromised if at all possible. The advantage of the subtournament method is that it works best for maximizing the fairness of the tournament. But since it is not doable with most numbers, I have proposed a different method for more than eight players. It is a three-round method with eliminations after each of the first two rounds. Four games are played in the first round, four more in the second round, then three in the last round. The first round reduces the players to eight, and the second round reduces the players to four. In the first round, it would not be fair to immediately give the win to the highest scoring player, because there would be some players who have not played each other, including some who have not played the highest scoring player. But it does seem fair to eliminate all but the top eight players. Odds are good that the best player will be among these eight. In the second round, players play four more games, as much as possible against new opponents. At the end of this round, it is still possible that some of the players in the second round have not played each other, though it is no longer an inevitability. So, while it may not be fair to declare the highest scoring player in this round the winner, it does seem fair to eliminate the four lowest ranking players. Finally, in the third round, all remaining players play each other at one game apiece, and the winner of the tournament is the winner of this round. This method is also described in the text I am adding to this page, and it includes details on tie-breaking, which I have not included here. In the comments section, I am focusing more on the justification for this method.
I agree that players should be given a choice of games in the first round. If we go with the three-round method I described, then I would recommend letting players rank their preferences among the top 11 games, then do my best to assign everyone his top four games in the first round. Assignment of opponents would be based on who shares your top choices. As players continued through the rounds, they would eventually have to play some of their less preferred games. To retain some choice of games in the last round, each pair of players would have the option of playing any game they had both won against other players in the tournament. This option could even be given during the second round. Before the tournament begins, I plan to make Game Courier keep track of how much time each player has taken. This could be done by creating a timestamp list that parallels the movelist. I could also create a timelimit function that causes a player to automatically lose when his time runs out. So that all games in the tournament could be manually checked to see whether the timelimit function was being used, I would also include information on its use in View move. As for the timelimit itself, how about 30 days per player. If both players kept an even pace, this would allow a game to last as long as 60 days. Then, each round would be given two months to finish. If everyone happened to finish the round sooner, then the next round could begin sooner. With three rounds, the tournament would last up to six months but could take less time. I think four games at once may be doable. Game Courier makes it easy to play multiple games at once, but most people will be playing in their spare time, and they shouldn't be too overloaded with games. Playing four games at once, most people may be able to manage a pace of two moves a day in each game.
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.
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?
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.
Ultima. Game where each type of piece has a different capturing ability. Also called Baroque. (8x8, Cells: 64) (Recognized!)[All Comments] [Add Comment or Rating]The Wikipedia page on Baroque Chess currently asserts that Robert Abbott did not invent the game, as can be discovered by reading the Fairy Chessmen by Lewis Padgett. I expect this is a bunch of nonsense and have explained why in the discussion area for Wikipedia's Baroque Chess page. However, I have not read the Fairy Chessmen and cannot get ahold of a copy. If anyone has read it, would you take a moment to either confirm my suspicions or to tell me how Ultima is described in this book? If someone will confirm my suspicions that the Wikipedia author doesn't know what he is talking about, I will go ahead and change that page. http://en.wikipedia.org/wiki/Baroque_chess
Game Courier Tournament #1. A multi-variant tournament played on Game Courier.[All Comments] [Add Comment or Rating]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.
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.
Interview with Ralph Betza. An interview with the `Grandmaster of Chess Variant Design'.[All Comments] [Add Comment or Rating]'One idea is to have polls for each type of game. Then we can see which people find the most fun!' We have conducted polls in the past and shall continue to do so, though I don't think we have conducted polls on specific types of games. 'Why not team up with FICS and get some more variants into the chess servers?' As far as I could tell, FICS is only a Chess server. If they become interested in Chess variants and want our help, they can contact us. In the meantime, we have Game Courier, which already handles over a hundred variants and can always handle more. http://play.chessvariants.com/pbm/
Shogi. Play the Japanese form of Chess, in which captured pieces can be dropped back as your own. (Recognized!)[All Comments] [Add Comment or Rating]For the present, I want to focus on the upcoming multivariant Game Courier tournament. Besides other variants, this tournament should include both Shogi and Kamikaze Mortal Shogi. It looks like Shogi does have the popularity for its own tournament, and this is something we could do in the not too distant future.
Kamikaze Mortal Shogi. Send your Kamikazes on suicide missions in this Shogi variant.[All Comments] [Add Comment or Rating]I'm glad you like the graphics. I even made a Japanese Kamikaze piece, using the Japanese character for wind. Kamikaze literally means divine wind.
Game Courier Tournament #1. A multi-variant tournament played on Game Courier.[All Comments] [Add Comment or Rating]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>
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>
<P>I've done some tweaking to the time control setting I previously proposed. After running through some examples, I consider the following setting to be good for setting an average pace of 3 moves per week.</P>
<PRE>
Spare Time: 7 days
Grace Time: 32 hours
Extra Time: 24 hours
Bonus Time: 8 hours
Bonus Period: 24 hours
</PRE>
<P>These settings will accomodate a pace of three moves per week, so long as each move is made on a different day. It will work for three adjacent days, such as Friday, Saturday, and Sunday, or for three nonadjacent days, such as Monday, Wednesday, and Friday. Let me explain how it works for each example. If someone moves Friday, Saturday, and Sunday, he can gain enough time to coast until next Friday. He will need five days of time. He uses 1 1/3 days in grace time, gets 2/3 in bonus time, and gets 3 in extra time. These add up to 5 days. If a player moves Monday, Wednesday, and Friday at the same time each day, grace time and extra time for a single move are sufficient for the two 48 hour intervals, and there will be at least 16 hours of extra time left over. Combine this with 32 hours grace time and 24 more hours of extra time, and you have 72 hours, enough time to go from Friday to next Monday. These calculations all presume that your opponent moves immediately after you each time. Odds are good that this won't happen, which will allow you to maintain this pace with time to spare or to move at a slower pace. Also, if you keep up a pace of at least 4 moves per week, you will gain time every week.</P>
<P>Antoine proposes that players should have the option of mutually raising their sparetime. I don't think this is necessary. If two players in a game are both in need of more time, they can cooperate together to both use their time more efficiently. For example, if each player made full use of his gracetime and extratime for each move, they could reduce their pace to 1 move every 4 2/3 days.</P>
<P>Regarding illegal moves, I don't think it is necessary to make any special provisions for them. First of all, Game Courier makes it easy to take back an illegal move. Second, given that you don't have to think long about your move when you're taking back an illegal move, the person who makes an illegal move is the one more likely to lose time. Therefore, there is no incentive for intentionally making an illegal move.</P>
<P>While on the subject, there should be a rule against taking back a move unless it is an illegal move. After all, this will be a tournament.</P>
Antoine's idea for increasing $sparetime gave me another idea, which I went ahead and implemented. This idea is to treat $sparetime like an insurance policy. I've added a new time control, called Pace. When you set a pace, any player who maintains that pace has his reserve time protected against going below $sparetime. It works like this. At the end of a player's turn, so long as the player hasn't run out of time, a player's reserve time is compared with the spare time. If it is lower than spare time, and if that player is currently maintaining the desired pace, it is set equal to $sparetime. With this in play, there are two ways to run out of time. One is to fail to keep the pace and gradually use up one's remaining time. The other way is to delay moving so long that even having the full spare time isn't enough. What this insurance protects against is gradually running out of time while maintaining the desired pace. Here's an example of what I mean. Let's suppose that time controls are what I gave in my last message, and a player makes three moves each Sunday but never moves any other day. This player is keeping the pace of three moves a week, but the other time controls are such that he will gradually lose time. But by using $sparetime with pace setting, this player can maintain a reserve of 7 days even though the other time controls don't facilitate this. Fuller details are provided in the User's Guide.
Game Courier Developer's Guide. Learn how to design and program Chess variants for Game Courier.[All Comments] [Add Comment or Rating]This guide now describes the following new commands: setflag, unsetflag, copyflag add, move, replace if, else, elseif, endif, verify The verify command was already available, but it has now been greatly expanded. I created some of these commands for use with Crazyhouse, and I created others because of their similarity to other commands I was creating. In particular, the new Crazyhouse preset tracks Pawns with flags, uses verify to check the flag of a captured piece, then uses add to change it to a Pawn if it used to be one. Although I didn't use them, I also figured out how to implement nesting if, if-else, and if-elseif-else statements. I haven't thoroughly tested them out yet, but I expect they should work.
The if commands are not working properly right now, but it's too late to continue debugging. I'll continue working on it later.
The if, else, elseif, and endif commands should be working properly now. My tests of their behavior are successful so far. The endif command has been expanded to allow the all parameter or a numeric parameter. The all parameter closes off all if scopes. A numeric parameter is like repeating endif as many times as specified. If you write an if-elseif series, it is appropriate to end it with 'endif all'.
Mortal Chessgi. A Chessgi game in which captures reduce material. (8x8, Cells: 64) [All Comments] [Add Comment or Rating]I'm glad you like my game. I don't do Java programming, but maybe you could ask Ed Friedlander to do something. I program primarily in PHP, and I have written a preset for playing Mortal Chessgi online with Game Courier. Game Courier includes the ability to play any of its games in solitaire mode. The link is already on this page. If you enjoy Mortal Chessgi, you may also enjoy Mortal Shogi and Kamikaze Mortal Shogi.
25 comments displayed
Permalink to the exact comments currently displayed.