Comments/Ratings for a Single Item
H. G. Muller wrote on Sat, Jun 29, 2019 09:16 AM UTC:Note that saying 'check' is something amateurs do; in official games this is even forbidden. In that light it seems the following convention could be useful for this game at amateur level, to help enforcing the checking rule (which might strike ordinary chess players as unusual):
A player that attacks a castle and suspects it might be checkmate can say 'check'. This obliges his opponent to point out at the end of his next move the Castle where his King takes shelter. If that Castle cannot be captured, the game just continues, because even if there was a genuine check it has apparently been resolved. If it can be captured, the player that pointed it out could be ruled to lose, or (in a more forgiving spirit) could be obliged to acknowledge his mistake and point out another Castle (or conceed he has been checkmated or played an illegal move).
As to notation: this is not really part of the game rules, and for orthodox Chess several systems exist (descriptive notation, coordinate notation, long/short algebraic notation). I don't particularly like the notation proposed here; personally I would just stick to an existing standard, like SAN. (Also for the reason of being able to process it with existing software.) This is based on identifying a move by mentioning the type of the moving piece and the target square, possibly augmented by as many coordinates of the starting square as is needed to distinguish it from other legal moves that would be witten the same without disambiguation.
Turnover Chess offers two new aspects one usually does not have to deal with: piece types are 'fluid', and besides capture there are the possibilities of (friendly) combination and turnover. in SAN one makes the distinction between capture and non-capture by inserting an 'x' symbol, (problematic on board with more than 23 files, but then, more than 26 files would be problematic anyway...), although this is redundant, as it is fully implied by the occupation of the target square. Apparently it is considered so helpful to make this distinction jump out that it is worth the redundancy. This would then likely be true for combination and turnover as well.
My first idea was to write any move to a non-empty square with 'x', but that would not distinguish combination / turnover from true capture. It is possible to make this distinction within the existing framework of SAN, however, by using promotion suffixes: any move that would not lead to the expected occupation (i.e. the outermost ring of the moving piece) of the target square could be written as a promotion to what does result. The use of 'x' would be determined by whether the former occupant of the target square was friend or foe. So Qe3 would be a non-capture, putting a Bishop on e3, while Qxe3 would in addition have captured an enemy there (Knight, Queen, Bishop or Castle). Qe3=Q would have absorbed a frienly Rook, Qxe3=K would have turned over an enemy Pawn. In all cases a Rook would be left behind, but that is implied in this game, and so common that it does not warrant introduction of more redundant symbols in the notation.
Some more remarks: I think that using K for Knight is a really bad idea. It is mega-confusing to chess players. Even if you don't have to use 'K' for indicating another piece type, it would be better to keep N for Knight. After all, you kept the names of the orthodox pieces, while they are really not pieces at all but just constellations of rings. You might as well keep their standard abbreviations. Not distinguishing Castles and Pawns in notation is probably also undesirable (even if they move the same). So I would always mention a Castle as C, (a good reminder for what is left behind), while Pawn moves could follow the normal SAN rule of using no type indicator at all, but always prefixing a 'x' symbol with their file coordinate. This remains unambiguous here, as Pawns can only have come from 3 squares to reach the mentioned target square, and only true captures can change file.
[Note that saying 'check' is something amateurs do; in official games this is even forbidden. In that light it seems the following convention could be useful for this game at amateur level, to help enforcing the checking rule (which might strike ordinary chess players as unusual):
A player that attacks a castle and suspects it might be checkmate can say 'check'. This obliges his opponent to point out at the end of his next move the Castle where his King takes shelter. If that Castle cannot be captured, the game just continues, because even if there was a genuine check it has apparently been resolved. If it can be captured, the player that pointed it out could be ruled to lose, or (in a more forgiving spirit) could be obliged to acknowledge his mistake and point out another Castle (or conceed he has been checkmated or played an illegal move).]
- I agree we don't need to say check. Just need pay attention to checkmate, because of course if you are in checkmate, the game is over and all other move is an illegal move.
- I played a few matches with the obligation to point out every Castle under attack and I did not dislike it, but sometimes we moved a piece and did not realize that the move resulted in check on some of opponent's Castle, and I did not like can't be able to attacking this Castle for not having said check, it totally distorts game.
- Turnover allows you to checkmate in more than one Castle at same time. I've already finished a match with 3 Castles in checkmate and it's nice to talk check and check again, seeing the opponent's face when realizing there are a lot of Castles in check. I would have to test this possibility further.
- See it on: https://www.instagram.com/p/By00QZ9DhoG/
- See it on: https://www.instagram.com/p/By00QZ9DhoG/
[As to notation: this is not really part of the game rules, and for orthodox Chess several systems exist (descriptive notation, coordinate notation, long/short algebraic notation). I don't particularly like the notation proposed here; personally I would just stick to an existing standard, like SAN. (Also for the reason of being able to process it with existing software.) This is based on identifying a move by mentioning the type of the moving piece and the target square, possibly augmented by as many coordinates of the starting square as is needed to distinguish it from other legal moves that would be witten the same without disambiguation.]
- I agree. Notation is a world and I just bring to myself a version to be able to take notes of my test matches to be able to animate it after. So I have learned a lot about notation and created mine. Of course each player will use his own notation system, its not a rule.
[Turnover Chess offers two new aspects one usually does not have to deal with: piece types are 'fluid', and besides capture there are the possibilities of (friendly) combination and turnover. in SAN one makes the distinction between capture and non-capture by inserting an 'x' symbol, (problematic on board with more than 23 files, but then, more than 26 files would be problematic anyway...), although this is redundant, as it is fully implied by the occupation of the target square. Apparently it is considered so helpful to make this distinction jump out that it is worth the redundancy. This would then likely be true for combination and turnover as well.]
- Well, the two points ":" I used to highlight a turnover, was just marketing :) Thinking in a future where two points is a kind of trademark, icon or turnover brand. Its not essentially needed. We don't need to differentiate if it is a friendly combining or a turnover.
- x mark is so cute :( it gives dopamine :) when you take an opponent piece. I agree it can be redundant. If I take, instead use x to indicate a take, just notate which piece is seated on square gives the same result and x will be unnecessary. I will try notate some matches to see it better.
[My first idea was to write any move to a non-empty square with 'x', but that would not distinguish combination / turnover from true capture. It is possible to make this distinction within the existing framework of SAN, however, by using promotion suffixes: any move that would not lead to the expected occupation (i.e. the outermost ring of the moving piece) of the target square could be written as a promotion to what does result. The use of 'x' would be determined by whether the former occupant of the target square was friend or foe. So Qe3 would be a non-capture, putting a Bishop on e3, while Qxe3 would in addition have captured an enemy there (Knight, Queen, Bishop or Castle). Qe3=Q would have absorbed a frienly Rook, Qxe3=K would have turned over an enemy Pawn. In all cases a Rook would be left behind, but that is implied in this game, and so common that it does not warrant introduction of more redundant symbols in the notation.]
- Just write the result is good. Instead QxQe3, just Q.e3 as I write or Qe3 is fine, but less exciting in therms of x as "hey have you seen? I take it!". I use a point to diferenciate move and combination, Q.e3 = "Queen moved to e3" so it is its Bishop going to e3 and Rook left behind... and Qe3 = "A Queen was mounted in e3", so evidently there is a Rook in e3 to be able to perform Qe3. I like it.
[Some more remarks: I think that using K for Knight is a really bad idea. It is mega-confusing to chess players. Even if you don't have to use 'K' for indicating another piece type, it would be better to keep N for Knight. After all, you kept the names of the orthodox pieces, while they are really not pieces at all but just constellations of rings. You might as well keep their standard abbreviations.]
- I like it. N is better. Friends said I need keep distance from chess, so I suppose use K was a way to try keep this distance, but N is good.
[Not distinguishing Castles and Pawns in notation is probably also undesirable (even if they move the same). So I would always mention a Castle as C, (a good reminder for what is left behind), while Pawn moves could follow the normal SAN rule of using no type indicator at all, but always prefixing a 'x' symbol with their file coordinate. This remains unambiguous here, as Pawns can only have come from 3 squares to reach the mentioned target square, and only true captures can change file.]
- I have tested it a lot, and it is really not needed to diferenciate C and pawn. When I start a match I just write a3 and it is a Ca1 goint to c3.
Here is a version where Pawns turnover Bishops and Queens in diagonal forward. This change was made to test this variation rule in how pawns must handle takes and turnovers. Check it up!
https://glukkazan.github.io/checkmate/turnover-variant-board.htm
Special thanks to: Jim Diego, from skype discussion. Skype: boardgameturnover
H. G. Muller wrote on Mon, Jul 1, 2019 12:55 PM UTC:Initially I liked the logic of treating recombination/turnover as a non-capture, and true capture as a capture. But when I was thinking about notation, it struck me as even more logical to only treat the recombination as non-capture (i.e. straght Pawn moves), and turnover and true capture as capture (i.e. diagonal Pawn moves). Because only the latter two move types really gain anything; the recombination you can undo any time you want. So recombination is more like a noncapture, where you happen to be allowed to stay with multiple pieces in one square. My SAN notation scheme would only use 'x' for true capture and turnover (the latter with promotion suffix).
I have no idea whether this would actually make a better game. And it is of course silly to let convenience of a notation system influence the rules. But is strikes me as more elegant.
Here is a match with Pawns handling turnovers on diagonal forward:
https://www.youtube.com/watch?v=hyppzlkwjj4&feature=youtu.be
I played a few matches with the PawnFreetoCombine version and I have to be honest, I can not play the previous version again. Much more intuitive and uncomplicated, definitely elegant and sincere. I will change this rule soon.
Probable new variant rule: Castle in check, move like chess King.
After hundreds of Turnover matches I have done, I finally realize that something is missing in the context of game logic. Since in traditional chess, at least two pieces are needed to perform a checkmate, with few exceptions on stucked Kings, I realize that this kind of complexity on checkmates is needed on Turnover too. So, I found a way to let it works, featuring the rule where a Castle in check, move like a King from traditional chess. It can move and take one square all around it.
The results is incredible, games have grown in logical complexity and I dare to say that finally it is better than chess.
Now I am discussing it with my developer to bring us a version with this change, so we all can test it. See on: https://www.facebook.com/groups/turnoverchess/permalink/3357003974392091
Enjoy.
Bn Em wrote on Tue, Jun 18 12:16 AM UTC:The most recent change to this page removes all description of the rules, directing the reader to an external site. This seems undesirable.
H. G. Muller wrote on Tue, Jun 18 04:55 AM UTC:This is the most original and inventive chess variant I ever encountered, and I like that very much. I agree that the current submission is not suitable as a rules page, though. We do have pages for external links, and it can be used as one of those. But it would be a pity if there is no full rule description of Turnover on this site.
That accessing the rules link requires a login is of course a deal breaker...
The author, Lúcio José Patrocínio Filho, has updated this page.
H. G. Muller wrote on Thu, Jun 20 01:06 PM UTC in reply to H. G. Muller from Tue Jun 18 04:55 AM:The link now points to an accessible website. But this website unfortunately contains a very incomplete rule description. The most essential part seems to be missing (namely that a move consists of moving only the outer-most ring of a combination).
H. G. Muller wrote on Thu, Jun 20 05:49 PM UTC:(Unfinished) test Diagram:
Ughh! Trying to implement the turnover transformation and splitting rules through a custom xxxTinker script revealed a bug in the parsing of the captureMatrix. Instead of ignoring promotion to its own type, it ignored promotion to the type just before it in the table.
After fixing this, I think I got the normal moving right. Promotion is still to be done.
H. G. Muller wrote on Sat, Jun 22 08:52 AM UTC in reply to H. G. Muller from Thu Jun 20 05:49 PM: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.)
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
H. G. Muller wrote on Sat, Jun 22 09:21 PM UTC in reply to Michael Taktikos from 07:55 PM: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
H. G. Muller wrote on Sun, Jun 23 07:23 AM UTC in reply to Michael Taktikos from 06:24 AM: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)
H. G. Muller wrote on Sun, Jun 23 09:38 AM UTC in reply to Michael Taktikos from 08:38 AM: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.
H. G. Muller wrote on Sun, Jun 23 10:51 AM UTC in reply to Michael Taktikos from 10:44 AM: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
H. G. Muller wrote on Sun, Jun 23 03:56 PM UTC in reply to Michael Taktikos from 12:51 PM: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%
25 comments displayed
Permalink to the exact comments currently displayed.
From chessvariants.com some intusiasts of turnover, asked about interesting themes. Here they are:
From wdtr2:
I am wdtr2 from chessvariants.com
Your game looks very interesting, reading the rules I have a few questions.
1) I do not know what the startup looks like
My guess (white) is
PPPPPPPP
RNBQCBNR
in the standard chess startup mode
Am I correct?
2) how does a castle move?
Guess: I moves like a king
3) What does the word disambiguation mean? I don't understand.
In your rules you said:
====================
When a White Rook in e1 combines with a Black Bishop in e5:
:Qe5 (when desambiguation is not needed)
Re1:Q5 (when desambiguation is needed)
When a White Rook in e1 combines with a White Bishop in e5:
Qe5 (when disambiguation is not needed)
Re1Q5 (when desambiguation is needed)
==========
:Qe5 and Qe5 (above) -- I think one of those has improper notation.
The text, from above, came from chess variants dot com
I feel the ":" should be mandatory. Where : means combine
Full notation would be
Re1;Be5:Qe5
Shortcut notation would be
:Qe5
Where ":" is mandatory - it means Combine
4) Can you expand the rules on splits and improve the documentation of splits?
For example: Image a Castle at e1. I am going to use the character ^ as split.
Ce1^Pe1;Qe5 Full notation where ";" is a separation character
Ce1^Ne1;Re5
5) Can you update the rules on what pieces can split into?
For example Knight can split into Pawn and Bishop
6) suggestion: I would like a rule change. Check and Checkmate do not exist. I want to introduce a new term. "Soft Check"
1) Soft check is only "on" when you have only 1 Castle
2) When you move a piece, and after the move completes, you need to say "Check". If you do not say check, you can not capture the castle on the next turn, but your move is valid.
3) With the design of "soft check", a castle may move next to a queen (even if you only have 1 castle). On the next move your opponent can not capture
the castle because your opponent did not say check. This gives the Castle a little more power, you can then always butt castles against castles. This idea is only valid, if the castle moves like a king.
7) If you only have 1 castle and you move to rank 8, it will not promote to queen.]
In Response:
The startup looks like CCCCCCCC. But why this need to be like that?
Castles are resources
Players will dispose its resources along the game as they wish.
It adds tactic and strategy to the game, because management of resources is one of the best mechanisms to be used in strategic games.
The King is inside a Castle.
But which Castle is he in?
He will be on last Castle. This is why players need to checkmate the last Castle.
How does a castle move?
What does the word disambiguation mean?
Notation needs to be simple and smart at same time.
So it is much more clever you notate moves results and disambiguate it if needed.
Better than that and still more fun is notate combination results like when you combine your own pieces
If you have a Bishop in a1 and want to combine it with your Rook in c3, so you just need notate Qc3 instead of Ba1Rc3^Q. And if you have a disambiguation, like if you have a Bishop in e1 too, so to make a Qc3 is possible moving either Ba1 or Be1, so you need notate Ba1.Qc3, making big notation just to disambiguate it. But to be more clever, it can be done just notating Ba1.Qc, because Bishops just move in diagonal, so if it goes from a1 to c of course it is c3. So finally the result is Ba1.Qc.
Can you update the rules on what pieces can split into?
Let me say that on first solution for this game there was no checkmate, but finally it gets bored, because checkmate is a very smart move, it needs much more powerful reasoning, it is so clever that computers just was able to perform a checkmate a few years ago, because its is hard to perform, so it represents the power of human mind and it needs to happen in a chess game and its variants. This is why I finally changed turnover to perform a checkmate, and the solution was imaging a King covered inside one of the castles, which turned the game much interesting because on real life in middle ages, kings sometimes fight inside its castles.