Comments by FergusDuniho

I'm interested. I was also thinking about going with Metamachy instead of Perfect 12. It seems to be a more recent evolution of Perfect 12. Perfect 12 does not appear in the "Chess Variants on very large boards" section of Cazaux's website, and that section begins with the statement "I consider that these variants are now surpassed by METAMACHY." So, I expect that he favors it over Perfect 12. Although he does not list it in his Favorites section, we have already done Shako as you mentioned, and the other two were for design contests with unusual board sizes. There is already a bare preset for this game, but I could make one that enforces the rules.

Having grace time makes things fairer for people who normally move at different times. A day of grace time is good for assuring that differences in personal schedules do not cost some players more time than others. While we should do something to rein in the length of games, some games go on because of several moves. Limiting the total time of the game could unfairly hurt the player whose turn happens to run up against such a time limit. The maxtime value is used to limit the total time a player may have between turns. It does not limit the total time for the game. This could put a cap on how much extratime and bonustime could increase someone's total time. Setting this to 30 days would mean that no player could take more than 30 days between turns. I would suggest setting it to 28 days, which is twice the initial spare time. If we want to be a bit stricter, we could set it to 14 days, which matches the spare time. This would allow someone who is behind on time to gain some back by making moves, but it would not allow anyone to gain more time than the initial 14 days of sparetime.

Looking at the ZRF, which was written by Glenn Overby himself, the code for the King looks like this:

; King
(piece
      (name King)
	(help "King: one space any direction to safe space; cannot leave fortress")
	(image Black "imagesABChessBK.bmp" White "imagesABChessWK.bmp")
      (moves
	((free) n (available) (verify (in-zone? fortress)) add)
      ((free) e (available) (verify (in-zone? fortress)) add)
      ((free) s (available) (verify (in-zone? fortress)) add)
     	((free) w (available) (verify (in-zone? fortress)) add)
      ((free) ne (available) (verify (in-zone? fortress)) add)
      ((free) nw (available) (verify (in-zone? fortress)) add)
      ((free) se (available) (verify (in-zone? fortress)) add)
      ((free) sw (available) (verify (in-zone? fortress)) add)
	(n (while empty? n) (verify (piece? King)) add)
      )
)

The free command is used to verify that a piece is not immobilized by an Immobilizer. This command is used before every type of movement except the last one. This last one is for capturing the enemy King by moving forward as a Rook. Therefore, an otherwise immobilized King can still threaten check against the enemy King, and this prevents the enemy King from checking it by moving to the same file with nothing in between them. Therefore, the rule against Kings being in the same file with nothing in between them is absolute, and there is no exception for checking an immobilized King with the other King.

The second link is wrong. It contains the string "{$userid}" instead of the value of the $userid variable. From what page are you getting this link?

I found a line of HTML that included "{$userid}" for inserting the value of the $userid variable, and I changed it to a PHP echo statement.

Ideally, I want to treat Metamachy as a game in which White has the first move of the first turn but Black has a special setup move before White moves. The trouble is that the more complicated Game Courier has gotten, the more difficult it has become to change how it behaves. I have some ideas for what to do, but I also worry about breaking things to get it done. It also takes a lot of inspection of the code to figure out how it works and what can be changed. Some of my ideas might also be useful for supporting multi-player games, but that's another thing I have not added yet because of the difficulty in doing so.

When I looked over the time controls before, I didn't notice the thing about the 4 moves per week pace. I had previously modified the invitation script to not include the option of setting a pace in the time controls, but I forgot about doing the same thing in the script for defining a round. The code is kept in Game Courier for backwards compatibility with games that still use it, but I do not recommend its use. Here is how it works. I have added some extra comments to better explain things.

// As long as you keep the desired pace, your reserve time is kept from falling below $sparetime.
// $i is the turn being checked. $i & 1 returns 0 or 1 to identify the player.
if ($timeleft[$i & 1] < $sparetime) {
    // Total time that has passed from beginning of game
    $timepassed = ($timestamps[$i] - $timestamps[0]);
    // If average duration for a move is less than the set duration for a move,
    // then moves are being made faster than required,
    // and $timeleft is raised to value of $sparetime.
    // Equivalent to -> if ((($timepassed / 2) / $i) < ($paceperiod / $pacefreq)) 
    // but loses no precision and avoids division by zero error
    if ((($timepassed / 2) * $pacefreq) < ($paceperiod * $i))
        $timeleft[$i & 1] = $sparetime;
    }
}

One problem with this is that it divides the time passed by 2, which is accurate only when each player takes exactly as long to move as the other player. It would be more accurate to count up how much time each player has individually used. So, it will normally reward both players or neither player, depending on how fast the game is moving along. It does not account for individual variation in playing speed. Because it divides time passed by two, the pace it checks for is actually half as fast as the pace specified. So, if the pace is 4 moves per week, it will reward players for moving twice a week. Without knowing how it works, you might imagine that it will enforce a certain pace. It will not do that. It will just reward players for keeping a minimum pace. When combined with other time controls that already reward players for moving quickly, it may help inflate how much time players have left. With the pace set to 4 moves per week, it will be possible to play slow, leisurely games that will take many months.

That information was already there in the Notation section. I tweaked it a little to make it clearer.

Nowadays, $orientation is mainly used when viewing a game, just in case you find side-flipping on each move disorienting and would like to view a game from a fixed perspective. It can be set in a preset or settings file with the use of GAME Code. It may also have a legitimate use in fairy chess problems, but it looks like the code for handling them needs to be overhauled.