I am developing an engine to play this variant using WB as test gui.
In one of those tests I encountered a situation where WB adjudicates the game as draw (bare king) even if one side's king was already captured and the other side still has a king.
This is indeed very wrong. I am puzzled as to why it could happen. It seems to me WinBoard should already have adjudicated a checkmate on the move before. Instead it allows the checkmated King to move, and be captured. And I guess the "bare King" adjustment of the winning side to a draw should be moved backwards. I probably assumed there was no possibility that you could win in a regular way when you only have a King, but this is an example.
hgm wrote:This is indeed very wrong. I am puzzled as to why it could happen. It seems to me WinBoard should already have adjudicated a checkmate on the move before. Instead it allows the checkmated King to move, and be captured. And I guess the "bare King" adjustment of the winning side to a draw should be moved backwards. I probably assumed there was no possibility that you could win in a regular way when you only have a King, but this is an example.
I will investigate it.
Thanks, the ending rule of this variant is foolish .
Well, I vaguely remember there were some subtle rule differences on some ICS. Like that it is illegal to move into check, but legal to leave your King susceptible to destruction by an explosion on a neighboring square. (But illegal to bow up your own King.) So it is tricky, as I must not make rules that conflict with ICS rules, to keep WinBoard useful as ICS client.
hgm wrote:Well, I vaguely remember there were some subtle rule differences on some ICS. Like that it is illegal to move into check, but legal to leave your King susceptible to destruction by an explosion on a neighboring square. (But illegal to bow up your own King.) So it is tricky, as I must not make rules that conflict with ICS rules, to keep WinBoard useful as ICS client.
It is legal to move into check because the goal of the game is to remove the opp king either by explosion or by a capture. Stalemate is rare because the king that still have an empty square to move to, can move there regardless if that is attacked by the opponent. Once it moves there the opponent will capture it to win.
Black to play and lose.
[d]7k/6R1/8/5K2/8/8/8/8 b - - 0 1
OK, that explains why it did not adjudicate checkmate. I checked it out, and it seems that in the general GameEnd routine I put code to correct any win to a draw when the winner has <= 1 piece on the board (if there are no holdings, and it is not Suicide/Giveaway). I guess I was thinking that a win with only a single piece must have been a forfeit, and the single King would not have provided winning potential. In Atomic this is obviously not true, as your case shows.
hgm wrote:Well, I vaguely remember there were some subtle rule differences on some ICS. Like that it is illegal to move into check, but legal to leave your King susceptible to destruction by an explosion on a neighboring square. (But illegal to bow up your own King.) So it is tricky, as I must not make rules that conflict with ICS rules, to keep WinBoard useful as ICS client.
It is legal to move into check because the goal of the game is to remove the opp king either by explosion or by a capture. Stalemate is rare because the king that still have an empty square to move to, can move there regardless if that is attacked by the opponent. Once it moves there the opponent will capture it to win.
Black to play and lose.
[d]7k/6R1/8/5K2/8/8/8/8 b - - 0 1
bsetup atomic
Entering setup mode.
The game type is now atomic chess.
You are not observing any games.
bsetup fen 7k/6R1/8/5K2/8/8/8/8
bsetup tomove black
It is now black's turn to move.
Kg8
Illegal move (Kg8).
That is what I meant. The rules are not the same everywhere, so I have to be careful not to break WinBoard as Atomic client for either of those servers. So on FICS the shown game would have been declared a checkmate earlier.
But that just means WinBoard should not adjudicate checkmate in that position. Exempting Atomic from the bare King win -> draw correction is a safe change, however. I guess I could do better, to still apply it sometimes, but that is probably not worth it.
Now I understand why Pulsar without "fics" command line option, would
* castle out of check
[d]rnbqr1k1/pppp1ppp/8/8/8/Q7/PPPP1PPP/R3KBNR w KQ - 0 1
White king castles long.
ICC Help: atomic
Atomic chess (wild 27) is a chess variant in which any capture also destroys the capturing piece (or pawn) and any piece (but NOT pawns) in a one square radius (horizontal, vertical, or diagonal). There is no chain reaction -- only direct captures detonate. For captures en passant, ground-zero of the explosion is the square on the sixth rank upon which the capturing pawn lands.
Win by capturing or destroying your opponent's king without simultaneously destroying your own king. You may not make a move which destroys your own king. Check and checkmate are not recognized; you may move into check, castle out of check, or castle through check.
hgm wrote:That is what I meant. The rules are not the same everywhere, so I have to be careful not to break WinBoard as Atomic client for either of those servers. So on FICS the shown game would have been declared a checkmate earlier.
But that just means WinBoard should not adjudicate checkmate in that position. Exempting Atomic from the bare King win -> draw correction is a safe change, however. I guess I could do better, to still apply it sometimes, but that is probably not worth it.
Played an atomic chess game attempting to implement fics rule.
WB adjudicate the game as false win claim even though that king was already mated.
Black to play.
[d]r4bn1/4p2r/2n2pp1/p2p2Pk/1p4Qp/2P1P3/PP1P3P/R1B1K2R b KQ - 2 20
So the claim verification in WB follows the icc rule, that is destroying your opponent's king before claiming a win.
WB setting:
Test legality on
Verify engine claims is on
Detect mates is on
Is there an option in WB such that the claim will be based on fics rule?
.