Sjaak II question

[hgm]

Does Sjaak II support 'absolute royalty', where capture of the first royal ends the game, rather than capture of the last remaining one?

[Evert]

Does Sjaak II support 'absolute royalty', where capture of the first royal ends the game, rather than capture of the last remaining one?

No.
In fact, it doesn't really handle "capture the royal" as a victory condition, it just ignores check if there is more than one royal piece present (with a special "duple-check" modification). That should make it relatively easy to support what you describe: it just needs to not skip the "in check" test if there are multiple royals present and the relevant rule is used, so I can certainly add that as an option.

Do you have a particular game in mind where this comes up?

[hgm]

This is not completely clear yet. I was advising someone who wanted to implement his own variant, (and now is using Sjaak II to do it), on the chess.com forum. But so far he has been a bit vague about the exact rules. My first impression was that he needed absolute royalty,though:

https://www.chess.com/forum/view/genera ... st_comment

I guess the 'duple check' rule can be generalized as "cannot leave N (or more) royals exposed to capture", where N=2. Absolute royalty would then be N=1. The rule that you cannot leave your only royal in check even if N> 1 is an independent one (implied by the very concept of 'royal').

Btw, for the Maka-Dai-Dai-Shogi Emperor there is a very unusual rule, that being able to recapture with a non-Emperor an Emperor that captured a royal on the preceding ply is a winning condition that prevails over the rule that you lose without royal. This is a bit similar to the Shatranj baring rule, where you still get a one-time opportunity to 'counter-bare' after being bared, so that you have to apply the test for "he is bare and I am not" at the beginning of your turn, rather than the end.

[JoshPettus]

doesn't sho shogi use this rule?

[hgm]

Sho Shogi uses extinction royalty: win by capturing all royals, rather than just one.

[Evert]

Ok, that is indeed a bit vague. By the way, I saw a comment along the lines of "pieces cannot capture, but they can deliver check"; that will not work: the capture move is used for check detection, so a piece that cannot capture cannot deliver check.

For this to work, pieces would need to have an "iron" property that would then be defined for all pieces except royalty. I can add that as a piece property as well.

[hgm]

Indeed, the way he describes it suggests that this would need some kind of selectivity in the capture moves, so that you only can capture some pieces and not others. In Betza 2.0 that could be indicated by a limiter on the c modifier: c{P,N,B,R,Q} . XBoard's XBetza notation supports just the reverse: you can specify that moves cannot deliver check by adding a t modifier ('tame'). The idea behind that would be that if the rules for moving a piece would be too subtle to specify them exactly in XBetza, you would specify it in a generous way that ensures everything it can do would be considered legal, but prevent that any of the spurious moves would cause imagined checks that would make opponent moves illegal. (E.g. in Knight-relay Chess you would give every piece a tN move, and leave it to the engine to decide whether an N move is legal or should be rejected.)

Btw, some time ago I made the ad-hoc extension (which will go into XBoard 4.9) to XBetza that an ii prefix to a move means the move can be done if the piece has made a single non-initial move. This to allow representation of the Pawn-push rules of Wildebeest Chess (fmWfceFifmnHiifmnD). A change I yet want to make before 4.9.0 is to further overload the i by giving it a different meaning in continuation legs of a multi-leg move, where the meaning of 'for virgin pieces only' makes no sense. In that case it would stand for 'iso', and could be used on sliding legs that have to be of equal length as a previous sliding leg. This to allow representation of slider rifle captures such as caibR.

[Evert]

I've implemented "iron" as a piece property and added a rule for "attack on any royal means check". These will make it into the next release of SjaakII. I also fixed output of ANSI escape codes on Windows, to make the program a bit easier to use from a terminal in Windows (for users who want that), but this is a bit hard to test for me.

In different news, I've also added "flexible" castling (where the destination square is not fixed). If I now add the ability to define a second "special" move I will be able to handle Wildebeest Chess, which may be worth it. The only thing that isn't handled at the moment is castling where the king only moves a single step. Defining such a castle move leads to unpredictable results because in input and outputit would be indistinguishable from a regular king move. How should such a move be sent? Presumably as a multi-leg "Kf1,Re1" move?

[hgm]

You could call that rule 'simple check', to stay in line with 'duple check'.

The King + Rook move should work in the latest XBoard. I suppose it would write it in SAN as Kf1xa1-e1, though, as the internal representation would be f1e1, with 'kill square' a1. This is also how the move would have to be entered with the mouse.

[Greg Strong]

I'm not sure I follow. What should the GUI expect from the engine? I would think "f1e1,a1f1". If there's no standard for this yet, I think there should be a simple syntax like that for moving multiple pieces (for Marsellais Chess for example.)