[ 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.
OK, I pushed my latest changes on fairy-move-model.js and base-model.js, and I think these are pretty well debugged now. At least everything appeared to work as intended on the Makromachy game that I am developing, and that uses most of the new features.
En-passant capture is still a problem, though, with Pawns that can be pushed more than two steps. The original chessbase code only allows the pawn to be captured on the square directly behind it. I suppose the best solution is to make epTarget not just a square number, but an array of square numbers, so that there can be more than one e.p. square. This would be a change in base-model.js.
A problem specific to Makromachy is that e.p. capability is currently specified per piece. There is no way to limit the capture to a subset of the captures; any capture-only move can also e.p. capture for a piece that has epCatch:true. It would be more logical if this could be controlled by a mode flag of a move graph rather than a piece-type property. In Makromachy I have Warrior pawns that also have backward Knight captures, and the latter are not supposed to e.p. capture. I suppose I could create a work-around by allowing other values for epCatch, e.g. epCatch:2 meaning 'only the forward captures'.
Another thing I don't have yet is 'fast castling'. But I am not sure that should be supported through fairy-move-model.js. Perhaps I should just write some code for it in makromachy-model.js, using an initial type for the corner pieces, and add capture of their own king to their normal graph (through a FLAG_CAPTURE_SELF mode that would push them as candidate moves to the special moves stack, so that it can be vetted and possibly pushed on the normal moves stack by a routine customGen.)
Also still missing are 'brouhaha squares'. I suppose these could be implemented by using a confine on the moves, so that only captures can reach the brouhaha squares. (Except that confines also suppress moves that start outside the confine region.) I suppose that more subtle interpretation of non-zero values in a confine array could indicate some squares as "cannot move to there, but can capture". By taking a weird value to mean that, the chances of breaking anything existing will be very slim.