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.)
Golem Chess
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.)