The Play-Test Applet indeed adapts the default King move to the board width, by making the castling end as usual w.r.t. the corners. Identifying the castling partners is a bit tricky, though. Originally the Interactive Diagram allowed castling with corner pieces and Rooks (which in some variants start closer to the King). For the AI this was not acceptable, so I added code to scan the board to locate the piece that can castle, look how wide the rank is that it is on (the board could be irregular, or have holes, e.g. Omega Chess), and defines the extreme squares as 'corners'. If those squares are empty, it scans the rank towards the King to find a piece. Later I implemented the j modifier to explicitly shift the castling square inward (so the AI could also do Omega Chess, where the square behind the Rook is not empty).

In the Wizard Tutorial I state that if you are not interested in the FEN, you can just put one piece of every type you need on the board. I realize now that this is wrong: You need to put the someting at the edges on the King rank to get the correct castling partners. I guess I should alter the Diagram script to entirely rely on the j (and board holes, if any) for identifying the castling partners, irrespective of whether these are empty in the initial position. That makes the generated GAME code less dependent on the initial setup. The King would still have to be in the right place, though.

I am glad you like it. For variants with less-typical rules, such as the Jumping Chess, one still has to write GAME code. But often that can be limited to code to implement the non-standard rules. I try to make this as simple as possible, though. Confinement to board zones (at the pseudo-legal level) can now be enforced by just defining a single function for vetoing moves based on the square coordinates of those. I am not entirely happy with that yet, because it does not pass the location of any hopper mount. So it cannot be used to implement the Janggi rule that Cannons cannot jump over Cannons. In the Diagram hops are treated transparently, though: you don't have to indicate the mount when entering the move. As a consequence there can be an arbitrary number of them. Perhaps I should have the move generator remember what was the last piece hopped over, and also pass that to the user-supplied routine.

For larger flexibility I guess it would be good to allow a user-supplied callback for the move generator, so make it easy to call it for your own purposes. Like testing whether there exists a move that is mandatory (by whatever criteria you want).