Looking for C developper

[Greg Strong]

This leads me to another ambiguity of the historic e.p. rule: What if I do a double-push followed by a non-capture of the same Pawn (e.g. e2-e4-e5). Am I now still allowed to capture that Pawn e.p., through f4xe3? What if he captured something in his second leg (e2-e4xd5)? When I e.p.-capture d5 now through f4xe3, will I get the captured piece back on d5?

Yuck! You had to go there

In this case I would say it shouldn't be allowed although I admit I have no good justification consistent with my opinion that your previous case should be allowed. Here I would say you can't capture en passant because the pawn is no longer on e4. I realise this is not really different than Sven saying en passant should not be allowed in the previous case because the en passant square is occupied.

I agree with your reasoning that the case for en passant in general is weaker in Marseillais. I don't like dropping it, however, because in my mind the goal of Marseillais is basically "orthodox chess with two moves per turn." Additional rules should be as minimal as possible IMHO to preserve the simplicity and beauty of this goal (subjective as that might be.) If we're going to break with tradition and add a new rule I prefer mine - you cannot make a two-space pawn move with your first move if it would be subject to en passant capture - rather than dropping en passant entirely. This resolves all problems while preserving the en passant rule.

What a mess. I think we should start a discussion on chessvariants.org to try to build concensus.

[hgm]

A so-far not suggested alternative is to say: "In orthodox Chess only Pawns can move twice per turn, (with restrictions), and for Marseillaise Chess we merely extend this to all pieces (and lift the restrictions)".

That would be equivalent to a double-move version of Chess with Shatranj Pawns (i.e. not having a double move). Then the e.p. issue would be reduced to what it is in orthodox Chess: when one side pushes the same Pawn twice in the same turn (and in that case it is all he can do in that turn!), that Pawn can be taken e.p.. The difference with orthodox Chess is that this now can happen on any rank!

But I think all in all (i.e. also considering how many people already use the rules we adopt), it would be best to use the 'modern rule' mentioned by Sven: only allow e.p. capture of a Pawn pushed on the last leg of the previous turn in the first leg of the current turn. That is also easier on the engine, which now doesn't have to remember more than one e.p. square, or e.p. squares from more than one leg ago. IMO this best conforms to orthodox Chess, where you also can only e.p. capture Pawns immediately after they have moved, and not when something has been moved in between.

And I really don't think that it would alter the neture of the game very much, whatever you would do. E.p. capture is quite rare.

[Greg Strong]

But I think all in all (i.e. also considering how many people already use the rules we adopt), it would be best to use the 'modern rule' mentioned by Sven: only allow e.p. capture of a Pawn pushed on the last leg of the previous turn in the first leg of the current turn. That is also easier on the engine, which now doesn't have to remember more than one e.p. square, or e.p. squares from more than one leg ago. IMO this best conforms to orthodox Chess, where you also can only e.p. capture Pawns immediately after they have moved, and not when something has been moved in between.

This works for me. It preserves en passant, confirms well with orthodox chess, resolves our issues, and has historical precident.

[Sven]

But I think all in all (i.e. also considering how many people already use the rules we adopt), it would be best to use the 'modern rule' mentioned by Sven: only allow e.p. capture of a Pawn pushed on the last leg of the previous turn in the first leg of the current turn. That is also easier on the engine, which now doesn't have to remember more than one e.p. square, or e.p. squares from more than one leg ago. IMO this best conforms to orthodox Chess, where you also can only e.p. capture Pawns immediately after they have moved, and not when something has been moved in between.

This works for me. It preserves en passant, confirms well with orthodox chess, resolves our issues, and has historical precident.

O.k. for me as well. So after the following double white moves, assuming a black pawn on e4:
d2-d4/d4xc5
d2-d4/Qd1-d3
d2-d4/Ra1-b1

there is no e4xd3 e.p. for black. And after
d2-d4/f2-f4

only e4xf3 e.p. is possible but not e4xd3.

Sven

[Greg Strong]

Great. Now we just need an engine and GUI

I will add support in my new variant GUI after I roll out the first version (which hopefully will only be a couple of weeks - almost ready but for a few loose ends to tie up.)

[hgm]

Well, WinBoard Alien Edition should have no problem supporting it, as variant multi.

[Greg Strong]

Well, WinBoard Alien Edition should have no problem supporting it, as variant multi.

How do you supply multiple moves? "d2d4;e2e4"?

[hgm]

Comma-separated.

As it was implemented a bit as a kludge, it uses an asymmetric way to communicate the moves engine->GUI and GUI->engine, though. The engine would always send the various legs in separate 'move' commands, the non-final legs suffixed by a comma. The GUI sends them in a single line.

When the GUI is entirely unaware of the game rules (the default rules for variant multi are those of orthodox Chess...), the user would have to indicate whether an entered move is the final leg or not. He can do this by keeping Ctrl pressed on non-final legs, which suppresses stm change (just like a comma suffix suppresses stm change on wtext moves). This turned out to be quite inconvenient (because you tend to forget it).

So the later versions of the Alien Edition do accept engine help for this, through the 'highlight' command. In response to the 'lift SQR' command, send by the GUI when the user grabs or selects a piece with the mouse on SQR, the engine can answer with a 'color FEN' to indicate which squares the piece can be released on. The GUI uses that for legality checking (it won't accept you releasing the piece on a non-colored square), and some colors have special meaning (e.g. magenta triggers the promotion popup). In particular, releasing the piece on a cyan square suppresses the stm change, and thus allows the user to enter another leg. As the moved piece stays selected in this case, WinBoard will immediately send a new 'lift command', and the engine can respond with a 'highlight' command for the second leg of that same piece. That is convenient for Lion moves, but perhaps a bit confusing for Marseillaise, where you would usually select another piece (which through the lift-highlight protocol would then highlight its moves, this time not in cyan, but in yellow/red, because now they are turn-terminating moves).

So basically a Marseillaise engine would have to respond to 'lift' command with highlighting the moves of the piece in cyan on the first leg, and in yellow/red on the second. That way the user does not have to worry about whose turn it is anymore. The engine can enforce any kind of progressive variant this way. In fact there is no reason anymore to have a special variant multi that enables multi-leg moves. The engine can enable them whenever it wants. (But only when legality testing is off. With legality testing on, highlight commands are ignored.)

[Evert]

You know, I think I could make Sjaak play this with relatively little extra work. Flipping the side to move is handled by a field within the move struct, so it would already be easy to make it not flip the side to move. The extra difficulty is doing it every other move instead, but I think I've thought of a way to do it that isn't too hacky.

EDIT: wait, so what is the rule on how turns progress? Does white get two moves on his first turn, or not? I always thought he didn't, but it does raise a problem: when I am fed a position, can I assume that the side to move has the right to make two moves? If I can, do I have to check if the position I receive is the starting position? Or do we need a way to indicate this in the FEN itself? Say, "W" means white can play 2 moves, "w" means white has already played the first move and only gets one (that way the standard chess startup FEN is the same for Marseillaise: white gets a single move at the beginning of the game). Or perhaps a more general "w2" meaning "white to move, 2 legs remaining" with "w1" simply being written as "w".

[Greg Strong]

You know, I think I could make Sjaak play this with relatively little extra work. Flipping the side to move is handled by a field within the move struct, so it would already be easy to make it not flip the side to move. The extra difficulty is doing it every other move instead, but I think I've thought of a way to do it that isn't too hacky.

EDIT: wait, so what is the rule on how turns progress? Does white get two moves on his first turn, or not? I always thought he didn't, but it does raise a problem: when I am fed a position, can I assume that the side to move has the right to make two moves? If I can, do I have to check if the position I receive is the starting position? Or do we need a way to indicate this in the FEN itself? Say, "W" means white can play 2 moves, "w" means white has already played the first move and only gets one (that way the standard chess startup FEN is the same for Marseillaise: white gets a single move at the beginning of the game). Or perhaps a more general "w2" meaning "white to move, 2 legs remaining" with "w1" simply being written as "w".

In modern play, White does not get two moves on the first move. This was originally called "Balanced Marseillais Chess", but the "Balanced" is now almost universally dropped.

The FEN notation will need to be updated. I was thinking "w1" for white's first move, "w2" for his second, but I think I like your proposal better ("w2", "w", "b2", "b".) This way, the starting FEN is the same as orthodox chess.

That's great that you think you can get Sjaak playing this. We really need a double-move capable engine. Thanks for giving it a shot! Let me know if I can help.