Ratings & Comments

OK, I already downloaded Nebiyu 1.45 and unzipped NebiyuAlien; then double clicked on NebiyuAlien.exe and a window was opened but everything is black; there is only one blinking cursor; the window header says:

C:\Users\Carlos\Downloads\Nebiyu\NebiyuAlien.exe

But now I don't know what to do.

There are many more links on that page, which come into view when you scroll down. The Nebiyu version I know is at the link Nebiyu 1.45. There seems to be a newer version 1.5, but from the decription of it I am not sure it would be useful untill you train it first, and I never used it myself. IIRC the Nebiyu 1.45 package contains several executables (also covering games other than chess variants), but the one you should run for CVs is NebiyuAlien.exe. The game definitions for that are all in the file alien.ini, which is sort of self-documenting. The file starts with a series of piece definitions, after which a series of game definitions using those pieces follows.

There is Fairy-Stockfish, which is very much worth having. But it is not an independent app that goes accompanied with an installer. Just something you unzip in a folder of your choice, after which you have to point WinBoard to the executable through the Load Engine dialog, so that it can use it as an engine.

The same holds for Nebiyu, which is not as strong as Stockfish, but rather easy to configure for playing new chess variants.

Thank you very much for the info. Of the two, attracts me more Nebiyu. I'm somewhat confused on how to proceed with the installation because I don't see any link that be unique and clearly says "download". There are these 4 links:

egbbdll-cpu

egbbdll-gpu

nets-epd.zip

nets-ccrl.zip

Could you, please, tell me which of them to click? 

For the second, I would be grateful if you, Fergus, HG or anyone else tell me of any program (preferable of chess or chessvariants) that I could download.

There is Fairy-Stockfish, which is very much worth having. But it is not an independent app that goes accompanied with an installer. Just something you unzip in a folder of your choice, after which you have to point WinBoard to the executable through the Load Engine dialog, so that it can use it as an engine.

The same holds for Nebiyu, which is not as strong as Stockfish, but rather easy to configure for playing new chess variants.

Do you know what version of Windows 10 you are using? 

I'm using Windows 10 Home, 1903 version, operative system version 18362.476, installed on 14/Oct/2019.

My PC is a Compaq Mini CQ-1100, Intel(R) Atom(TM) CPU N2600, 1.60 GHz RAM.

Go in to the EnginesXBoard folder and delete everything underneath and then try running ChessV.exe again?

I already did it but the problem persists: no error message is issued nor the system crashes, it simply behaves as if nothing had happened.

In order to determine the cause there are 2 steps:

1) To install ChessV2.2 in other computer with Windows 10 Home .

2) To install in my PC another app.exe

For the second, I would be grateful if you, Fergus, HG or anyone else tell me of any program (preferable of chess or chessvariants) that I could download.

Ok, I had a thought.  Carlos, if you would be so kind, would you mind trying this?  Go in to the Engines\XBoard folder and delete everything underneath and then try running ChessV.exe again?

I included engines Fairy-Max, KingSlayer, and SjaakII.  When ChessV first runs, it will try to start each of those engines to determine their capabilities.  Perhaps one of them is failing and it is stopping everything...

Hi Carlos.  Thank you for the extra information.  Unfortunately, this does not make sense to me.  Do you know what version of Windows 10 you are using?  I know there is a "Windows 10 S" that can only run apps from the Windows App Store.  Other than that, I cannot imagine why it would not be possible to run a simple exe ...

Oh- ok- on further thought.  ChessV requires the .NET Framework while Winboard does not.  (The older ChessV used an older version of the .NET Framework.)  I would think you would get a better error message if that was the problem, but ...  Also, .NET Framework 4.6 is already installed on Windows 10 and should be compatible.  Does not really make sense.  Let my try something; I need to figure this out and I do not think that the problem is because there is no installer.

Greg:

When I double click on ChessV.exe it appears a window asking me if I agree the app makes changes in the device. After clicking "yes" NOTHING HAPPENS. It's disconcerting why does WinBoard 4.8.0 works while ChessV2.2 doesn't.

HG:

I already learned to drop pieces in Seirawan Chess. Thanks!

Regarding WinBoard 4.8.0, I don't know how to drop the Hawk and the Elephant playing Seirawan Chess against the Fairy-Chess engine.  After moving a piece, no menu appears asking you to choose which piece you want to drop. Could you, please, help me?

To gate in a piece you first select that piece in the holdings (by clicking it, so that the border highlight around it goes on), and then move the piece from the location on the back rank where you want to gate it in the normal way (click-click or drag-drop).

I have successfully tested on Windows 10.  What happens when you double-click ChessV.exe?  (It does not make button on the start menu)

Greg:

The same day you pre-released ChessV 2.2 I downloaded it but it does not work.

Recently I upgraded the OS from Windows 7 to 10. Save by the button sizes issue I still can run ChessV 2.1

I have archived the ChessV 2.2's 10 elements: 3 folders, 5 extensions and 2 apps, but Windows 10 may require programs to include an installer.

By contrast, some days ago I downloaded H.G. Muller's WinBoard 4.8.0 and I can run it perfectly; its logo appears listed in the Start Menu while the one of ChessV 2,2  doesn't, but the ChessV 2.1 logo yes appears listed.

I will look forward to the official release with installer included!

HG:

I will try to configure the Interactive Diagram as you say using the Bishop image for both Dragon Horse and Wazir.

Regarding WinBoard 4.8.0, I don't know how to drop the Hawk and the Elephant playing Seirawan Chess against the Fairy-Chess engine.  After moving a piece, no menu appears asking you to choose which piece you want to drop. Could you, please, help me? 

The new ChessV supports Symmetric.  You could give that a try.  I think I have also fixed your issue with the button sizes, although I can't be sure (since I could not reproduce it.)

In the Interactive Diagram images for the various piece types can be arbitrarily chosen. So there is nothing against representing the Dragon Horse and Wazir by the same image as the Bishop, so that the game state that determines how a piece depicted as a Bishop moves will become entirely hidden. But for the demo I wanted to make it clear what is actually going on.

For computer analysis the the conversion rule is probably not relevant for most of the game: the Bishops will both develop pretty quickly, and after that you are basically dealing with normal Chess on a 9x8 board. Most existing configurable multi-variant engines would allow you to specify an initial Wazir move on the Bishop, which would then enable you to set up the positions you want to analyze from the opening positions.

Thanks for your reply, HG.

What I'm looking for is an engine or computer program that allows me to analyze Symmetric Chess games with the idea of publishing them on YouTube, for which it would be very useful to have teaching resources such as those before mentioned: arrows, highlighting squares, etc.  

I think I could use the Interactive Diagram but I feel a bit unpleasant the fact that on the starting setup appear Dragon Horses instead of Bishops. Would it be possible to implement the Bishops Convertion Rule without the intermediation of neither Dragon Horses nor Wazirs? 

I made a set, painted runes on back of some wooden Scrabble pieces. Painted board on some soft leather. Love the game. I might have just called it Odin's Chess, and I'd have opted for priests with some twist, but overall I like its uniqueness. It has a root chess feel but is very much a rebuild from that foundation.

HG:

Your Interactive Diagram is undoubtedly an excellent resource to show easily the various ways of moving pieces.

Given your obvious computer skills, I wonder if you could develop a software that serve as support when analyzing chessvariants games just like many bloggers do with standard chess; features such as arrows indicating piece movements, highlighting squares of threatened pieces, soon return to the basic position after seeing one or more variants. For example, please take a look at this YouTube video. 

I mean to add said features to the Interactive Diagram. Or are they more typical of a video editor software? 

The definitive name of this game is 'Wildebeest Decimal Chess'. Is it possible to change the name of the corresponding preset (which I had called 'Wildebeest Chess Decimal') for the definitive name, without destroying ongoing and finished games?

I also just downloaded Chess V2.2. Great job. Thank you Greg for having included my game. No matter if you have it under its old name; but if it is a Release Candidate version, if the name could be also changed it would be more coherent with this page (even if the 2 names are nearly identical).

Treating the Bishop conversion rule as a piece-type change in the Interactive Diagram through a custom function WeirdPromotion() embedded as JavaScript in the HTML page:

  function WeirdPromotion(x1, y1, x2, y2, promo) {
    var piece = board[y1][x1]; // moved piece
    var type = piece & 511;    // strip off color and virginity bits
    if(type == 6) {            // convertable Bishop
      promo = piece - 3;       // demotes to Bishop
      var partner_x = 8 - x1;  // start location of other
      if((board[y1][partner_x] - piece & 2047) == 0) // contains same piece (igore backround color flags)
        board[y1][partner_x] = ((x1 ^ x2 ^ y1 ^ y2) & 1 ? piece - 3 : piece + 1); // demote partner to B or W
    } else if(typ == 7) promo = piece - 4; // converting Bishop always promotes to Bishop
    return promo;
  }

Thank you for all these explanations and feedbacks. I will correct soon the description on my own page. 

• The end-o-game rules, checkmate, stalemate, etc. are identical to standard chess
• King's jump: you guessed well. At his first move, the King may jump to a free square at 2 squares' distance. It does not matter if the square jumped over is occupied or not; however, the jump os forbidden if that intermediate square is threatened by an enemy piece. When jumping like a Knight, at least one of the two intermediate squares must be free of threat. The King's jump is not permitted if the King is in check.
• The King cannot capture with its initial jumping moves (it may jump to a free square only)
• En passant: any time a Pawn or a Prince takes a double step and passes through the capture square of an opposing Pawn, that Pawn may capture the Pawn or the Prince as if it had only moved one square. This en passant capture must be made in the immediate move following the double step. Only a Pawn may capture en passant; the Prince does not have this option.

Not clear from your description at http://history.chess.free.fr/metamachy.htm was:

• Whether stalemate is a win, draw or loss.
• What the "overpassed squares" are in case of the initial King move to the second ring. In particular whether moving like a Knight (from f1 to g3, say) passes over f2, g2, neither, either or both. And what it means for those squares to be "under attack" when they are occupied. (For D or A move it can be assumed that these are the W and F squares in the same direction, respectively.)
• Whether the King can capture with its initial jumping moves.
• Whether a Prince can capture en passant, in addition to being e.p.-capturable. Especially since, in the description of the Pawn, you present its ability to capture e.p. as a "consequence" of its ability to capture diagonally, rather than as an additional rule that could very well have been different. Since the Prince can also capture diagonally, does this have the same (but this time unmentioned) 'consequence'? And is this then a consequence just of being able to capture, (so that the Prince can also e.p.-capture orthogonally), or does the direction matter (and how about backward diagonal then)?

Note that my remark on the non-royal nature of the Prince is not meant as criticism on you piece naming, but just as a warning to the reader that the Metamachy type of Prince is not like the Shogi Prince (which also moves like King) in that it has to be captured / mated too in order to win the game and cannot expose itself to pseudo-legal attack. I would have said the same for Queen where it not that the Queen is an orthodox Chess piece that can move into check, and would automatically be assumed the same in other variants. Note that in your Metamachy description you use 'royal' in exactly the same meaning as I use it here, when you describe the Prince as "a non-royal King".

Ok, I see.  Yes, probably representing positions in the middle of turns would not be common.  But since ChessV considers the legs to be different moves, I needed to do something.  I don't want to break the property that everything has an FEN.

Love the rebuild of chess. It's less a variant and more a unique offering, like shogi as example.

I'd say two things surprised me. In changing almost every piece on the board was there any thought of a different approach to the pawn?

And, of more interest, doing something to save te knight from its 'pasted on feel', the only real disappointment with the game so far? It woul be rare that promotion to a knight would be a better option than a taken piece IMO so I doubt knights get much play.

Perhaps making them a 'Veteran Knight' knight/camel combined move would help.

Or, allowing promotion to a knight on 8 and 9 row, to anything captured in 10th. In that was a knight might be better option as it arrives to the fray earlier.

Just a couple of thoughts.

Hello friends,

Two things. I would like to know what was not clear in my description of metamachy? I could make corrections.

Second, it is a bit severe against me as the inventor to write about the Prince "Despite what its name suggests, it has no royal properties". It moves like a King, I think this is a strong royal property. It can be checked, and this is logical, the capture of the Prince should not be the end. A Prince is not a King. Its name is well chosen or I miss something.

Best regards

French translation:

Marseillais Chess is a chess variant where each player plays two successive moves. On top of the rules for the normal game, the players must honor the following rules:

• A player that is in check must evade the check on his first move.
• If a player checks a King with his first move, he loses the capability to play a second move.
• If, after having played his first move, a player finds himself in a position where it is impossible to play a legal move, this is considered a stalemate.
• En-passant capture should be performed with the first move, except when two e.p. captures are possible. In the latter case, the two e.p. captures can be made in each of the two moves.
• Pushing Pawns two spaces beyond their initial location cannot be considered a double move (two advances of one space). So the player can make his second move after that.

About the FEN: is this really needed? Why would one ever want to have a FEN for a position after the first move? In orthodox Chess we also do not have a special form of the turn indicator for positions half-way a castling, where the King has already moved and the Rook is yet to move. Or in Chu Shogi, for after the Lion made the first leg of a locust capture. The exceptional case for the initial position can already be recognized from the full-move counter in the FEN.

[idea!] Why not use a fraction on the full-move counter if you want to do this?  E.g. move 10.5 would mean after the first half of the 10th turn of the player on move.

As to legal move generation:

It seems to me that a Marseillais Chess cannot be implemented without some dedicated code that would be useless in single-move variants. One task for this code would be to score a stalemate after the first move different from one before it, namely as an illegal position (whatever score you want to use for that) rather than a draw. A second task should be to treat first-moves  that get such a score as illegal moves, i.e. ignore them, and correct the legal-move count that might have been made during move generation for it. This would need a 'delayed' mate detection to handle the case where this count hits zero because all 1-move-legal moves turn out to cause self-stalemate the player, aborting the node with a checkmated or a draw score depending on the in-check status.

It should be clear that you cannot judge the legality of a turn before you have seen the full turn. So that would be 2 ply in Marseillais, and a progressive number of ply in Progressive. If you wouldn't try the last ply of the turn, you could never know if the turn can be legally completed. Unless of course the rules guarantee there always is a legal move irrespective of the position, e.g. because passing on the second turn is always allowed. If you do a full judgement on the legality of the position after the turn, one turn should be enough.

The reason I mentioned QS was because I assumed this would be required to detect the fact that the previous ply exposed the King. The assumption was that the root node of QS would start generating moves, and detect that one of the moves captured the King before really searching any. And then abort with a very happy score. So it would always be a 1-node QS, or a dedicated King-capture test, if you want. Depending on the variant there could be simpler ways to detect King capture than generating all moves and see what they hit. E.g. making all possible retrograde captures from the King, and see if they hit an enemy that reciprocates one (sometimes referred to as the 'super-piece method').  Depending on the complexity of the moves in the variant the super-piece method might be cheap or very expensive. (E.g. bent sliders, Cannons or Fire Demons are a pain.) Just generating all prograde capture moves, which you must be able to do anyway, is always a sure method, though.

How much extra you need compared to the turn you want to judge the legality of unavoidably depends on how complex the conditions for legality can be in the variant at hand. Take the Shogi Pawn-drop-mate ban. To detect it you must be able to see that that the Pawn drop checks (which is of course trivial), but that every conceivable reply move is illegal (exposes your King, or perhaps (worse) completes a perpetual checking cycle). So that is two turns plus a King capture test.

But it can be worse. Imagine a variant where it is illegal (rather than just losing) to expose yourself to mate-in-1 (rather than just to King capture). To judge a move you then have to take into account all replies that check, and then all evasions to any of those, to see if these expose the King. That is 3 ply + 'QS' (or 2-ply + mate-test). Imagine a variant where it is illegal to check when you cannot continue checking until you checkmate. (Tsume Chess?) Far fetched? Take the chained release moves of Paco Shako, implemented as a multi-move turn. It is illegal to release a piece from an embrace (by jumping into it) if the released piece cannot find an empty square to go to, an enemy to enbrace, or trigger another legal release. You will have to verify that at least one chain of releases (no matter how long) exists that terminates. There is just no predicting how many ply it can take.

Is there any French speaker here who can provide an accurate English translation of this? Google translate is not good enough to make it clear.

Les échecs marseillais sont une variante du jeu d'échecs où chaque joueur joue deux coups à la suite. En plus des règles du jeu normales, les joueurs doivent respecter les règles suivantes :

• Un joueur en situation d'échec doit parer l'échec au premier de ses deux coups.
• Si un joueur fait échec au roi au premier coup, il perd la faculté de jouer son deuxième coup.
• Si après avoir joué son premier coup, un joueur se trouve dans une situation où il lui est impossible de jouer un coup légal, il est déclaré pat.
• La prise en passant doit être effectuée au premier coup sauf si deux prises en passant sont possibles. Dans ce dernier cas, les deux prises en passant peuvent être effectuées à chacun des deux coups.
• L'avance de deux cases des pions depuis leur position initiale ne peut pas être considérée comme un coup double (avance de deux fois une case). Donc le joueur peut jouer ensuite son deuxième coup.

An additional note, which I will add to the text of the page itself at some point, when we finish discussing modern Marseilleas:

The concept of an FEN Notation needs to be updated for Marseillais Chess.  ChessV can load/save an FEN for any game, so I needed to decide how to enhance FEN for Marseillais.  The only part that needs to be expanded is the part that records the side on the move - typically "w" or "b".  I add the additional options of "w2" for white on-the-move with two moves still to make and "b2" for black on-the-move with two moves still to make.  I like this alteration in part because the starting position for a (balanced) game still has the same FEN as orthodox chess.

We might miscommunicate, because I am thinking in terms of a pseudo-legal-move search, while you might want to determine move legality before searching them.

A reasonable distinction - from the point of view of a pure engine, it might not matter if a move is technically legal if you return -INFINITY for those moves that aren't.  For a GUI (that is, either Game Courier, or ChessV at the root), we need to know what is legal vs. illegal, although you do address this (quoted later.)

IMO independently trying to establish legality of moves in a search is just a waste of time, as moves are legal more often than not. Just do the search, and when the move is illegal this will discover it soon enough, and will return -INFINITY. But most of the time there is nothing to discover. As long as an illegal move will get a score lower or equal than anything else, the search will work fine.

What you say makes perfect sense.  It does.  And yet, Stockfish does not work this way.  It does not allow a king to be captured and evaluate it badly - rather, it considers that move to be illegal, even in a deep search.  I've looked at a ton of open source chess engines, and what you desribe is not how they work.  In truth, I don't really "understand" chess engines well at all - I sort of understand, but have a very, very hard time visualizing it.  You clearly understand these things on a level that I do not. I'm really just a sophisticated copy-cat who models my open-source engine after the code of others.  What you describe is a nice simplificaiton, but you are far off the beaten path and I am reluctant to follow you down this road, especially given that ChessV doesn't just play Chess, it plays over a hundred games, and it does it with absolutely NO "special cases" for any given game jammed in the middle of anything.  None.  It does what it does by means of a very sophisticated architecture of message-passing between Game, Piece, PieceType, and Rule classes glued together dynamically at run-time.  Not to brag, but there is nothing else in the world like it.  I don't want to tear apart what works on promise of what might be a 0.01% improvment in a typical game, nor what might make an unlikely corner-case of Marseillais more playable.

If you want to test legality of an input move, just do a sufficiently deep search on it (1 ply + QS in normal chess, 2 ply + QS in Marseillais), and reject it if the score is -INFINITY. You don't need any special code for that.

Ok, here you might be right.  As a GUI, I really only need to know what is legal at the root, and again, what you say makes sense.  But I am afraid to follow you.  For one thing, ChessV must, must, must do the right thing in every chess variant which it comes across.  I stipulate that as an immutable parameter of its design (a parameter which I have temporarily broken by implementing Makruk without the counting rules.)  Is it always the case that an evaluation of -INFINITY (game lost) is the same as a move that is not legal?  And 1 ply + QS in normal chess, 2 ply + QS in Marseillais?  Doesn't this already indicate that we don't really know and we are doing an approximation?  Is this univerally applicable to all variants it supports and may support?  For Progressive Chess, does it need to be X ply + QS?  And what the heck does QS even mean in terms of a game like Marseillas where there are no quiescent positions?

Please don't misintrepret - I am not doubting you.  Your engines are awesome and there are many different games where you have the best engine in existance and, in some cases, the only engine.  I'm not doubting you.  I'm doubting MYSELF.  I'm just not willing to make a radical change when I cannot fathom the consequences.

All that said, at some point I will have a sophisticated test suite of dozens of positions in dozens of different games so I can test architectural changes with some level of confidence.  For example, I really like the alternative to mate-distance-pruning you suggested on another forum that is like a universal application of it that prefers the shortest route to any advantage.  It seems genious, and I want to use it.  But I'm afraid, given that Stockfish doesn't use it ...  And I have no robust test suite to prove it doesn't break anything...

We might miscommunicate, because I am thinking in terms of a pseudo-legal-move search, while you might want to determine move legality before searching them. For me an illegal move is simply a move that receives score -INFINITY when I search it. In an engine for normal chess this happens when the next ply captures your King, which gets awarded +INFINITY, and is then negated. Incidentally -INFINITY is also the start value of bestScore, and if it is left at -INFINITY all of the moves must have been illegal. That means mate or stalemate, and if stalemate is a loss both can get the same score, and -INFINITY would be a very suitable value, and you don't really have to do anything other than just returning the maximum move score.

IMO independently trying to establish legality of moves in a search is just a waste of time, as moves are legal more often than not. Just do the search, and when the move is illegal this will discover it soon enough, and will return -INFINITY. But most of the time there is nothing to discover. As long as an illegal move will get a score lower or equal than anything else, the search will work fine.

If you want to test legality of an input move, just do a sufficiently deep search on it (1 ply + QS in normal chess, 2 ply + QS in Marseillais), and reject it if the score is -INFINITY. You don't need any special code for that. I you want to make a list of legal moves (e.g. for the purpose of highlighting taret squares), just write a small loop to subject every prseuo-legal move of interest to such a search.

I think you are describing what I already consider to be Marseillais Chess. In other words, what you are proposing is what I think we should be considereing to be actual Marseillais. But, in any event, what you describe is what ChessV is already doing under the name "Marseillais Chess" and what, on the other TalkChess thread, we agreed the rules to be (although we didn't get into the move-into-stalemate question)

Not arguing - if you are proposing we move forward with this, I am in complete agreement.

Aside from trying to reconstruct the original Marseillais Chess, I would like to propose a game I might call Simplified Marseillais Chess, which is designed with programming it in mind. It would follow the rule of Balanced Marseillais Chess of giving White only one move at the start of the game, it would allow en passant capture only of a Pawn moved on the last part of a player's turn, it would have a turn end with one move if there were no legal moves to follow it, and it would work with normal stalemate and checkmate on a player's first move. I think those are the main differences from regular Marseillais Chess. Is there anything I have overlooked?

Sorry if I'm falling behind in this conversation.  I'm working so messages are coming faster than I can consider or respond to them.  So, for now, I'm only responding to H.G's latest message:

I understand what you are saying here, but I'm not sure how this addresses the issue.  Perhaps the conversation has already moved beyond what I think we are talking about. Regarding the "move into stalemate" issue, H. G. said:

The pair of moves should be legal, and a first move that only occurs in illegal pairs should therefore be considered illegal itself.

I think this is what we were talking about.  If it's not, please let me know.  You describe assigning a stalemate score to a move pair, but I don't think this does anything about making a first move ILLEGAL if it leads to a stalemate when there is an alternate possibility.  If we've already written this off as unworkable, great.  If we're still talking about it, I don't think it is reasonably doable.

Regarding Sven's eninge - that would be awesome.  I didn't remember this from the thread and going back now, it seems this file is no longer available.

One more question remains. While the rules seem to allow for second-order stalemate when the King is not in check, what about when the King is in check? Should this count as checkmate or stalemate? From the understanding that checkmate is check plus stalemate, we could argue that check plus second-order stalemate is also checkmate. Or, we might argue that the ability to escape check, even if no follow-up move is possible by any means of escaping check, constitutes only stalemate. Here's an example:

Here's an example of what I'm calling a second-order stalemate. Black is not in check but has only one legal move.

For the sake of testing some endgame positions as I write the code, here is a game where I played both sides just to get a stalemate position.

Is this really a problem? If you score stalemate after the first move as -INFINITY (which it would automatically get when you score King capture as +INFINITY), the node that searches the first move will end up with score -INFINITY if it has no legal pair of moves. Only there you correct such a score to 'draw' if the player is not in check. This assumes actual checkmates get a slightly better score, either by adjusting them for distance to the root in the leaf itself, or by a delayed-loss bonus when propagating towards the root, so that positions heading for a forced checkmate will not be mistaken for stalemates. (Note that a consequence of the proposed rules is that when your only 1-step-legal check evasions stalemate yourself, this would count as a checkmate.)

BTW, I thought that Sven Schüle said he had made an engine, in the TalkChess discussion you already referred to. I never got around to making a Fairy-Max derivative for it.

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.

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 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.

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 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.

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 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.

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.

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.

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?

What I cannot imagine is that the original inventor would have thought it reasonable to allow e.p. capture

1. when the capturing Pawn has not seen the other one move past it
2. when the Pawn that moved is no longer there
3. 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.

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

1. when the capturing Pawn has not seen the other one move past it
2. when the Pawn that moved is no longer there
3. 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?  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.

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.

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.

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!)

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.

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.

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.

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?

I am a bit worried about this paragraph that states a dropped Rook is considered virgin (and thus fit for castling). As far as I know there doesn't exist any on-line server that uses this rule, or any engine that plays by this rule. It is also a very weird rule: when you move a Rook you lose castling rights, and moving it back to a corner normally doesn't restore them. And a drop move is a move like any other.

A very interesting game.  And you have the interactive diagram using our signature Alfaerie pieces and colors!  I love it :)

Yes, graphics are present now, and I've unhidden the page.

You might consider renaming the Chimera Rider, since "rider" is a common variant piece descriptor.

Dear Fergus,

I am the inventor of Chimera chess who posted the description above.

I had a look at the page from my account, and I can see all the images.

Could you please check again? 

Thanks,

Albert

Thanks H.G., I've changed my older comment to use the inline-style whiteout.

A common work-around for spoilers is to print them as white text on a white background. Selecting it then usually makes it visible. This editor doesn't seem to have a button for selection of the font color, though. But of course this could be done through HTML tags. Like below:

This sentence is printed in white.

I've put (what I think is) the solution in my last comment, but as an html comment.  You can see it by viewing the page's source code (ctrl+u on most browsers; then ctrl+f to search for "spoiler" should get you there quickly).  I was suggesting/asking whether we (the editors) should pursue adding a spoiler-hiding method and, probably, a button in CKEditor to insert such a spoiler to the site.

You’re asking the admin team for Spoiler text as a feature?  Or did you want me to simply post the sequence for now?

Spoiler(?) (should we consider adding a spoiler tag plugin for CKEditor?):

Qxc5+, ke6 // in check both from queen and sentry->lancer
Qd5+, ke7
Qxf7+, kd6 // again doubly checked
Ld2=n+, kc6
S-c6Kd6# // checked by Lancer, no piece to interject; cannot move back to Sentry's square, and Queen and Pawns cover last escape squares.

Nice!

A quick puzzle based on this variant, with Black's pawns moving up the board - playing from the bottom (using abstract pieces as this is from Tabletopia) 

Anyone insterested in playing a game, we can arrange a time/date to play live online.

Wow, QS explosion is a serious problem.  Now that I have allowed all check evasions in the QSearch, I have my search stack overflowing very quickly in Gross Chess and my stack supports a depth of 128!  After four plies of QS it considers only recaptures and check evasions and I still had over a HUNDRED plies.  I figured something had to be broken with my 3-fold repetition detection, but not so...  In Gross Chess you can literally have over a hundred consecutive moves of nothing by check evasions and recaptures to the last square without triggering repetition.  I would not have thought it possible had I not spent a couple hours manually stepping though about 50 plies until I was convinced it was for real.  (It has a lot to do with the cannons - you can often escape check by moving into the path of your own cannon to become a screen and check the opponent king.)

So I appreciate your previous message or I would probably have been at a loss as to what to do about this.  I've now switched to this:  first four plies of QS are all captures and check evasions; after four plies it switches to only recaptures and check evasions; after eight plies of QS it starts to allow standing pat even when in check (returning the static evaluation rather than -INFINITY.)  This has stopped the search explosion.  I'm now running a 1600 game Capablanca match against FairyMax to ensure this doesn't hurt my search strength too much.  (Seeing as most games don't have the kind of search explosion problems that Gross does but I'd like to keep the search function the same across games if possible.)

Yeah, I was generating all check evasions in QS, I just forgot to make that exception when it switches to recpature only.  I added the limit because the QS explosion was so bad it basically didn't move when I implemented Evolution Chess.