The past week I made another sweep through the alphabetical index to identify "game information pages" for variants that are within the capabilities of the Interactive Diagram's AI. I managed to everything from finish Z to R. (I was working backwards through the alphabet, because last time I went forwards from A, but I had forgotten how far I got.)

Since that previous sweep the capabilities of the Diagram have been greatly extended, in the sense that what needed embedding custom JavaScript in the page can now usually be handled by the morph and captureMatrix parameters.

I also developed new tricks for configuring the Diagram to handle games with 'limited' piece drops. With this I mean cases where the piece drops are just intended for introducing 'spare' pieces by dropping them in a comparatively small and save area of the board (such as the player's own backrank), where they are unlikely to cause much tactical upheaval. Most of the problems that exist with Shogi-like piece drops than do not occur. Dropping on empty squares in the backrank on 8x8 gives at most 8 drop moves for a piece in hand, not any different from what a typical minor piece has away from the edges. This means the search tree won't explode, especially if you can arrange the mechanism of introduction (e.g. by leaping from a brouhaha square) such that no multiple pieces of the same type have simultaneous access (by blocking each other).

A second consequence is that the value of a piece in the hand is not higher than on the board. Especially since the dropping typically cannot be a capture. So no extra depth is needed to make potential drops prove their usefulness, and overcome the intrinsic value loss on leaving the hand, as there would be for Shogi. In one respect the support of the I.D. for such drops can be improved: the heuristic for determining piece value for the off-board pieces completely fails, as it is judging the moves defined to travel to the board. (The in-hand piece is defined as a separate type, morphing into the desired piece when it lands on the board, and has only the moves it needs to reach the board as a valid drop.) Usually it is very low (because the number of potential introduction moves is small, and none of them are captures), or even zero (because introduction requires sliding through off-board squares, blovking any move on board).

The I.D. already has a value parameter, which can be used to overrule the automatically determined piece value. But for the introduction to work sensibly you would need an in-hand value very close to the value on the board (or it will always introduce at the earliest possibility, at the expense of sound development, or never introduce at all). And the piece value heuristic works by random sampling, making the absolute piece values vary from run to tun, (each time you reload the page). So you cannot set a value now that is slightly lower than the on-board value, without sometimes finding that it is actually higher, and the piece will not be introduced. This problem could be solved by allowing the value parameter to accept a relative value, which should be added to the heuristically determined value of a given piece. E.g. by appending a /xxx to it, where xxx is the number of the piece to which the value before the slash should be added.

Another possible enhancement of the I.D. could be the support of neutral pieces. I encountered several variants that I could not do because they involved those. Such pieces come in two flavors: those that have to be movable by both players, and those that have to be capturable by both players. I suppose there could be parameters friend=N and foe=N to give the numbers of the pieces that always can be moved or captured, respectively.

Support for the introduction method in Matts Winther's variants (of which there are many!), where they are 'gated' onto the board at the origin square of Pawn from its initial rank, might also be useful. So far th I.D. only has support for the Musketeer mechanism through the autoGate parameter. Seirawan gating is also not implemented.

Things that seem rather hopeless at the moment are variants with Shogi-style drops, and hexagonal variants. Of course hexagonal boards can be distorted to a square topology, but this loses most of the 'educational value'. Moves get asymmetric, and have ugly Betza notations. Even if it would be doable to make a table with masonry like square layout (and provide a full-board image with hexagons as background), I don't think it would be useful to include such Diagrams if there isn't a Betza-like notation system for moves dedicated to hexagonal topology. I was surprised how many hexagonal variants we feature on CVP.

[Edit] Oh yes, and not to forget about multi-player variants, multi-move variants, variants with hidden information, variants with dice/cards.... Those are the most hopeless of all.

Multi-dimensional is already possible, as it can always be mapped on side-by-side 2-dimensional slices. But the move description then is very ugly, and not fit for presentation (expressing the displacement in the remaining dimensions as very long leaps). To ameliorate that the meaning of the Betza atoms could be extended to their totally symmetric equivalent in higher dimension, so that at least variants with totally symmetric pieces (which are most common anyway) would be possible. There would be a shortage in directional modifiers, though. One method out of that would be to redifine 's' as the four sideway directions, which would allow symmetry breaking in the vertical direction. Or, more flexible, redefine the combinations v = fb and s = lr, which serve us so well in 2d, as v = (vertically) up , and s = down ('sinking').