[ List Earliest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]
Check out Janggi (Korean Chess), our featured variant for December, 2024.
Check out Janggi (Korean Chess), our featured variant for December, 2024.
Well, I will definitely start with something simple. But I don't want to paint myself into a corner from the start, so some advance planning of the strategy that will eventually be adopted seems useful.
The problem with using $prev is that it doesn't seem to offer any hope of expanding the capabilities to more than 1 move + 1 explicit side effect, something I would still like to do in the future. It would be possible to specify the side effects before the move, but that mostly subverts the effectivity of the allow command, as to allow both simple moves and combinations suicide + move one would have to allow moves + captures both as first and second move, and then it would not weed out cases where the user typed two normal moves. I could use the explode trick on every move on the off-chance that the user might have entered a move with a side effect, but the store and restore this requires to not mess up the game state must also be an order of magnitude more expensive than just testing pseudo-legality of a given move.
When I would specify allow moves 1 captures 1 promotions 2 freedrops 2 suicides 2 suicides 3 , I could test whether the input line did specify side effects by something like if != dest null and origin: . For simple moves moved and origin are reliable, and I could run the move generator only for the moved piece. Whether the move is compared in coordinate form or as text string really should not matter much. For composit moves I would either have to recover the moving piece through the explode trick, (because I don't know how many suicides followed it, so I cannot rely on prevorigin either), or generate moves for all pieces to see which one matches the thismove string.
It would have been very helpful, efficiency wise, if it could be tested whether the Pre/Post-Move code is run for a new input move, or just for a move that was already accepted as part of a game, and is now played to set up the current position. Is there a variable that holds the current game length? I suppose it would be possible to update a global counter in the Pre-Move section (initialized to 0 in the Pre-Game section) to keep track of the move number. If the move is not the last move in the game, the Pre/Post-Move code could be made to suppress any unnecessary (pseudo-)legality testing. In particular, composit moves would not have to be tested, as they would be guaranteed to not have any implied side effects (the very reason for them being composite being that they explicitly specify all their side effects).
[Edit] is this a matter of comparing movenum with mln ?