Comments/Ratings for a Single Item
Hello HGM,
thanks for implementing this interesting variant in the ID engine. (Indeed so interesting, that I registered here and write my first message now :)
For giving the ID engine a sparring partner, I have implemented it in Zillions (It is the TurnoverEndgame.zrf, beside there is also a TurnoverOpening.zrf with simplified win condition, so that it can look deeper): https://drive.google.com/file/d/1zpwfCtoG-tUYk7CrPDQ6IjfHWhJYzP1E/view?usp=drive_link
To test the game with your start position, you can click on turnoverHGMStartposition.zsg (if Zillions is installed, of course)
Tried to test the zrf (10 sec/move) vs the ID diagram (2.5 ply), the first move was
- e3 Ke8xd8
The move of the Castle (= King) is illegal here. Hope to see a bugfix to test this interesting variant further
It seems I misunderstood the rules then, which is no wonder considering the awfully deficient description at the given link. I assumed that 'turnover' meant that you would combine the moving ring with what was present in the destination square, no matter what color the latter originally had. In that case Ke8xd8 would be legal. (Even though a bit pointless...)
Apparently 'turnover' only applies to enemy victims? Is it not possible to recombine your own pieces? Or is this included in what is described as 'move'?
I don't have Zillions.
The rules you mentioned are correct, turnover applies both to own and to enemy pieces.
But the illegal move Ke8xd8 doesn't look like a turnover (in this case, that would be a combinination King + Queen to a completely new piece), but looks like a castling King - Queen.
Moreover, the King has already all 3 rings, so all ring-combinations including that of the Queen are already integrated in him. So he can be separated into two different pieces, but there is no piece to combine with him for a turnover - such a turnover would result in a piece not existing in chess
I don't get it. The rule description at the link says the rules for moving a Castle (=King) are:
Castling:
The whole Castle can move one square for any side, except forward.
The WHOLE Castle can take the opponent's Castles, Fortresses, Towers and Walls one square for any side, except forward.
Its Wall can turnover Forts and Citadels one square for any side.
The third point seems to state that you can split off the Wall (= Pawn), leaving a Citadel (= Queen) behind, and merge the Wall with the existing Citadel on d8 to create a Castle there. The whole Castle should only move (leaving nothing behind) when moving the Wall would bring a bare Wall in the destination (i.e. when the destination was empty, or contained an enemy that should be captured rather than turned over). Forward moves are an exception to that latter rule; and are not allowed to capture in the first place.
Hm, before the 3 points you cited, there was another one in the rules, let's call it point 0:
Castle:
Its Wall can move or turnover one or two squares forward.
According to point 0, its wall can turnover one or two squares FORWARD, not sideways, and that makes sense, since the wall represents a pawn. I agree that point 3 you referred is expressed somehow unclear, leaving the impression that its wall can turnover in every direction including sideways, but that would contradict point 0.
An easy way to test the ID engine about legal moves and strength is to make a test game vs
https://dagazproject.github.io/checkmate/turnover.htm
(after setting the same startposition in the ID engine as in this site)
I agree that point 3 you referred is expressed somehow unclear, leaving the impression that its wall can turnover in every direction including sideways, but that would contradict point 0.
Well, it is obvious that it contradicts the behavior of that applet. I don't see any contradiction with the rule you quote, though; both sentences indicate that turnover is possible if you make one step forward. (And the only possible turnover targets are Fort and Citadel.) One would expect the castling description to apply only to the moves indicated in the diagram as 'castle' (i.e. white dots), which is indeed in every direction but forward. The first two points in the castling rules indeed make that exception. The third point does not have to make it, because it addresses turnover options, and the rule for forward moves already specified that these also exist for forward moves.
Note that the applet you refer to does allow friendly turnover for diagonally forward moves (but not to sideway moves). If I play b2-b3 (leaving a Citadel on b2), the next move I can play a1-b2 to turnover that Citadel. After c1-c2, c1-b1, c1-b1 it does not allow a1-cb1, though. So the applet doesn't treat all the castling squares the same way, which casts a lot of doubt on its correctness.
From a Comment by the inventor in 2020 I am starting to suspect that the castling moves are only allowed when in check. It is not clear what in check means in this variant, as it seems to have multiple extinction royals, and it is not illegal to leave those under attack. My best guess is that it applies to your only remaining Castle facing destruction. This is still a bit ambiguous, as without the castling move you could be forced to disassemble your last Castle, even if there is no external threat. The castling rule makes positions with a bare Castle (or Castle plus blocked Walls) viable, by allowing the Castle to stay a Castle when you move it (under zugzwang or to evade capture).
It is clear that the linked description is grossly inadequate...
[Edit] A demo game on facebook suggest that any Castle that could be captured on the next move is allowed to make a 'castling' move to evade the attack. But zugzwang forcing self-destruction does not enable castling, but results in the game ending as a draw there.
It appears the rules of this variant are still fluid. The start position of the applet is also different from the one shown in the article here.
It is clear that the linked description is grossly inadequate...
Yes, the description should be more precise, in the present form it lets much space for interpretations
Note that the applet you refer to does allow friendly turnover for diagonally forward moves (but not to sideway moves). If I play b2-b3 (leaving a Citadel on b2), the next move I can play a1-b2 to turnover that Citadel. After c1-c2, c1-b1, c1-b1 it does not allow a1-cb1, though. So the applet doesn't treat all the castling squares the same way, which casts a lot of doubt on its correctness.
So does my Zillions implementation. If the rules are incorrect interpreted by the russian author of the applet, then in a mysterious way I made the same misinterpretations, so that it happens that my zrf and the applet are implementations of the same game and can play a match against each other.
If you are still in touch with the game inventor, it would be good to know his statement, if this game, independently implemented in the applet and in my zrf, is the same game he had in mind.
So how do you explain a diagonally forward move of a Castle can turnover, but neither move the entire Castle nor the Wall to an empty square? None of the written rules remotely suggest such a thing, and neither does the diagram. It beats me how anyone could interpret the currently given rules this way; the interpretation of 'forward' as "straight or diagonally forward" does not hold either. There must have been a different rule description in the past.
I have no contact with the author, but he updated the article here 3 days ago.
So how do you explain a diagonally forward move of a Castle can turnover, but neither move the entire Castle nor the Wall to an empty square?
Here is only my interpretation (can differ from what the inventor had in mind!): "Last Castle", "Normal Castle attacked by enemy" and "Normal Castle not-attacked" are not the same piece and they should have different names.
The last Castle should be automatically promoted to a King who cannot move/capture diagonally forward, the entire King is moved and no parts of him (Betza notation WbF) and after the move this King isn't allowed to be in check.
A normal (not-last) Castle attacked by the enemy can (but is not forced to) move/capture like a King, but only to squares not attacked by the enemy. If the attacked Castle doesn't move at all and is captured, that doesn't matter
A normal (not-last) Castle not-attacked by the enemy can only use it's outer Wall (pawn) moves: either 1 or 2 squares forward if they are empty, or turnover with an own piece 1 or 2 squares forward or 1 square forward diagonal or capture an enemy piece moving like the above mentioned King (Betza WbF)
As mentioned, this is just my interpretation of the rules, it is not necessary the opinion of the game inventor, and probably not upto date with the inventor's latest rule changes. For my taste, the rules especially for the "Castle", which is obviously the same name for multiple pieces with different move combinations, are way too complicated to be remembered and should be simplified if possible
I think the rules changed at some point by adding this castling business, and that the applets play by the old rules, where a castle always decomposes. Apparently it was perceived as a flaw that castles could not be salvaged from check, or forced to decompose by zugzwang, and castling and stalemate were introduced as fixes.
I think this was a poor choice; the castling destroys the conceptual simplicity and elegance of this variant. If integral motion of a royal piece was desired, the logical solution would have been to make the king one of the atomic pieces. E.g. if de rings are designated L(arge), M and S, we could have L=K, M=B, S=R, LM=Q, MS=N, LMS=P. If you start with 8 LMS pieces, the victory condition could be that having no kings at the end of your turn loses. Your first move will create a K (leaving an N behind). A K then cannot decompose, and can capture a Q or P. It could turnover a B or N, but perhaps the rule should be that K cannot turnover, and only capture orthogonally.
The simplified rules you posted make sense, and are much easier to remember.
Especially that the game is lost with 0 Kings on the board, so that we have not to switch from non-royal to royal King, with each one having different move-combinations. And also that the King cannot turnover and only capture as Wazir, makes the over-complicated rules reasonable. Agree with your description 100%
12 comments displayed
Permalink to the exact comments currently displayed.
I think the Interactive Diagram now completely implements the rules as I understood those. To make this easy to achieve with the custom Tinker script, I had to make a few modifications in the standard betzaNew.js script powering Interactive Diagrams. In particular how it handles exemption of moves from the effects of morph and captureMatrix by dressing those with an apostrophe in the XBetza move descriptor, and how it resolves conflicting instructions specified in these two:
For one, the apostrophe now does not prevent a custom Tinker script for being applied to the move. If it is desirable that such a script only affects part of the moves, it can always be made smart enough to make that destinction itself. But it was inconvenient that moves that should excluded from the specified morphing/banning could then not be adapted in other ways (such as adding an unload on their origin square).
And I think I provided a more natural way to resolve conflicts between morph and captureMatrix: if the captureMatrix specifies a type change, it is executed first (even if the morph for the moved piece would have specified a different type change). But then morphing is applied according to the morph for that resulting type, rather than the original piece. This made it possible to implement the Turnover promotion rules by having Pawn and King morph into Queen on the last rank; even when a piece that was originally (say) a Knight 'unstacks' to split into a (moving) Pawn and a (remaining) Bishop, it is the arival of the Pawn (or the transformation that it brings about on a turnover victim) that triggers the promotion.
This behavior can be controlled with maxPromote, as it only applies to pieces that are not specified as promoting (the promotion purely controlled by morph, not by promoZone). For promoting pieces a morph specified for the moving piece would cause the captureMatrix to be ignored. (And one can always suppress promotion by zone for those pieces by setting promoZone=0.)