Multi-king SEE does not move kings

[ddugovic]

This code obviously does not update the occupied bitboard (to move the king(s) which may be captured):

template<>
PieceType min_attacker<KING>(const Bitboard*, Square, Bitboard, Bitboard&, Bitboard&) {
  return KING; // No need to update bitboards: it is the last cycle
}

In extinction chess if there are multiple kings of both colors attacking the same square, SEE can only be resolved by updating occupied each time a king "moves".

[ddugovic]

Hmm... there isn't a simple solution since Two Kings rules are complicated. So let's start with a simple baseline (even if we lose Elo): if any king moves during SEE, terminate SEE. We can compare that baseline either to master or to 4631595ef4561cf1fd649d460a67a6da4e135d63 .

I expect for Extinction that baseline (versus master) will fail [-10, 5] and that for Two Kings that baseline will pass [-10, 5].

[ddugovic]

I think variant Two Kings makes this difficult, but only because moving either king may change which king is royal.

Maybe Two Kings needs a separate SEE routine (at least when moving a king affects which king is royal), like Atomic has a separate SEE routine. Then I like your suggestion (although if possible I'd want min_attacker to avoid calling attacks_bb when moving a royal king).

[Nordlandia]

Wild9 or TwoKings

Also, consider this position, with black to move :

White : Kf4 Rg7 Rh8 Black : Kd8 Pa2

It looks like Black is in checkmate. But, in fact, he has one legal move, which is 1.. a8K . This creates a King on the a-file, and hence transposes royalty. Of course black is still lost after RxK. But this is an interesting legal possibility.

[ianfab]

@Nordlandia I think neither Stockfish nor cutechess nor ICC allow promotions to kings in TwoKings. For the latter I am not entirely sure, but for Stockfish I certainly know that I have not implemented that because I have never heard of that rule for TwoKings/wild9 before. I know there are variants of wild9 that allow king promotions, but wild9 itself does not, at least as far as I know. For SEE such special cases would anyway be irrelevant.

[Nordlandia]

@ianfab okey. It's mentioned here: http://www.chessvariants.com/invention/kings

[Nordlandia]

Website operator on Green Chess variant site [zoldsakk.hu/en/] implemented Two Kings but with slight modified rules. Pawns can promote to kings and the reigning king can escape checkmate by pawn promotion also known as transfer royalty.

[ianfab]

@Nordlandia Ok, so it is just some alternative rules, but not the "standard" Two Kings variant, right? I was a bit confused, because your first post in this thread kind of suggested that it was a normal rule, so I was wondering whether there is a bug in my implementation.

Since it made the code simpler, the implementation in principle already supports n-Kings out of the box (if you set up such a position via FEN), but the promotion to king is not implemented. It could maybe be added as a subvariant, but the move generation and validation for king promotions would probably be tricky to implement.

[ddugovic]

Maybe (if ever) we start porting variants to Rustfish supporting n-kings and king promotions for all variants (via a new subvariant/rule setting) will be feasible.

[Nordlandia]

Also king-promotion make the variant not eligible for syzygy format, as suggested earlier. Current two kings is very similarly to regular chess. Once both non-royal kings get traded off it's standard chess.

[ianfab]

@ddugovic I would be surprised if porting to Rust solved the dilemma between generalization and performance, but I would be glad to be proven wrong.

[ddugovic]

@ianfab I agree, I too am pessimistic about n-kings being feasible as I describe (and at present I dare not attempt to maintain such a change without the compile-time guarantees offered by Rust).