Comments/Ratings for a Single Item
Zillions of Games comes with a game called 'Double-Move Chess (Checkmate),' whose description says, 'Checking the opponent is only allowed on the second move.' To test whether it enforced this rule, I played both sides. After moving all four center Pawns forward, I captured the Black King with two moves from the light-squared White Bishop. The game went like this: e2-e4, d2-d4; d7-d5, e7-d5; B f1-b5, B b5-e8. Although the rule was stated in the description, the ZRF did not enforce it.
I'm thinking the two moves should be of different move-types. The second move can first check whether the enemy King is in check. For example, preceed each move of the second move-type with (no-check?). Link all spaces on board with next direction. (define no-check? mark a1 (while (or (not-piece? King) (not-enemy?)) next) (verify not-defended) back) This searches for the enemy King's position, verifies whether its position is defended, which means the current player is threatening that space, then returns to the position of the piece moving.
I've had an additional thought on how to make a Marseillais Chess ZRF more optimized. Between each player's first and second move, have a dummy player check whether either King is in check, placing a piece on a specified location if either King is in check, and clearing the same space if no King is in check. Then on the second move, each piece just verifies that this space is empty before moving. This will eliminate a whole lot of overhead caused by multiple checks of whether any King is in check. It might also be useful to use two spaces instead of one. Checking both spaces could be done with an or. Doing this would reduce a bit of overhead. There could be two dummy players, a white dummy and a black dummy. Each could first check for a marker indicating that it's side is in check. If so, it would check whether it's still in check. If it was empty, it would not have to check whether it's in check. In either case, it would check whether it's side has placed the other side in check. Another advantage of this would be the presence of visible check indicators for each side. Zillions does not normally tell you when you're in check. This would be a nice side effect of implementing the game in this way.
I have completed Zillions implementation of a simplified version of Marseillais Chess, which I call Simple Marseillais Chess. Implementing the rules for en passant would have been very tricky, and there seems to be nothing I can do about getting it to accept checkmate as a goal. So I just let myself create a new version of the game, then implemented that. The simplified version is played like Chess with these differences: 1. Each Player normally has two moves per turn. 2. The second move of a turn is allowed only when no Kings are in check. 3. Although a Pawn may move twice in a turn, it may not make the two-step initial move available in Chess. 4. Pawns may not capture each other by en passant. 5. The object is to capture the enemy King. 6. 3-times repetition is a loss. 7. A player who cannot move must pass.
I don't know much about Marsellais, I have tried it a few times with a novice status, but I have not analyzed rare situations and fine details. I think this move can NOT be done, en passant movement is a Pawn move in which you capture an enemy Pawn moved INMEDIATELY before the en-passant capture. In your example, after the Pawn move you moved other piece in the second part of the turn. I think it is the same if you move the Pawn twice letting it in a position in which en-passant is permissed, you can't take the Pawn because the last move was not a two-steps move in the same PART of the turn, you moved one square in the second part of your turn, and this is the last move to the effects of the game. This is an interesant discussion, and it must be clarified by experienced players. If we are rigurous with the Chess rules that I suppose are translated to Marsellais, if you move a Pawn two squares and it lands in a position in which it can be captured en-passant, and after that you move other piece, this is the last move, so the Pawn can't be captured en-passant, but if you move first the other piece and after that the Pawn, it is vulnerable to en-passant capture, so order can be important to the effects of the application of this rule. Has someone an 'official' response?.
I've understood the interpretation of en passant capture to mean the capturing player makes the en passant move 'as soon as legally available'. For example, if the initial double-step pawn move results in a discovered check, the check must be dealt with, then, on the next turn, if the player is not again in check, the pawn may be taken en passant, if that move is still available. A series of checks would 'push' the en passant capture along with it. The checks could even be ended by the double capture move originally suggested. If that move, the en passant capture ameliorating check, was available, then it would have to be taken then, or the en passant opportunity would be lost. This could theoretically occur in a FIDE game, no? Anyway, the en passant capture would then be available to the other player during his next move, which would have to be the one-move capture, and not the two-move non-capture. In which case, the situation described would be a serious blunder, or a brilliant sacrifice. This does not hold if Roberto is strictly right, and there is a voluntary pass by the opponent, for, theoretically, the opponent could have, instead, made a voluntary en passant capture between the non-capturing moves.
No, I'm wrong about en-passant rule. It states: 'A pawn that is moved two squares in one move (half a turn) can be taken en-passant, even if the pawn moved in the first half of the turn. The en-passant taking should be done on the first move of the turn. However, when two pawns can be taken en-passant, this is allowed.' I have to see the comment that is going to be displayed in a few hours, because I'm now a bit confused with Antoine's question. Some clarifications are needed about rare cases, I expect that an experienced player can give detailed explanations about it.
Interesting question! I always take 'en passant' by pushing my opponent's Pawn back to the third rank and then capturing it in a normal fashion. The result is the same as if I forced my opponent to retract his two-step Pawn move and then make a different move with the same Pawn. Marseillais Chess rules lead to considerable confusion here. I would be tempted to say that Black may capture the N(c3) in Antoine's example, but may not perform an en passant capture of the P(c4). We may find out that this question has been dealt with before.
This implies that the opponent cannot capture two men with one en passant move.
Thanks to Doug, it answers Antoine's question, and it swhows that my initial interpretation was not wrong as I though: 'My interpretation of the 'two moves per turn' is simple: after you move the first move of your turn, the other player is forced to 'pass', as a permissed (and obligatory) 'move' in this game, and after completing the turn with your second move, the two-moves turn is available for the other player.'
To paraphrase Betza, the Queen's ability to do 'two things at once' makes it worth a Pawn more than a Rook and a Bishop. My last game of Marseillais Chess leads me to the opinion that Q=R+B exactly in this variant, as the two separate pieces can both move in the same turn. The subject of Marseillais Chess piece values deserves further study.
The fact that one of the best chess players of all time (Alekhine) took the trouble to play at least one game of this variant may count for something.
In trying to tentatively estimate the value of the pieces in this variant, I'd guess that the long range pieces may be worth, say, one and a half times what I give them as in standard chess. Thus: P=1; N=3.49; B=5.25; R=8.25; Q=15 and the fighting value of K=4 (though naturally it cannot be traded).
Wow, this rule change makes a big difference to the game of chess!
The sample games were finished in 4, 7, 18, and 13 moves - each move certainly has much more influence on the game play.
I've been trying to think of ways to "add power" to the game "Chess on an Infinite Plane" without adding more or stronger pieces. This might be a good way to do it (but maybe with some limitations).
Is there anyone who would like to try such a game? I'm open to any new and innovative ideas. If you have any favorite pieces, we can try those also (but I'm looking for more than just a mix of new pieces).
The games in play for Chess on an Infinite Plane are going well so far. I'm just interested in a version which might somewhat amplify the game power a little.
A request was made on another thread for games scores and/or analysis of Marseillais. I ran a self-play match with ChessV using about 12 total hours of thinking. Here is the score:
1. c2c4 b7b6,c8b7 2. b2b3,c1b2 b7g2,g2h1 3. f1g2,g2h1 e7e5,d7d5 4. b2e5,d2d4 b8c6,c6e5 5. e2e3,d4e5 a8c8,f8b4 6. b1d2,a1b1 d5c4,b4d2 7. d1d2,b3c4 c7c5,d8d2 8. e1d2,d2c3 h7h6,c8d8 9. b1b6,b6b7 g8e7,h6h5 10. b7a7,a7b7 f7f6,f6e5 11. g1f3,f3e5 e7c6,c6e5 12. f2f4,f4e5 e8g8,f8f2 13. b7d7,d7d8 f2f8,f8d8 14. e5e6,a2a4 d8d6,g8f8 15. h1f3,h2h3 g7g5,h5h4 16. f3b7,a4a5 g5g4,g4g3 17. a5a6,b7g2 d6e6,e6a6 18. c3d3,d3e4 a6d6,d6d2 19. e4f5,f5g4 d2g2,g2g1 20. g4h4,h4g4 g3g2,f8f7 21. g4f5,f5e4 g1a1,g2g1=q 22. e4d3,d3c2 a1f1,f1f2 23. c2d3,d3e4 f7e6,g1g6 black wins by checkmate
Also, there have been 12 games completed on Game Courier. You can find the game logs by following this link.
I expect 23 moves is probably in the neighborhood of what a well-played game of Marseillais should last. Double moves lead to sharper tactics and bloodier games. For example, defending a piece doesn't necessarily accomplish much, since the opponent can use his two moves to take the piece and then move the attacker away to a safe location (a kind of hit-and-run.) Also consider that each move is really two moves, so this game had the equivalent of about 45 moves of conventional chess.
Unfortunately, if you run this test with ChessV it is going to crash. There's a bug I discovered when trying to run this that I first had to track down and fix. The version I recently posted was a "release candidate" to get it out into the wild so I could get people doing more testing and reporting problems. So far about a dozen bugs have been found and fixed. I hope to release an update shortly - possibly this weekend. Then you'll be able to run similar tests. The short explaination is that there was a bad interaction between the double-move and the code that handles en passant.
Why 12 hours? Somewhat arbitrary. The longer you let it think, the deeper it can think. But the time required to reach the next level of depth increased exponentially, and the exponent can be quite high. To reach enough extra depth to make a difference in skill might require a couple of days.
I should also point out that Marseillais is different enough from standard chess that we don't really know how to best program a computer to play it. We are in uncharted waters here. Almost certainly there are changes that need to be made to the standard chess algorithm for proper play of double-move variants, but we do not yet know what those changes are and it will take a lot of study and experimentation to find them. If you're really interested in the details, chess programs have something called Quiescent Search that is very important, but this concept doesn't really work for double-move variants and it is not clear what should replace it. You can read about quiescent search here.
But, all that said, this score is of what is probably one of the highest quality games of Marseillais ever played. Humans don't really know how to play it well either. Every aspect of standard Chess has been studied deeply for hundreds of years. But, as you saw for yourself when you went searching out samples games and analysis for double-move variants, there isn't much available. But stay tuned. This is an area that will hopefully see more development in the future. Now that there is a GUI that can run double-move games, hopefully some other chess programmers will make engines that are capable of playing them.
I ran the game giving each side 8 hours on the clock. Didn't wind up using all the time, though, because the game ended first. You never really know for sure how much time you should use for any given move because you don't know how long the game will last.
Regarding Chess on a 12 x 12 Board, I've played a few games here. You can find the logs on Game Courier. It seems there is definitely a use for "flanking" - going outside and around. You can get a rook moving on the very first move if you want.
While fixing a bug in the Game Courier code, I came across a situation that is not clearly covered by the rules. Suppose a Pawn makes its usual first-move double move, then it moves forward one more space on the same turn, so that it moves a total of three spaces forward. Can it be captured by en passant if the opponent has a Pawn in the usual position? On the one hand, it has made a double move, and a Pawn that makes a double move can normally be captured by en passant. On the other hand, it is no longer on the space it moved to when making its double move, and if the player had wanted to, he could have moved the Pawn forward one space, then captured the Pawn that was in a position to capture it by en passant if it had made a double move.
For now, I have written the code to forbid en passant capture in this situation. Does anyone know if there is any precedent for allowing en passant capture in this situation?
This is tricky, and different players have used different rules. This page states:
According to Pritchard's Popular Chess Variants, 'The en passant rule has seen change. Modern players allow it only when the Pawn advance formed the second move of a turn.'. This helps to eliminate some ambiguity discussed in the comments. (What if a player advanced a Pawn by two squares, then occupied the intermediate square with a piece?)
The situation is potentially even worse than this example. What if a pawn made a double move and then went on to capture a piece with its second move? Would capturing it en passant then magically bring back the piece it captured?
There was a discussion about this on the talk chess site a few years ago. The discussion went on for quite a while and a lot of people weighed in. I can try to dig up the thread, but the final outcome was that there is really only one interpretation of en passant makes sense and doesn't lead to problems: the en passant capture must be made with a player's first move and can only be used to capture a two-space move by the opponent's second move. If a player makes a two-space pawn move with the first of his two moves, it is not subject to en passant. ChessV uses this interpretation and I believe Game Courier should do the same.
In any case it should be clear that you can never capture a piece after it moved away with the second move, just because it was in a location after its first move where you could capture it. It would be highly illogical if e.p. capture would be an exception to that. Whether you want a second move done with a different piece to destroy e.p. rights is a matter of choice.
I changed it to allow en passant only when the Pawn's double move is a player's second move, and I confirmed that this change did not break any past game. But as I was rewriting the rules, one more thing occurred to me. Suppose a Pawn's double move done on the first move puts a King in check, thereby ending the turn without a second move. If this check could not be ended with an en passant capture, this could allow a King to be checkmated in a position that would not be checkmate in Chess, and this would violate the intention behind the game.
So, I think we have to exclude the rule that en passant is allowed only when a Pawn makes a double move on the second move of the turn. This could be replaced with the rule that en passant is allowed only when the double move was the opponent's last move, or it could be replaced with the rule that en passant is allowed only when the Pawn that made a double move didn't make another move after it. For the meantime, I'll change it back to the latter.
Well, another move should clear the e.p. rights generated by any previous move. Like it always does. E.p. rights are transient, and last only to the end of the next move. (And not to the end of the next turn!)
Yes, I should have said en passant only allowed if the two-space pawn move was on the player's most recent move (rather than second move) to account for this. I just tested this situation and ChessV does allow en passant to get the king out of check. It is implemented as H. G. suggests - any move clears the EP square.
The earliest source I can find is Pritchard's 1997 Encyclopedia, which is the source Hans originally used to write this page. It says "En passant is legal if the opponent moved a pawn two squares on either of his moves but the capture must be made at once. However, if the opponent made two two-square pawn moves, both pawns can be taken e.p. This last rule is credited to Alekhine by F. Palatz in an article on the subject (LEC Sep 1928)." LEC refers to L'Echiquier. Notably, Alekhine is not one of the inventors, and how the game should handle en passant might be something that the original inventors didn't think of. It is also unknown whether the game was invented by Fortis or by de Queylar. It has been attributed to each one, but its origins are murky.
Regarding one of the alternative rules, it says "The game was sometimes played with alternative rules: a check on the first move was illegal and a player could not capture e.p. if the pawn had been moved in the first part of the player's turn." It's very possible that Fortis and de Queylar invented similar games with slightly different rules that eventually got conflated together.
The rule that Greg Strong and H. G. Muller propose has the advantage of being the simplest to program. It works with code that has already been written for Chess. Of course, the original inventor of the game would not have had this in mind, since programming games was not an option when it was invented. However, the rules as initially described above can be programmed, and that's what I have done in Game Courier. The only issue with them is that they need emendation for a Pawn that moves twice on the same turn. If we keep those rules, then en passant capture should be impossible in this instance, or it should be allowed for the Pawn on its new space. I have the former programmed right now, whereas the latter would be trickier to program.
So if the player moved a pawn two spaces and the placed a piece on the square passed over you would allow capture of both with a single move? To me, that doesn't fit comfortably with the spirit of chess. Pritchard notes that the rule has changed over time, probably for good reason. Similarly, Marseillais Chess is now played in 'balanced' form because it is clearly superior. Old games do evolve and that's a good thing.
Here is the thread on Talk Chess where this was discussed. In it I actually started iwth Fergus' view and was persuaded to adopt my current view.
What I cannot imagine is that the original inventor would have thought it reasonable to allow e.p. capture
- when the capturing Pawn has not seen the other one move past it
- when the Pawn that moved is no longer there
- when the e.p. square gets occupied
So if the player moved a pawn two spaces and the placed a piece on the square passed over you would allow capture of both with a single move?
The way it is coded, that would not happen. The first thing it checks for is an ordinary diagonal capture. If the move involves one, that's what it does, and it doesn't get around to checking for an en passant move.
I have started to look at the thread you provided a link to, and I will continue to look at it tomorrow.
What I cannot imagine is that the original inventor would have thought it reasonable to allow e.p. capture
- when the capturing Pawn has not seen the other one move past it
- when the Pawn that moved is no longer there
- when the e.p. square gets occupied
That's all reasonable, and what I've coded for Game Courier is in conformity with it. The first one is already handled by the rule that en passant is not allowed on the second move unless the player is making two en passant captures. This prevents a player from using his first move to move a Pawn into position to do an en passant capture. (Note that a Pawn that was already in the position to do this could just capture the double-moved Pawn normally and then use its second move to go to the space the now captured Pawn had passed over, reaching the same position without using en passant.)
The second is handled by setting the ep1 variable to false whenever a player moves the same Pawn again. Since ep1 would store the position of the previously moved Pawn if the last move were a Pawn move, it checks whether the second move is from that location.
The third is handled by checking for a normal capture before checking for other types of Pawn moves. If the move is a normal capture, it never gets to the code for en passant. If it's not a normal Pawn capture, then the move was to an empty space. By the time it reaches the elseif clause for en passant, it has already been determined that the space is empty.
One more issue has come up. Suppose that a player makes a first move that leaves him with no legal second move. Does this end his turn like a checking move would, or does it end the game in a draw? Pritchard says in Popular Chess Variants, "A player who is not in check and cannot complete his turn is stalemated." This suggests the latter, but he could have said it more explicitly if that is what he meant. Is there any consensus on how being unable to move on the second move should be handled?
Tough Question. I could see the 2nd move being "pass", and if Marseillas is a mandatory 2 move game per person, it is a strong arguement that it is a stalemate. You are the programmer to the game, I would pick the one Fergus Likes, and make sure it is mentioned in the rules.
It seems logical to me that stalemate must be a result of one player's move making it impossible for the other player to complete his move(s). Intentionally "stalemating" yourself on your first move so you have no legal second move seems like it should be illegal - an illegal move. If left with any set of 2 legal moves to be played, a player should be compelled to make those moves.
If, for example, a player can only move his pawn, that pawn starts on b7, and an enemy pawn is on b4, that player should not be allowed to make the pawn double-move on move 1, but rather make 2 separate single-square moves.
I support that interpretation. The pair of moves should be legal, and a first move that only occurs in illegal pairs should therefore be considered illegal itself.
One can compare this with the handling of the touch=move rule in FIDE rules, which also makes a turn a two-event action: lifting a piece, and then dropping it. If I play Carlsen with black, and start touching Ra8 after his opening move, I cannot claim a draw on the basis that this Rook has no moves, and I am not in check, so that its a stalemate. I simply must grab another piece to move.
I hadn't thought of that interpretation, but it is more computationally complex than the ones I was considering. It would involve testing a position for legal moves, then trying out each legal move and testing it for legal moves until at least one legal move is found. Also, I normally handle checking for stalemate in the Post-Game sections to minimize its computational cost, but if a move were to be illegal if it had no follow-up move, the code would have to check for double levels of stalemate in the Post-Move sections, and that would significantly raise the computational load of the code.
The two interpretations I was considering were to allow only one move when no second move is legally available or to end the game in a draw when a second move is not available. Another alternative would be to end the game as a loss for the player who does not have a second move available. This would discourage players from deliberately stalemating themselves just as well as making it illegal would, and it could be done with far less computational complexity.
I would consider the latter solution perfectly acceptable. In my Shogi engines I use something similar for Pawn-drop mates; rather than engaging in time-consuming testing whether the move is legal, just reverse the score of a checkmate when the previous ply was a Pawn drop.
I don't know if the interface already commits the user to the first move after he entered it. If not, and he can still take it back, you don't really have to do anything. Whatever he does for the second move will be rejected as illegal, so sooner or later he will decide to try another first move.
Using the Zillions-of-Games version of Marseillais Chess by Young-Hyun Joo, I moved pieces until I got a position where one side used the first move to move into a position with no second move. When I tried to move again, it declared the game a draw.
While I generally don't like the idea of a player being able to draw a game by stalemating himself, it is also a difficult thing to do until the endgame, and giving each player two moves should normally allow the player who is ahead to force checkmate all the more quickly. So, in this game, it may mitigate the greater advantage of the player who is ahead and give the player who is behind greater hope of being able to draw the game without really making the game too drawish.
This rule comes from a reading of Pritchard, and given how he mangled all of my games that ended up in the revised version of his Encyclopedia, I don't trust him. But he is also the only source I have. I would like to find the article written by Fortis, but it may not be on the web. Since I don't have a serious objection to it, and since it is computationally less expensive than some other options, I'll probably go with it unless someone has a more authoritative historical source than Pritchard.
Checking how en passant works in the same Zillions script, it works as I have programmed it except that it allows the capture of two pieces when a piece has moved to the space a pawn just passed over with its double move. I suspect that if capturing two pieces at once were allowed, this would have been mentioned explicitly in the rules. My interpretation is that since en passant means "in passing," the idea is that an en passant capture happens during the pawn's move and not after another move. In that case, the new piece would not yet be on that space when the en passant capture actually happens, and a double capture would not be possible then. Given this, a pawn who captured by en passant on that space should itself be captured, leaving the piece that moved to that space still standing. But this would overcomplicate the game, and it is easier to say that moving the piece there caused the enemy pawn to lose its chance to capture by en passant but compensated for this by giving it another piece to capture. So, I don't support allowing double captures.
I don't know if the interface already commits the user to the first move after he entered it. If not, and he can still take it back, you don't really have to do anything.
This comment popped up while I was writing my last one. The interface does not commit a user to a move until it is complete.
Whatever he does for the second move will be rejected as illegal, so sooner or later he will decide to try another first move.
That's how it currently works. A player without any legal move on his second move is unable to proceed and must go back and make a different move to complete his move. The problem comes in when a player has only one legal move, and that puts him in a position without any more legal moves. In that case, the player is unable to move at all, and all he can do is resign or wait for the clock to time out. I would rather have something cleaner than that.
I think I figured out how to interpret the rule in a way that uses stalemate but avoids the problem of letting a player deliberately move into stalemate. This is the interpretation that if a player does not have any combination of two legal moves, the game ends in stalemate at the very beginning of his turn. I could do it like this. After checking for regular check and stalemate in the Post-Game sections, I could try out the available legal moves to see if any are followed by legal moves, stopping as soon as I find at least one. For this, I would use a subroutine that returns false as soon as one legal move is found and does not take the time to go through all possible moves and calculate a list of legal moves. Since there are plenty of legal moves when lots of pieces are on the board, and a position without any combination of two legal moves would be most likely in a position with few pieces left, there should not be a heavy computational load for doing this.
I somewhat like the notion that a player can't make a first move that puts himself into stalemate if there is an alternate sequence. Unfortunately, this would be extremely difficult for me to implement. Like Zillions, ChessV handes multi-move variants by treating each leg as a separate move and implements the double move by adjusting when the side-to-move is flipped. To implement this, I would not know if a move is legal without generating moves another level deep, and that would be a radical modification. In practice, I think this would almost never come up in a real game. I had a hard time even coming up with a position where I could test this.
So far as I know, there is no other xboard engine that plays Marseillais (or another GUI that enforces the rules.) I really hope that changes. To that end, I'm not inclined adopt an interpretation that makes it substantially harder to make a fully compliant engine to address a situation that is extremely rare at best.
Don't get me wrong - when trying to nail down the rules for classic games, ability to program them shouldn't be the top concern, and certainly shouldn't constitute a veto of clearly defined rules. But the classic rules are in doubt, very likely were played with different interpretations at different times (to the extent these corner-cases were even considered), and the rules have been evolving.
57 comments displayed
Permalink to the exact comments currently displayed.