Game-terminating moves (variant stuff)

[hgm]

The mini-AI in my Interactive Diagrams must be as general as possible, to handle a large variety of chess variants. For this reason I have been pondering about what game-termination rules commonly occur, and how these could be supported.

As we know, it is one of the defining characteristics of chess that the game is won by capture of a 'royal' piece. In some variants reaching certain squares can be a game-terminating event which is less 'chess-like'. But even for winning by capture of something there is a variety of rules.

1) winning can be instant or delayed (when the opponent gets an 'after-moe to strike back, possibly in a worse way)
2) if there are multiple royals you can win by capturing one ('absolute royalty') or must capture all ('extinction royalty')
3) sometimes certain pseudo-legal captures are forbidden by the nature of the intended victim alone, which can be described as that you lose by doing it. So this is a kind of 'anti-royalty'. This can also have some variations:
3a) its simplest form is the 'iron piece', which cannot be captured at all.
3b) pieces can be 'relatively iron': only immune to capture by some of the opponent's piece types, often the same type (a sort of anti-trading rule).
3c) pieces can also be 'temporary iron', e.g. for one turn following a certain event (like capture of a similar piece of the opponent)
4) similar to 3c there can also be 'temporary royalty'

The idea of delayed winning conditions is that they can be trumped by a more important winning condition. E.g. in Shatranj you win by baring the opponent, which in a sense makes all the pieces other than King also somewhat royal (as extinction royalty). But you must bare the opponent by a legal move, i.e. you cannot expose your King to capture while capturing the opponent's last non-King. So baring is delayed winning condition: the opponent gets an after-move, and if he succeeds capturing your King with that, it will be his victory, not yours. Only if you survive the after-move, you win. (And even then, in Shatranj, there is the possibility that the after-move bared you too.)

A convenient way to implement this is to keep a 'royalty count' decrementing in larger steps, and at the end of each turn:
1) test if a the new side to move has negative count. If so, he loses
2) test if the player that just moved has zero count. If so, he loses. (Or perhaps it depends on whether both now are at zero.)
So reaching zero represents fulfilling a delayed termination condition, as the player that just moved must already have had the zero count at the start of his turn. (This assumes you cannot decrease your own royalty count, which would not be true in cases like Atomic Chess; in that case there must be an even earlier:
0) test if the player that just moved has negative count. If so, he loses.)

The initial value of the royalty count decides whether it will directly go negative, (instant condition) or hit zero first (delayed condition). For FIDE, or with multiple 'absolute royals', you would start the count at 1 and decrement in steps of 2. With a pair of extinction royals you would start it at 3. For Shatranj you could decrement by 16 for capture of a King, and by 1 for capture of other pieces, and start at 15. Capture of a King is then instant victory, capture of all 15 pieces a delayed victory, which can be inverted when retaliation against your King immediately follows. If the retaliation counter-bares you, you would both be at 0 at that point. This could optionally be recognized as a special case that grants one extra after-move to prove the counter-baring was illegal, by capturing the King that did it. But it must be prevented that the 0-0 situation persists if he doesn't manage that. A sufficient rule is that when it is 0-0 both before and after a move, the game terminates as draw.

Reaching of a goal square is very similar to capturing a royal; if it must be done through a legal move, this can be enforced by making it a delayed winning condition. E.g. start the royalty counter at 1, decrement by 2 on King capture, by 1 on reaching the goal square.

The temporary stuff needs another implementation, similar to e.p. capture rights (which also evaporate after one turn): you inform the daughter node when the event occurs that grants it the temporary royal or iron target. The practical case where this happens is Chu Shogi, where the event is capture of a Lion. If a Lion did that, he gets to be temporary (absolute) royal for one turn, and the square where this Lion sits can be passed to the daughter node. This is a way of saying that it is forbidden / illegal to capture a protected Lion. If a non-Lion captured a Lion the opposite happens: all Lions of the capturing player then get to be iron. This could just be passed to the daughter as a flag, as it doesn't depend on the location of those Lions. (Well, actually it does: in exceptional cases a non-Lion can capture a Lion and in the same move promote to a Lion; that Lion would then not become iron. So we would have to pass the location of the capture anyway, so that this fresh Lion can be exempted.)

When we assume the to-square of the previous move will always be passed through daughter nodes, we only have to pass additional flags to indicate temporary royalty or ironness of Lions. In principle the move generator could already test this, and for the case of temporary royalty that could be smart, as you can abort generation as soon as you find a capture on the temporary royal. You could even try to be smarter, and subject the temporary royal to a check test, like you do for your permanent royal. OTOH, this is a rare situation, and anything you do extra to catch it early would almost always be wasted time. For captures of iron pieces you don't gain anything by weeding those out early. So I do all these tests in MakeMove, triggered by a property 'could-be-royal' that is defined for all piece types. All true royals, iron pieces and pieces subject to Lion-like anti-trading rules have this property set. And only if a capture victim has it set it is necessary to figure out exactly what we have to do: reject the move as illegal, declare it an instant win, decrement a royalty count, or prepare a flag to be passed to the daughter. In the first two cases MakeMove aborts without making the move, returning the appropriate score for the move (+INF or -INF); in the other cases it returns the evaluation gained by capture (material and PST).

A complication is that chess variants can have multiple capture, and that you have to sum the effect of all victims. I do this by indicating the various kinds of (anti-)royalty by bits in the could-be-royal code that are spaced well apart, so that summing them for all victims acts as a set of packed counters for the number of victims of each kind. The counters for captured primary and captured secondary royals can then multiply the usual decrements for such victims. A (multi-)capture cannot be made if one of the victims is flagged as iron. Each set of pieces that are 'relatively iron' for each other has its own flag, and by testing the corresponding counter fields with an AND operation the move can be rejected when any of those matches. There is a flag for creating temporary royalty when both victim and capturer have it, and a flag for creating temporary ironhood when the capturer does not have it, but the victim has.