H. G. Muller wrote on Thu, May 19, 2022 09:12 AM UTC:
Zillions of Games is a commercial program, and not everyone has it. It is a pity the AI of the Interactive Diagram doesn't do drop moves yet. In general variants with drop moves (such as Shogi) are very hard for a computer, because of the huge branching factor. In this case drops (for summoning Demons) are limited to just a few squares adjacent to the Mages, while most of the time there wouldn't be anything to drop because the Demons are already in play. Implementing the Demon summoning as a regular drop, which would try any square, and rely on a user-supplied BadZone routine to reject any drop that doesn't land adjacent to a Mage would still be a very inefficient implementation, though.
I guess it would be possible to abuse the XBetza 'unload' modifier u for summoning. Currently this is defined as putting the piece that was captured by the move at the origin square of the leg that it labels. But a back-and-forth move where the second leg unloads (e.g. abuK) would never capture anything, as it would end where the piece itself was (and the first leg per default has m mode). But if the Diagram's AI would simply ignore the u in such a case, effectively making it a turn pass, a user-supplied routine WeirdPromotion could be used to specify a new piece for the unload square rather than the overall destination of the move. Promotion choices are automatically taken from the 'hand' already (to implement promotion-to-captured-only). This would then selectively generate drops on squares adjacent to the pieces capable of summoning (which have the abuK move component specified on them).
Zillions of Games is a commercial program, and not everyone has it. It is a pity the AI of the Interactive Diagram doesn't do drop moves yet. In general variants with drop moves (such as Shogi) are very hard for a computer, because of the huge branching factor. In this case drops (for summoning Demons) are limited to just a few squares adjacent to the Mages, while most of the time there wouldn't be anything to drop because the Demons are already in play. Implementing the Demon summoning as a regular drop, which would try any square, and rely on a user-supplied BadZone routine to reject any drop that doesn't land adjacent to a Mage would still be a very inefficient implementation, though.
I guess it would be possible to abuse the XBetza 'unload' modifier u for summoning. Currently this is defined as putting the piece that was captured by the move at the origin square of the leg that it labels. But a back-and-forth move where the second leg unloads (e.g. abuK) would never capture anything, as it would end where the piece itself was (and the first leg per default has m mode). But if the Diagram's AI would simply ignore the u in such a case, effectively making it a turn pass, a user-supplied routine WeirdPromotion could be used to specify a new piece for the unload square rather than the overall destination of the move. Promotion choices are automatically taken from the 'hand' already (to implement promotion-to-captured-only). This would then selectively generate drops on squares adjacent to the pieces capable of summoning (which have the abuK move component specified on them).