Very interesting!

Half-golem capturing adjacent half-golem:  It says 'If a piece other than
a Golem captures a Golem, the capturing piece is removed from play, and the
Golem is replaced by a Half-Golem of the same ownership as the Golem.' 
But it also says 'A Golem or Half-Golem may always capture an adjacent
Golem or Half-Golem.'

What happens here?  And likewise, if a half-golem captures an adjacent
full-golem, is the capturing piece also removed?

This is an interesting game I'd like to implement, but the following is problematic:

4.  As an exception to rule 1 above, you may capture a defended Golem or Half-Golem two squares away with a Golem or Half-Golem if it is the only legal move you have.

I don't have the ability to retroactively rule an otherwise illegal move legal based on the outcome of every other move.  I doubt any chess engine is going to do this.  There is a ZRF, and I've looked at it and don't believe it does this either, but I can't be 100% sure.  I have changed computers several times since I last had Zillions installed.

Is this really so hard to implement? I had a somewhat similar situation in the Interactive Diagram for Tamerlane II, where 'King Succession' (swapping King with a Prince as a move) is only allowed when you are checkmated. (I suppose the 'only-move exception' here in practice also only occurs when checkmated, as it is hard to imagine you could be stalemated when you still have a Golem.) So I could handle it by some extra code in the section that handles mates once it is detected that you have no legal moves. This code is almost never executed, so there is no slowdown in normal play. It then testst whether succession is enabled, and if so, tries all possible swaps with pieces of the designated successor type.

In an analogous approach you could, in a position without legal moves, generate the illegal Golem captures, search those, and return the score of the best. Since you had already generated them as pseudo-legal moves, and then rejected them in the special legality testing code, you could have the latter code stash the moves somewhere, and let the mate-handling code retrieve them, so you don't really have to generate anything.

Code-wise it is much simpler to just redo the entire node under conditions where the GxG captures would be considered legal. All other moves would be immediate hash hits anyway. Like

Search(stm, alpha, beta, depth, legalGxG)
{
  nrOfMoves = GenLegalMoves(stm, legalGxG); // the second parameter would suppress the special legality test on GxG
  if(nrOfMoves == 0) { // we are mated
    if(!legalGxG) { // well, maybe not really, as we might have rejected a GxG
      return Search(stm, alpha, beta, depth, TRUE); // redo allowing all GxG
    }
    return (incheck? -INF + ply : 0); // stalemate correction
  }
  for(ALL_MOVES) { // normal search
    ...
    score = -Search(!stm, -beta, -alpha, depth-1, FALSE);
    ...
  }
}

You could try to be smart and let the re-search depend on whether there actually were any rejected GxG moves, but since you will virtually never be checkmated, efficiency here is not really relevant. It hurts more that you have to pass an extra parameter to Search. But you could use the e.p. square for that (assuming you pass that, to indicate where e.p. capture is possible). By setting it to the location of the captured G after GxG you could indicate this G is now fair game even when protected.

This is a (still imperfect) attempt with the Interactive Diagram. Even for this I needed to adapt the Diagram script: although the new move-entry system does allow promotion to enemy (as needed when capturing a Golem), the AI did evaluate it as if the capturing piece changed into a Half-Golem of its own color. The type changes are dictated by a user-supplied routine WeirdPromotion; this was the easy part.

Of course the AI assigns the same value to Golem and Half-Golem, as it uses mobility as only guidance. Having it upgrade the value because of a user-specified demotion of pieces that capture it seems asking for too much. That raises the question how to handle this. Perhaps the Diagram should have a parameter value that can be used to overrule the automatic piece-value assignment.

The Golem and Half-Golem are subject to the Diagram's anti-trading features of the protected and counterStrike kind. These also forbid trading of adjacent Golems, though. Actually I think it is a flaw that Golem Chess allows this. For a Lion an adjacent piece would be captured through hit-and-run, and protection would be ineffective and not lead to trading. This is why the Chu-Shogi Lion-trading rules are as they are. For the Golems it still leaves an easy way to trade those, though. Of course I could have the Diagrams protected feature exempt adjacent capture. That would even give a better representation of the Lion. But I intentionally did not do that to make it more useful for pieces that cannot rifle-capture...

And no special exemption for checkmate yet... In the Diagram this is more difficult, because it only rejects the illegal captures after search, in the daughter nodes. So it becomes more difficult to communicate to the parent the move was rejected for this reason, so it can decide to redo those.

[Edit] Hand-tuning of piece values through a value=N line with N in centi-Pawn immediately after the line with a piece definition is now generally supported. (And used here to set the Golem value to about double that of what its mobility would suggest. That seems reasonable; it is like having two Half-Golems on the same square.)

This diagram isn't working properly. Capturing a golem is demoting it to a half-golem, but of the wrong side. The half-golem should be the same side as the golem was.

Flush the browser cache...

I found a loophole for easily allowing the forbidden trades as checkmate evasion, in the Diagram! There already was a parameter tradingThreshold, which served to implement Chu Shogi's exemption of 'bridge captures' from the Lion-trading rules: when you gain more than this threshold in the exchange, it is no longer forbidden to trade the protected piece. This can conveniently be used for suspending the anti-trade rule, by setting it to a large negative value. So in the mate-handling code (executed when after all moves have been searched bestScore is still at -15000) I added

    if(exemption) {
      var h = threshold;
      threshold = -15000; exemption = 0;
      bestScore = AlphaBeta(stm, alpha, beta, eval, last, preLast, depth, borrow, ply); // redo without trade ban
      if(ply == 0) bestNr = bestScore; // needed because in the root we return the best move instead of the score
      threshold = h; exemption = 1;
    } else ... // normal mate handling

This redoes the search of the node without trade ban (with a cleared flag exemption set through a new mateExemption parameter to prevent infinite recursion).

That does the trick: If I set up a mate through a7-a5, Ke8-a4, Gd8-c6, d2-d3, switch on AI, and then Gd1-c4, it will play Gc6xc4. If I set up a normal favorable trade, like Rh8-h6, Ra1-a6, Gd1-f6, switch on AI, and then Gd8-h6, it refrains from Gf6xh6, even though that would gain it a Rook.

Code-wise it is much simpler to just redo the entire node under conditions where the GxG captures would be considered legal. All other moves would be immediate hash hits anyway.

I could certainly do something like this, and if I was writing a dedicated Golum engine I would.  Sorry, I should have been more explicit.  I am wondering if I can do it inside the framework I currently have (which of course you don't know in detail.)  I don't want to add extra code to the search function that is specific to a single game.  But you have given me an idea of how this might be incorporated into the framework in a general way that - hopefully - would be useful for other games.

Whenever a move is made, a MoveBeingMade message is sent to every Rule object, which can then return IllegalMove to deem it illegal.  (For example, the CheckmateRule tests to see if a royal piece is attacked and returns IllegalMove if so.)  I suppose I could add another possible return value - IllegalUnlessOnly (or words to that effect.)  Moves with those returns would initially be unmade, as with illegal moves, but set aside.  If there are only IllegalUnlessOnly moves, then they would all be made again and the IllegalUnlessOnly returns ignored.  This would add a tiny bit of overhead, but only a couple of if-thens at each node unless the value is actually used.

Good job with the Interactive Diagram!  It's pretty close to playing correct Golem Chess.  And, since it's mostly for demoing a game, I don't think it's essential for the ID to impelment every minor rule.  This is a pretty uncommon corner-case.  The anti-trading rule only at range 2 is more common though.  I made a similar decision to make it only applicable at range 2 in my game, Odyssey, which has been in ChessV for years but I have never gotten around to publishing.

Well, I don't see much difference between what I did and what you propose here, considering the different frameworks we have. And the frameworks aren't so different. It is just that I consult the equivalent of these 'rule objects' in the daughter node. But that is also after the move has been made, and when that move is deemed illegal it is also unmade, and ignored in the parent (because its score is -INF). I could also differentiate different shades of illegality in the return code, if I wanted (as any score below -INF would effectively cause the move to be ignored), and take special action for an IllegalUnlessOnly code, like stashing moves for conditional later search, without subjecting them to the particular rule that made the move illegale 'IfNotOnly'. (Note that a move could be illegal for more than one reason, though; a forbidden trade could also expose your King!) And I also reacch a point where it can be concluded that no other legal moves are available, where I then have to take action to have the stashed moves searched. (In my case because bestScore is still at -INF after all other moves have been tried.)

It is just that I am to lazy for this cumbersome stashing of moves. Instead of figuring out which additional moves have to be tried, I just try all moves again, including those that were temporarily rejected for the IllegalUnlessOnly reason, by redoing the entire node in a tail recursion. But this time with the 'rule object' that rejected the move temporarily disabled, so these same moves won't get rejected again. This is of course very inefficient (especially without hash table...), but since it is a 'never happens' case, code simplicity prevails over run-time efficiency.

I don't see this as a feature dedicated to a single variant, but as a general mechanism to switch off certain rules in the 'only-move' case. (It is not really only move: there could be several rule-violating moves that solve the mate. E.g. you might be able to capture the protected Golem with two different Golems.) But there have to be rule parameters that specify which rules can be switched off in this case. As I programmed it now I can only switch off the 'no trading when protected' rule. (Of course one can argue that this entire anti-trading business is pretty much a dedicated feature for Chu Shogi...)

BTW, this already turns out insufficient: the counter-strike rule can also have to be suspended. E.g. black Ka4, Pa5, Pd5, Gc6, white Nb4, Gc4. (Other pieces in start position.) White plays Nb4xc6, for a discovered check. Pd5xc4 could cure the checkmate, but the counter-strike rule forbids this after NxG.

So I must also create ways to switch off more anti-trading rules. The enforcement of such rules (as well as checking and baring) are controlled by a 'property word' for each piece type, where the bits correspond to the various rules. (When you click the 'move' header in the piece table these properties are shown behind the piece value, in parentheses.) I guess I could implement the mateExemption parameter as specifying a mask, with which the property words will be ANDed in case no legal moves were found during the retry.

We cross-posted.  I hadn't seen your latest message when I posted mine.

Instead of figuring out which additional moves have to be tried, I just try all moves again, including those that were temporarily rejected for the IllegalUnlessOnly reason, by redoing the entire node in a tail recursion.

Thank you, this makes a lot of sense.  It is cleaner and should occur so infrequently that the cost is minimal.

I don't see this as a feature dedicated to a single variant, but as a general mechanism to switch off certain rules in the 'only-move' case

Certainly.  I'd imagine there are other cases that will turn up.

Of course one can argue that this entire anti-trading business is pretty much a dedicated feature for Chu Shogi

Sure, but Chu Shogi is important enough to warrant support and the anti-trading rules are appealing enough that they have been implemented in some fashion in several variants (Elven Chess, Golem Chess, Odyssey).  BTW, I now support Elven Chess, although still not Chu, mostly because I haven't found the significant time it will take to code all that and gather the graphics.

I don't see this as a feature dedicated to a single variant, but as a general mechanism to switch off certain rules in the 'only-move' case

Certainly.  I'd imagine there are other cases that will turn up.

Actually, this could also be used for Losing Chess, where you can only make a non-capture if there are no captures.  So all non-captures could be IllegalUnlessOnlys.  Although this would be an inefficient way to do it since it's likely to happen a lot.  A more efficient way would be to have the losing rule listen for both MoveBeingGenerated and MoveBeingMade messages.  In MoveBeingGenerated it just needs to make note of whether any capture was generated.  This wouldn't work if we had to worry about pseudo-legal moves, but Losing Chess has no check/checkmate so I don't think that's a concern.

Actually it is Suicide/Giveaway that has no checking. In Losing Chess the checking rule does apply, and you lose by checkmating or baring the opponent. So the situation you sketch is not entirely hypothetical. But fortunately engines like to search captures first anyway, so it would be very easy to stop when you reach the captures if the bestScore is no longer -INF (or the legal-move count is non-zero), in variants with mandatory capture.

I have gone through the alphabetical index A-D systematically to see which variants could be handled by the Interactive Diagram. For very many of those, some programming was involved in the form of user-supplied routines for interdicting some moves ('BadZone()'), or forcing type changes ('WeirdPromotion()'). The latter also because the Diagram does not support location-dependent movement rules, but uses the kludge of changing the piece type (often 'invisibly', i.e. to a type with the same image and same ID) to alter the move.

As requiring user-supplied JavaScript severely resticts the user-base, I would like to avoid the need for that as much as possible. So I have been looking for alternative ways of specifying what BadZone() or WeirdPromotion() should do, which can be supplied as Diagram parameters, from which the general Diagram script then would construct the required functions BadZone and WeirdPromotion to implement it. (E.g. by using a table-driven standard function for  it.) This is mainly an interface problem: how can you specify what needs to be done without resorting to Turing-complete programming languages?

The rules for which I had to provide custom JavaScript mostly fell into two categories: "something happens when you reach a certain square/zone", and "something happens when you make a certain capture/move". That 'something' then usually was changing piece type, terminating the game, or forbidding the move.

As a result of this reconnaisance mission, I already implemented a morph parameter that can take care of the majority of 'to-square-triggered' events, through which one can supply a FEN-like description of the board to indicate an event to happen when a piece of the type it applies to reaches that square. Which can be 'declare illegal', 'declare immediate/delayed win', 'change into type ...' or 'offer the standard promotion choice'. Note that game-theoretically declaring a move illegal is the same as specifying it as an immediate loss for the player who makes it.

The other case is still unsupported (or partly supported in an unsystematic way, such as all the anti-trading options). The Golem business also falls under 'capture-triggered event'. I guess a good solution for this could be to have a parameter through which the user can specify a 'capture matrix' of N rows and N+1 columns (where N is the number of participating piece types), rows separated by slashes in FEN-style. The options per square could be change into a piece of a given type (capitals for color of the mover, lower-case for the enemy color), 'declare illegal' (iron or relative iron), 'declare win' (royalty). Iron and royal are really two sides of the same coin, (game-termination, but with opposit result), so it is not surprising that these can be handled in a unified way.

E.g. for Golem Chess (piece types PNBRGHK) the value of this capture matrix would be

.....h../.....h../.....h../.....h../.....H../.....h../.....h..

representing

   - P N B R G H K
P  . . . . . h . .
N  . . . . . h . .
B  . . . . . h . .
R  . . . . . h . .
G  . . . . . H . .
H  . . . . . h . .
K  . . . . . h . .

where the first column of the matrix specifies what happens on a non-capture (e.g. for pieces that morph every move, like in Kyoto Shogi). To keep the size of the parameter manageable several shortcuts could be introduces, like a number for specifying a number of repeats of the previous symbol (implied to be . when there was none, the 0 being reserved for indicating 'kamikaze capture'), a double-quote for repeating the entire previous row (which would reduce the Golem matrix to 5h/"/"/"/5H/5h/").

With a special symbol for 'illegal' (like !) such a matrix can be used to specify absolute or relative ironness, or a Stratego-like pecking order. Absolute royalty could also be specified this way (e.g. by #). Unfortunately conditional anti-trading can collide with morphing, as under some conditions the move would still be allowed, and it should be specifiable what happens then. This could be solved by adopting the convention that symbols representing such rules (capture of protected, counterstrike) do not define a new matrix element, but apply to the preceding one. If counter-strike was represented by =, and capture of protected by %, the special rules of Golem Chess could have been specified by the matrix 5h=/"/"/"/5H%.%/5h%.%/5h= .

The same symbols could be used in the value string for the mateExemption parameter to indicate which anti-trading rules can be broken when there is no alternative legal move. I guess this even could be used for King Succession when the matrix is extended to 2N+1 columns, the final N columns for friendly capture. Then you would put a Betza move udU on the King that would allow it to 'capture' any friendly piece by teleporting to it, but unload it on the square it came from. You would forbid that move in the King's row of the capture matrix for all friendly piece types other than Prince. Under normal conditions you would also like to forbid it for Prince, but suspend that latter restriction in case of checkmate. To be able to specify such a selective suspension, there should be two different symbols for indicating 'illegal'. E.g. ? and ! . King x friendly Prince would then get ?, King x any other friend would get ! , and you would add mateExemption=? .