I am not sure how this comment could have ended up in this untitled discussion; I am pretty sure I posted it as a reply to Garth Wallace's piece-definition topic. This must be a bug of the posting system. Perhaps an editor can move this comment to the topic where it belongs. Moved. I'm not sure what could've happened to it initially. --BR

From a practical point of view: the Jocly move generator defines each piece type through a 'graph', which is a board-size array. For each square this stores a set of 'trajectories', where each trajectory is a set of (squares, rights) combinations. The 'rights' part indicates under which conditions the piece can move there: when it is empty, occupied by an enemy (the latter still distinguishing royal and non-royal enemies), or never (but passing through it). First occupied square in the trajectory normally makes all later squares inaccessible (but does not affect other trajectories), except when a capture specifies hopper-capture, in wich case it only considers the moves behind the first occupied square. (This obviously was added as a not very general kludge to be able to do Xiangqi.) By listing this for each board square separately, it does allow location-dependent moving, and boards of irregular topologies. Although the principal reason for doing it that way was probably just efficiency: the graphs would never contain any moves that stray off board, so you would never have to test for that during move generation.

The extended Betza notation used by the XBoard GUI (XBetza) indeed implements general hopping as the ability of a step V, or repeated sequence of identical steps VV* (together referred to as a 'leg' of the move) as a condition on the occupancy of the final square of that leg, namely that it must be occupied, but will not be affected. This makes no sense in final legs of a move, but in non-final leg this 'p' modality supplements the usual 'm' or 'c'. It makes no difference between friend or foe (as hoppers usually don't), but XBoard allows the use of the combination 'tp' to limit the hopping to friendly mounts. (At some point the alphabet is just too small... XBoard also uses 'tc' for a 'tame capture', i.e. one that cannot capture royalty.) As you remarked locust capture can be indicated by a non-final leg with capture rights. And lameness as a non-final leg with 'm' rights only.

To define pieces as the Ultima Withdrawer, still another modality is needed. In principle the move can be seen as a locust capture that starts with a King leg, and then reverses direction for a Queen leg of minimally 2 steps. (Which again can be seen as a King leg followed by a Queen leg in the same direction.) You cannot combine this move with a normal Queen move, because that would make the capture optional. (Which in Ultima it isn't.) But if you always force the detour, the move must not be blocked by a friendly piece there. This can be done by also giving it hop rights (so total modality of the first leg 'mcp'). But that still fails when the Withdrawer wants to move away from a board edge. So I needed an extra modality on non-filal legs for that ('o'), which means 'can (temporarily) leave the board. Then 'mcpo' on the first leg would do it. Similarly, the 'Advancer' would be given a move that overshoots its final destination to make a capture, and then inverts direction.

In my proposal for a Betza 2.0 I tried to solve the problem of combination moves like castling (or catapult pieces) by defining a 'u' modality for 'unload'. The idea is to have one piece transport the other. In any case there also has to be a modality for 'friendly fire' (I picked 'd' for 'destroy'), which enables you to capture friendly pieces. A 'u' in a later leg would then leave there what you 'picked up' (= captured or destroyed) on a previous leg.

Move induction (as in Knight-Relay Chess) is also an interesting problem. It could be seen as a move of the induced piece, but then it would have to 'probe' if a friendly Knight is attacking it. This can be done by a leg step that can hop onto friendly Knights only, and use the first two legs of the move to make back-and-forth Knight jumps, and then a final Knight jump if that was possible. Or it can be seen as a move of the inducer, where it hops onto a friendly piece, transports it by another Knight jump, unloads it there and then retraces its steps. When every piece is inducible, and only a single piece type can induce, the latter method is conceptually simpler. Otherwise you would have to assign the inducible moves to every piece. Except that it is rather cumbersome to have the inducer retrace its steps after it unloaded the induced piece. But for convenience you could make a special unload modality for that ('tu'), which would mean 'unload and return'.

As to the ambiguity of move definitions: to get rid of that you would have to abandon the concept of trajectories, but make 'lameness' an intrinsic part of the definition. So each move becomes a set of squares to be modified in some specified way, (usually just the 'from-square' that gets emptied, and the 'to-square' that gets to hold the moved piece or its promotion choice), plus a set of squares on which a certain condition has to be fulfilled with respect to its occupancy (usually that they have to be empty). As mathematical sets are considered the same irrespective of the order in which their elements are mentioned, and can mention each element only once, you would have no freedom in specifying the move. But this quickly leads to very cumbersome descriptions for sliders (which would be decomposed into lame steps of various distances), and even worse for sliding hoppers (which would have to specify each of their distant hops as a number of combination of empty and occupied squares along their path to make sure the move is only allowed if there is exactly one occupied square in the path).