[ 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.
Pairs of coordinates are usually sufficient to describe a move. It would be very useful if there could be an arbitrary number of coordinates, though. It could then also describe moves that need more than two mouse clicks to be entered. The JavaScript could run through the list after every click, to get the sub-set of moves that start with the clicks that have already been made. (With only simple moves, after clicking a piece, this would leave you with the moves of that piece.) It could then highlight the 'next in line' click of each of those, so that the user knows which squares he can click next. If all clicks in a move would have been made, and no other moves start with the same sequence of clicks, the move can be considered entered. If there are still multiple options we can adopt the convention that one has to click the last-clicked square again to terminate the move without waiting for more clicks. E.g. for optional locust captures the second click could be on the locust victim, and the third click could be on the final destination.
Is the issue that to retrieve a position, each time all moves of the entire game have to be replayed? Even if this is the case, it would surprise me if it would take any measurable time at all. Chess engines typically search on the order of a million positions per second, generating all moves in each of these positions. Even if a scripting language would be 100 times slower, and a game on average has 100 moves, it would still only take 10 ms of CPU time to retrieve the game.
But for moves that are already part of the game, there isn't any reason to check their legality at all. This should have been done while they were first entered, and added to the game. Only newly submitted moves would have to be vetted. Older moves can simply be executed as stored. The only problem would be automatic side effects. But typically only very few moves have those. But locust captures or unloads generated from the Betza descriptions would never be automatic; they would always require full specification of the side effect in the input move. So the automatic side effects would remain limited to e.p. captures and castlings, which can be handled in the conventional way.