Comments/Ratings for a Single Item

As things work right now, it is possible to take back moves, because when you do, it will replay all the canonical moves and skip over the moves that were taken back, recalculating game data as each move is made. But suppose you're evaluating each move only once, using constants to keep track of game information like whether certain pieces have already moved, and someone takes back a move that changed some of the information stored in the constants. You would either have to restore the game data to what it used to be, which could become rather tricky, or give up the ability to take back moves that do change game data.

Storing the game state as the sequence of moves from the initial position is a good method, and for most of the game more compact than remembering the current board position. Especially for large games. And a large part of the move history is actually part of the game state, if there is an N-fold repetition rule. Ordinary move notation is not reversible, so taking back moves directly would require storing extra information (such as what was captured), and replaying the game from the start solves that problem. (But in shuffle games you would also have to remember the start position, or at least the random seed used for generating it.)

The question was not whether it was needed/desirable to replay the moves, though, but whether it was necessary to test the (pseudo-)legality during this replay. And there the answer is "no, except for the latest move". Since Game Courier is such that you can only add one move at the time, all earlier moves must have been the latest move at the time they were added, and when they were legal then, they will be legal in the replay as well. And otherwise they would have been refused, and never added to the game.

So for all but the last move there is no need to test pseudo-legality, and moves that are 'self-explanatory' can just be performed as specified. The only caveat is the handling of moves that have implied side effects. These should be recognized at all time, and when they appear the implied side effect should be performed in addition to what the move specifies explicitly. Common cases of implied side effects are disappearence of the enemy Pawn on e.p. capture, and moving of the Rook in castling. Depending on the prescribed move notation there could be other cases, such as the captures in Ultima. In principle all Ultima moves can be described by the origin and destination of the moving piece.

In the GAME code generated by the Play-Test Applet I treated this by having two sets of moves for each piece: one consiting of all the moves, and one only of the moves with implied side effects. For most pieces the latter set would be empty. Only for the latest move the full move set is used, to check if the newly entered move is amongst those. For all other moves it is only tested whtherthe move matches one with implied side effects, and if it does the generated move (which is aware of the side effect) is performed rather than the move from the move list (which does not specify any side effect). Moves that do not match any of the moves with implied side effects are taken at face value.

(But in shuffle games you would also have to remember the start position, or at least the random seed used for generating it.)

It normally stores the seed, but when several games of Fischer Random Chess broke because PHP's algorithm for selecting random numbers had changed, I added constants to the language. Since Game Courier is designed for correspondence games, it runs a game from the beginning for each new move. Unlike variables, whose values are determined only by the running of the program and the input fed to it, constant values were stored in logs or $_POST data so that they would be available without re-running the code that originally generated them. The main thing distinguishing a constant is that it's value survives from one run of the program to the next. With that in mind, its value may be changed if necessary, but this is done with a special command, since going along with the way constants work in other languages, a constant is supposed to keep the same value.

In the Interactive Diagram script I included my own random implementation to guarantee consistency. In the GAME code include file for shuffling that it uses I do use a constant ('startshuffle') to store and retrieve the array '$space' at the start of the game, and only shuffle when this constant is not defined.

It occurred to me that the problem I was having with king moves might be because I was setting after in a for loop but not resetting it to false before the next piece was evaluated. Changing that does seem to solve the problem. There might still be better ways to do this with the fairychess system.

I do like the idea of having a non-displacement capture entered with only one click on the target piece because that's the easiest way I can see to disambiguate between a capture and a non-capture in cases where both would result in the moving piece landing on the same destination. The difficulty I have with that is making the notation work with it, since if I record the extra move, it isn't considered legal in some situations.

The difficulty I have with that is making the notation work with it, since if I record the extra move, it isn't considered legal in some situations.

To avoid the need to write code for screening out extended moves, Game Courier uses the maxmove system variable and the ban and allow commands. The maxmove variable indicates how many moves may be made on a single turn. You can use the ban command to ban many things globally then use the allow command to make exceptions for certain types of moves at certain places in the extended move.