Ratings & Comments
Here are the rules of Chess66 as I've written them up for Game Courier. Apart from a change to the naming convention for the new spaces, is this complete and fully accurate? Note how I've divided this into five sections. These are the geometry of the board, the difference that Switches make, how spaces in a Switch count as separate spaces, how spaces in a Switch are sometimes treated as the same space, and how the individual pieces move.
Rules of Chess66
Chess66 is an adaptation of Chess to a board with a different geometry. Where no difference from Chess is noted, it follows the rules of Chess.
- Its board has two extra spaces that each overlap with a neighboring space and push the rank it is on over by half a space. A4 overlaps with a4, pushing the 4th rank half a space right. H5 overlaps with h5, pushing the 5th rank half a space left.
- Because its ranks and files no longer line up neatly on a Cartesian grid, movement is based only on geometrical relations and not on the coordinate system.
- Lateral movement is allowed through the sides of spaces, and lateral movement in the same direction goes through the opposites sides of spaces. Because of this, vertical movement may sometimes shift the file named by the coordinate system.
- Diagonal movement is allowed through the corners of spaces that do not share any sides, and diagonal movement in the same direction goes through the corners at opposite ends of spaces.
A Switch is a pair of overlapping spaces that come together at one end and branch off at the other. In doing so, they allow some new movement options:
- At its narrow end, each space in a Switch shares the same side with an adjacent space. This allows a Rook or Queen to move through the narrow end to one of two different files. In this way, a Rook or Queen can checkmate a King without assistance from another piece.
- From the broad end, a Rook or Queen can move through the Switch to the same file, providing a new way for double attacks to work.
- Also at the narrow end, each space in a Switch shares a corner with another adjacent space that neither one shares any sides with. Through this corner, diagonal movement is able to change color. So, a Bishop that moves to A4 or to H5 may move away on a subsequent turn on a different color. This allows Bishops to switch color, giving a Bishop the power to reach every space on the board.
Although the two spaces in a Switch overlap, they count as separate spaces.
- A piece moving to a Switch must move to one space or the other. For example, a Pawn on a2 can make a double move to either A4 or a4.
- While some paths can lead to either Switch, others lead to only one space or the other in a Switch. For example, a Bishop on e8 can go to A4 or h5, and a Bishop on d1 can go to a4 or H5.
- The movement options available to a piece on a Switch depend upon which space of the Switch it is on. For example, a Pawn on A4 can proceed only to a5, and a Pawn on a5 can proceed only to b5. Also, a Bishop on A4 can move away on either light or dark spaces, but one on a4 can move away only on light spaces.
Because the two spaces in a Switch overlap, they are treated as the same space in some respects:
- The two spaces in a Switch cannot be occupied simultaenously.
- It is illegal to pass through a space in a Switch if the other space is occupied.
- A piece may move to a space in a Switch only if both spaces in it are empty or one is occupied by an enemy piece. If a piece moves to the empty space in a Switch, and the other space is occupied by an enemy piece, that piece is considered captured.
- It is not legal to move from one space in a Switch to the other. Instead, A4 is treated as though it were horizontally adjacent to b4, and H5 is treated as though it were horizontally adjacent to g5. This affects the movement options for Rooks, Queens, Kings, and Knights
The King leaps one space in any lateral or diagonal direction. It may castle with a Rook on its first move so long as it is not in check, there is nothing in between it and the Rook, it doesn't pass through check while castling, and the Rook hasn't moved. In castling, it moves two spaces toward the Rook, and the Rook moves to the space the King passed over.
The Queen may move as a Rook or a Bishop.
The Rook may move any number of spaces in any lateral direction until it reaches an occupied space or Switch.
The Knight can leap directly to any space that could be reached in two one-space moves except for those reachable by two in the same direction. Since a piece on A4 or H5 can move directly to b4 or g5, a Knight on one of these can leap further away than a Knight can normally leap.
A Bishop may move any number of spaces in any diagonal direction until it reaches an occupied space or Switch.
The Pawn may move one space straight forward without capturing, or it may move one space diagonally forward to capture. On its first move, it may move two spaces forward without capturing so long as it isn't blocked. If this move takes it over a space an enemy Pawn could have captured it on, that Pawn may immediately capture it by en passant, moving to the space it passed over. On reaching the last rank, it must promote to another piece. This may be any piece except a King or another Pawn.
This has been published. I have edited the text to improve the grammar and clarity. It could still be better, but is acceptable. Thank you for your patience.
Thank you very much, and thanks again for your kind reply!
I hope you have a nice day!
@Greg,
I'd like to make chessV play custom variants against another chessV copy where the small parameter would yield different results. May you write a small guide on how to do that?
The definition of the Knight move is not correct. On an undistorted board it would allow the Knight to also move like Wazir or Ferz. This could be fixed by also excluding moves that are reachable in a single step.
Diagonal movement is allowed through the corners of spaces that do not share any sides, and diagonal movement in the same direction goes through the corners at opposite ends of spaces.
Let me understand this correctly: A bishop on e8 moves in the direction of switch A4/a4. Further down in your description you say that in this case the bishop can only reach A4. But the bishop reaches the same corner of A4 and a4; therefore the bishop can decide whether to stop on A4 or a4.
So, in principle, a move into the switch, no matter from which direction and valid for all pieces, must result in a decision between the two squares of the switch - provided that the switch is not occupied.
My description for this is:
- Finally, you can move into a switch from below, from the side or from above. If the switch is not occupied, then you can choose whether the piece that moves into the switch is on 4 or a4 or 5 or h5 after the move. If the switch is occupied, then the piece in the switch must be captured; the opponent’s piece takes the place of the captured piece.
2. While some paths can lead to either Switch, others lead to only one space or the other in a Switch. For example, a Bishop on e8 can go to A4 or h5, and a Bishop on d1 can go to a4 or H5.
See the comments above.
A bishop on e8 or d1 can move to A4 or a4 respectively to h5 or H5.
Also, a Bishop on A4 can move away on either light or dark spaces, but one on a4 can move away only on light spaces.
But a bishop on A4 cannot move to f8. For that he would have to be on a4.
3. ... or one is occupied by an enemy piece. If a piece moves to the empty space in a Switch, and the other space is occupied by an enemy piece, that piece is considered captured.
A piece can only be captured on the square it stands. Therefore, in an occupied switch, you cannot move to the empty square and capture the piece on the other square of the switch. After the move into the occupied switch, the capturing piece stands on the square of the captured piece.
The Knight can leap directly to any space that could be reached in two one-space moves except for those reachable by two in the same direction.
I am not sure if the rule is correct. In my description I use a definition which comes from Alfred Pfeiffer (Chemnitzer Schachverband e.V.):
- The knight moves to one of the squares that a king can reach from the square in two moves, but which are not on the same row, line or diagonal. It does not move across squares that lie in between.
Unfortunately, there is no way to do this at present. ChessV can be used to test changes to its parameters by playing against another engine, but as far as I know there are no other engines capable of playing your games. You certainly could run two instances of ChessV but they won't talk to each other.
I need to separate the game representation used in thinking from the one in the GUI. This would not only allow testing of different parameters but would also make multi-threaded thinking possible.
Ok, Thanks
The description of the King's Flight is not clear on whether the King can leap over another pieces. It cannot, based on the Zillions ZRF also by Sidney LeVasseur. I will update this page to clarify.
Let me understand this correctly: A bishop on e8 moves in the direction of switch A4/a4. Further down in your description you say that in this case the bishop can only reach A4.
Correct.
But the bishop reaches the same corner of A4 and a4; therefore the bishop can decide whether to stop on A4 or a4.
No, it cannot. Let me break the move down into steps. First, the Bishop on e8 moves to d7. At this point, movement in the same direction must go through the opposite corner is just passed through. This is the corner that d7 shares with c6. Continuing in the same direction, it can go to b5. At b5, it can move diagonally to A4, because b5 and A4 share a corner but no sides. Also, this is in the same direction that the move from e8 to b5 was in. However, b5 and a4 do share a side, which means that movement from one to the other is not diagonal. So, a move from e8 to a4 would be illegal.
So, in principle, a move into the switch, no matter from which direction and valid for all pieces, must result in a decision between the two squares of the switch - provided that the switch is not occupied.
No, that is completely the opposite of how I understand the rules.
A bishop on e8 or d1 can move to A4 or a4 respectively to h5 or H5.
This is unintelligible. If you mean what you said above, it is contrary to my understanding of the rules.
Also, a Bishop on A4 can move away on either light or dark spaces, but one on a4 can move away only on light spaces.
But a bishop on A4 cannot move to f8. For that he would have to be on a4.
That is correct, and I didn't say anything to the contrary. The light path from A4 goes through b3, c2, and d1.
- ... or one is occupied by an enemy piece. If a piece moves to the empty space in a Switch, and the other space is occupied by an enemy piece, that piece is considered captured.
A piece can only be captured on the square it stands. Therefore, in an occupied switch, you cannot move to the empty square and capture the piece on the other square of the switch. After the move into the occupied switch, the capturing piece stands on the square of the captured piece.
Are you saying that a piece cannot capture a piece in a Switch unless it can move to the space the piece is on? Or are you saying that when a piece can move to either space in a Switch, it can move to the Switch and capture the piece, and then it must occupy the space the piece was on?
The Knight can leap directly to any space that could be reached in two one-space moves except for those reachable by two in the same direction.
I am not sure if the rule is correct. In my description I use a definition which comes from Alfred Pfeiffer (Chemnitzer Schachverband e.V.):
- The knight moves to one of the squares that a king can reach from the square in two moves, but which are not on the same row, line or diagonal. It does not move across squares that lie in between.
They are the same, but I removed the ambiguities in his description and used some technical language. Since the King cannot move into check, and a Knight is not subject to the same restriction, I replaced the reference to two King moves with one to two one-space moves. Since I would normally refer to ranks and files rather than to rows and lines, and since I have been using these words in an algebraic sense rather than a geometric sense, I rewrote it to not use them. To "leap directly" is technical terminology that implies that a move "does not move across squares that lie in between."
Email verification not working (I have checked the spam folder).
No, it cannot. Let me break the move down into steps. First, the Bishop on e8 moves to d7. At this point, movement in the same direction must go through the opposite corner is just passed through. This is the corner that d7 shares with c6. Continuing in the same direction, it can go to b5. At b5, it can move diagonally to A4, because b5 and A4 share a corner but no sides. Also, this is in the same direction that the move from e8 to b5 was in. However, b5 and a4 do share a side, which means that movement from one to the other is not diagonal. So, a move from e8 to a4 would be illegal.
This is a very special consideration. Do you think that such can be communicated to potential players?
Why do we leave out consideration of equal/different corners and sides? Can't we agree that switches can be entered from all sides and a choice must be made between the fields of the switch? Surely that would be much easier for everyone.
In the discussion at the time, I just took your position, but ran into a wall looking for a simple solution. I came to the conclusion that switches have a special status, which must lead to a choice between the fields of a switch from all sides - from above, from below and from the side.
No, that is completely the opposite of how I understand the rules.
A bishop on e8 or d1 can move to A4 or a4 respectively to h5 or H5.
This is unintelligible. If you mean what you said above, it is contrary to my understanding of the rules.
What can I say? I think my position is quite logical. At the beginning of the discussions, I was of the opinion that switches work differently when they are operated from below, from the side, or from above. I have abandoned this opinion and changed it in favor of a pragmatic solution, in that a switch must be handled the same regardless of the direction.
Are you saying that a piece cannot capture a piece in a Switch unless it can move to the space the piece is on? Or are you saying that when a piece can move to either space in a Switch, it can move to the Switch and capture the piece, and then it must occupy the space the piece was on?
This seems to me to be much simpler than you make it out to be.
After all, a piece can only be captured where it is. Why should this be different for a switch?
Why should a piece be able to move to A4, and thereby capture a piece on a4 quasi en passent? That only happens with pawns. But that's where it should stay. The basic principle should be that pieces are captured on the square on which the pieces were placed. Pragmatic solution, isn't it?
They are the same, but I removed the ambiguities in his description and used some technical language. Since the King cannot move into check, and a Knight is not subject to the same restriction, I replaced the reference to two King moves with one to two one-space moves. Since I would normally refer to ranks and files rather than to rows and lines, and since I have been using these words in an algebraic sense rather than a geometric sense, I rewrote it to not use them. To "leap directly" is technical terminology that implies that a move "does not move across squares that lie in between."
I think I have understood that.
Why do we leave out consideration of equal/different corners and sides?
I have not done that. I consider equal ones equally and different ones differently, which is what makes most sense.
Can't we agree that switches can be entered from all sides and a choice must be made between the fields of the switch? Surely that would be much easier for everyone.
No, it would not be easier for everyone. This makes the game more confusing and complicated, because paths to and from Switch spaces are no longer symmetrical with each other. This would allow one King to attack another, and the following position would count as checkmate.
I think my position is quite logical.
It's not logical. At best, it is not outright contradictory.
At the beginning of the discussions, I was of the opinion that switches work differently when they are operated from below, from the side, or from above.
That's the position which makes the most sense, because it makes how Switches work a consequence of the geometry of the board.
I have abandoned this opinion and changed it in favor of a pragmatic solution, in that a switch must be handled the same regardless of the direction.
This conflicts with the rule that the space a piece is on in a Switch determines how it may move away. While you could have both rules, it makes the game more confusing.
Are you saying that a piece cannot capture a piece in a Switch unless it can move to the space the piece is on? Or are you saying that when a piece can move to either space in a Switch, it can move to the Switch and capture the piece, and then it must occupy the space the piece was on?
This seems to me to be much simpler than you make it out to be. After all, a piece can only be captured where it is. Why should this be different for a switch?
I was asking you to clarify which of two possible interpretations of what you said is the correct interpretation, but you didn't do that.
Why should a piece be able to move to A4, and thereby capture a piece on a4 quasi en passent? That only happens with pawns. But that's where it should stay. The basic principle should be that pieces are captured on the square on which the pieces were placed. Pragmatic solution, isn't it?
In both of the alternatives I asked you about, the capturing piece ends up on the space the captured piece was on. But you have not indicated which you have in mind. So, let me illustrate the difference.
In this position, can the Black Pawn capture the White Pawn and move to A4? Or is the Black Pawn unable to capture the White Pawn, because the move from c5 to A4 is not diagonal?
You can certainly scrap the entire concept.
I'm not sure which part of my comment you took as scrapping anything; certainly that was not the intent. Merely a minor note that your use of the word ‘maximum’ implied a liimitation I don't see
Mind games should be able to be discussed. Or do you have a different opinion?
I fully agree; if I differed in opinion there would be little reason for me continuing to frequent this forum. Did I imply something else?
At the beginning of the discussions, I was of the opinion that switches work differently when they are operated from below, from the side, or from above. I have abandoned this opinion and changed it in favor of a pragmatic solution, in that a switch must be handled the same regardless of the direction.
From what I remember, the discussion was limited specifically to movement via the side of a switch space: your original description allowed (rook) movement from A4 (using Fergus' notation) along the rank to e.g. b4, but not vice versa, breaking the usual assumption that slider moves are reversible. The ‘pragmatic solution’ you refer to was specifically to allow orthogonal slides from/via b4 to reach either of A4 or a4. It might be noted that disallowing all sideways movement from A4 would have achieved the same effect.
As far as I remember entry from the top of a switch, orthogonally or diagonally, was never controversial in this way, and as Fergus has noted unifying downward entry in the same way as for sideways entry leads to exactly the problem of asymmetry that unifying sideways entry was supposed to avoid.
This is an interesting game I'd like to implement, but the following is problematic:
4. As an exception to rule 1 above, you may capture a defended Golem or Half-Golem two squares away with a Golem or Half-Golem if it is the only legal move you have.
I don't have the ability to retroactively rule an otherwise illegal move legal based on the outcome of every other move. I doubt any chess engine is going to do this. There is a ZRF, and I've looked at it and don't believe it does this either, but I can't be 100% sure. I have changed computers several times since I last had Zillions installed.
Is this really so hard to implement? I had a somewhat similar situation in the Interactive Diagram for Tamerlane II, where 'King Succession' (swapping King with a Prince as a move) is only allowed when you are checkmated. (I suppose the 'only-move exception' here in practice also only occurs when checkmated, as it is hard to imagine you could be stalemated when you still have a Golem.) So I could handle it by some extra code in the section that handles mates once it is detected that you have no legal moves. This code is almost never executed, so there is no slowdown in normal play. It then testst whether succession is enabled, and if so, tries all possible swaps with pieces of the designated successor type.
In an analogous approach you could, in a position without legal moves, generate the illegal Golem captures, search those, and return the score of the best. Since you had already generated them as pseudo-legal moves, and then rejected them in the special legality testing code, you could have the latter code stash the moves somewhere, and let the mate-handling code retrieve them, so you don't really have to generate anything.
Code-wise it is much simpler to just redo the entire node under conditions where the GxG captures would be considered legal. All other moves would be immediate hash hits anyway. Like
Search(stm, alpha, beta, depth, legalGxG) { nrOfMoves = GenLegalMoves(stm, legalGxG); // the second parameter would suppress the special legality test on GxG if(nrOfMoves == 0) { // we are mated if(!legalGxG) { // well, maybe not really, as we might have rejected a GxG return Search(stm, alpha, beta, depth, TRUE); // redo allowing all GxG } return (incheck? -INF + ply : 0); // stalemate correction } for(ALL_MOVES) { // normal search ... score = -Search(!stm, -beta, -alpha, depth-1, FALSE); ... } }
You could try to be smart and let the re-search depend on whether there actually were any rejected GxG moves, but since you will virtually never be checkmated, efficiency here is not really relevant. It hurts more that you have to pass an extra parameter to Search. But you could use the e.p. square for that (assuming you pass that, to indicate where e.p. capture is possible). By setting it to the location of the captured G after GxG you could indicate this G is now fair game even when protected.
...because paths to and from Switch spaces are no longer symmetrical with each other. This would allow one King to attack another, and the following position would count as checkmate.
I can't see anything other than a checkmate situation. The legal moves of the black king are vertically a5 and a3, horizontally b4 and diagonally b5 and b3. The move to c5 is excluded and only with that can the black king free itself.
We had such a situation in the discussion below and it involved a bishop on A4.
Also, a Bishop on A4 can move away on either light or dark spaces, but one on a4 can move away only on light spaces.
But a bishop on A4 cannot move to f8. For that he would have to be on a4.
That is correct, and I didn't say anything to the contrary. The light path from A4 goes through b3, c2, and d1.
If the bishop on A4 cannot move towards f8, then the king on A4 cannot move to c5? On the other hand, the white king can capture the black king on A4. This is undoubtedly an asymmetry that, as I understand it, cannot be avoided when handling a switch.
I guess I didn't understand your question correctly. I'll try my best to answer.
The switch is occupied, so the black pawn can move diagonally into the switch. In my opinion, the black pawn does not have a choice between A4 and a4, but moves directly to A4 and captures the white pawn there.
satellite=golem
files=8
ranks=8
graphicsDir=/graphics.dir/alfaeriePNG/
squareSize=50
firstRank=1
lightShade=#FFFFCC
darkShade=#669966
holeColor=#663300
rimColor=#663300
coordColor=#D6DEAD
whitePrefix=w
blackPrefix=b
graphicsType=png
useMarkers=1
borders=0
enableAI=1
newClick=1
protected=5
protected=6
counterStrike=5
counterStrike=6
mateExemption=1
pawn::ifmnDfmWfceF::a2-h2
knight:N:::b1,g1
bishop::::c1,f1
rook::::a1,h1
golem::Q2:falcon:d1
value=1000
half-golem::Q2:slidinggeneral:
king::KisO2::e1
|
Golem Chess |
This is a (still imperfect) attempt with the Interactive Diagram. Even for this I needed to adapt the Diagram script: although the new move-entry system does allow promotion to enemy (as needed when capturing a Golem), the AI did evaluate it as if the capturing piece changed into a Half-Golem of its own color. The type changes are dictated by a user-supplied routine WeirdPromotion; this was the easy part.
Of course the AI assigns the same value to Golem and Half-Golem, as it uses mobility as only guidance. Having it upgrade the value because of a user-specified demotion of pieces that capture it seems asking for too much. That raises the question how to handle this. Perhaps the Diagram should have a parameter value that can be used to overrule the automatic piece-value assignment.
The Golem and Half-Golem are subject to the Diagram's anti-trading features of the protected and counterStrike kind. These also forbid trading of adjacent Golems, though. Actually I think it is a flaw that Golem Chess allows this. For a Lion an adjacent piece would be captured through hit-and-run, and protection would be ineffective and not lead to trading. This is why the Chu-Shogi Lion-trading rules are as they are. For the Golems it still leaves an easy way to trade those, though. Of course I could have the Diagrams protected feature exempt adjacent capture. That would even give a better representation of the Lion. But I intentionally did not do that to make it more useful for pieces that cannot rifle-capture...
And no special exemption for checkmate yet... In the Diagram this is more difficult, because it only rejects the illegal captures after search, in the daughter nodes. So it becomes more difficult to communicate to the parent the move was rejected for this reason, so it can decide to redo those.
[Edit] Hand-tuning of piece values through a value=N line with N in centi-Pawn immediately after the line with a piece definition is now generally supported. (And used here to set the Golem value to about double that of what its mobility would suggest. That seems reasonable; it is like having two Half-Golems on the same square.)
I took the discussion from earlier to heart and to that extent I thought about it and adjusted the rules. The result:
I find the idea that a bishop on d1 can only move to a4 or to H5, or a bishop on e8 can only move to A4 or h5, to be completely illogical.
You can bend it with corners and sides so that it seems logical, but basically, from my point of view, it leads to complicating the rules.
The rule that a switch is a place of decision to occupy the squares of a switch uniquely, no matter from which direction the switch is occupied, seems to be a clear rule that everyone can understand. I do not think that such a rule complicates the course of the game.
The concept implies that unsymmetrical move sequences cannot be excluded. I cannot express it in any other way.
This diagram isn't working properly. Capturing a golem is demoting it to a half-golem, but of the wrong side. The half-golem should be the same side as the golem was.
Flush the browser cache...
I found a loophole for easily allowing the forbidden trades as checkmate evasion, in the Diagram! There already was a parameter tradingThreshold, which served to implement Chu Shogi's exemption of 'bridge captures' from the Lion-trading rules: when you gain more than this threshold in the exchange, it is no longer forbidden to trade the protected piece. This can conveniently be used for suspending the anti-trade rule, by setting it to a large negative value. So in the mate-handling code (executed when after all moves have been searched bestScore is still at -15000) I added
if(exemption) { var h = threshold; threshold = -15000; exemption = 0; bestScore = AlphaBeta(stm, alpha, beta, eval, last, preLast, depth, borrow, ply); // redo without trade ban if(ply == 0) bestNr = bestScore; // needed because in the root we return the best move instead of the score threshold = h; exemption = 1; } else ... // normal mate handling
This redoes the search of the node without trade ban (with a cleared flag exemption set through a new mateExemption parameter to prevent infinite recursion).
That does the trick: If I set up a mate through a7-a5, Ke8-a4, Gd8-c6, d2-d3, switch on AI, and then Gd1-c4, it will play Gc6xc4. If I set up a normal favorable trade, like Rh8-h6, Ra1-a6, Gd1-f6, switch on AI, and then Gd8-h6, it refrains from Gf6xh6, even though that would gain it a Rook.
Code-wise it is much simpler to just redo the entire node under conditions where the GxG captures would be considered legal. All other moves would be immediate hash hits anyway.
I could certainly do something like this, and if I was writing a dedicated Golum engine I would. Sorry, I should have been more explicit. I am wondering if I can do it inside the framework I currently have (which of course you don't know in detail.) I don't want to add extra code to the search function that is specific to a single game. But you have given me an idea of how this might be incorporated into the framework in a general way that - hopefully - would be useful for other games.
Whenever a move is made, a MoveBeingMade message is sent to every Rule object, which can then return IllegalMove to deem it illegal. (For example, the CheckmateRule tests to see if a royal piece is attacked and returns IllegalMove if so.) I suppose I could add another possible return value - IllegalUnlessOnly (or words to that effect.) Moves with those returns would initially be unmade, as with illegal moves, but set aside. If there are only IllegalUnlessOnly moves, then they would all be made again and the IllegalUnlessOnly returns ignored. This would add a tiny bit of overhead, but only a couple of if-thens at each node unless the value is actually used.
Good job with the Interactive Diagram! It's pretty close to playing correct Golem Chess. And, since it's mostly for demoing a game, I don't think it's essential for the ID to impelment every minor rule. This is a pretty uncommon corner-case. The anti-trading rule only at range 2 is more common though. I made a similar decision to make it only applicable at range 2 in my game, Odyssey, which has been in ChessV for years but I have never gotten around to publishing.
Well, I don't see much difference between what I did and what you propose here, considering the different frameworks we have. And the frameworks aren't so different. It is just that I consult the equivalent of these 'rule objects' in the daughter node. But that is also after the move has been made, and when that move is deemed illegal it is also unmade, and ignored in the parent (because its score is -INF). I could also differentiate different shades of illegality in the return code, if I wanted (as any score below -INF would effectively cause the move to be ignored), and take special action for an IllegalUnlessOnly code, like stashing moves for conditional later search, without subjecting them to the particular rule that made the move illegale 'IfNotOnly'. (Note that a move could be illegal for more than one reason, though; a forbidden trade could also expose your King!) And I also reacch a point where it can be concluded that no other legal moves are available, where I then have to take action to have the stashed moves searched. (In my case because bestScore is still at -INF after all other moves have been tried.)
It is just that I am to lazy for this cumbersome stashing of moves. Instead of figuring out which additional moves have to be tried, I just try all moves again, including those that were temporarily rejected for the IllegalUnlessOnly reason, by redoing the entire node in a tail recursion. But this time with the 'rule object' that rejected the move temporarily disabled, so these same moves won't get rejected again. This is of course very inefficient (especially without hash table...), but since it is a 'never happens' case, code simplicity prevails over run-time efficiency.
I don't see this as a feature dedicated to a single variant, but as a general mechanism to switch off certain rules in the 'only-move' case. (It is not really only move: there could be several rule-violating moves that solve the mate. E.g. you might be able to capture the protected Golem with two different Golems.) But there have to be rule parameters that specify which rules can be switched off in this case. As I programmed it now I can only switch off the 'no trading when protected' rule. (Of course one can argue that this entire anti-trading business is pretty much a dedicated feature for Chu Shogi...)
BTW, this already turns out insufficient: the counter-strike rule can also have to be suspended. E.g. black Ka4, Pa5, Pd5, Gc6, white Nb4, Gc4. (Other pieces in start position.) White plays Nb4xc6, for a discovered check. Pd5xc4 could cure the checkmate, but the counter-strike rule forbids this after NxG.
So I must also create ways to switch off more anti-trading rules. The enforcement of such rules (as well as checking and baring) are controlled by a 'property word' for each piece type, where the bits correspond to the various rules. (When you click the 'move' header in the piece table these properties are shown behind the piece value, in parentheses.) I guess I could implement the mateExemption parameter as specifying a mask, with which the property words will be ANDed in case no legal moves were found during the retry.
25 comments displayed
Permalink to the exact comments currently displayed.
Can you watch Fluidity please, I can’t add new variants but I have 5+ of them in keeping ready.
So how can I add my piece to Piececlopedia?! If I can;)))