Comments by HGMuller

That it takes so much effort even by seasoned chess programmers to create a rule-checking preset for a variant as simple as Symmetric Chess firmly puts us in the category of 'backward websites'. We really should have some kind of wizard for this, where people that cannot program at all would have no trouble to create such a preset. E.g. something like the Design Wizard for Interactive Diagrams I put in the article on those. Where you just have to take a minute or so to specify board dimensions and size of promotion zone, pick a preferred graphics theme, tick a number of pieces in a list of standard types (or, very rarely, pick an image and specify a non-standard move for it by hand), drag the pieces to their initial locations on an empty (a specified symmetry taking care of you having to do that for only one member of each type), and you are done.

If the wizard produces the usual game code, (just as that for the Interactive Diagrams produces the HTML), it will remain possible to take care of any features not suported through the wizard by editing the automatically generated game code later. But this should be needed only very rarely.

To catch more variants through the wizard it could allow a general input screen for specifying castling rules: the location of the castling partner, where it and the King will end up after castling, which squares must be empty and which squares must not be attacked. (And allow that to be repeated as many times as possible.)

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

Last year at the ICGA Computer Games Conference 'Computer Curling' was actually one of the big things. The attraction was that it was a game with a continuous rather than a discrete game state, which makes exhaustive listing of all possible moves impossible. I suppose that to make it difficult there must be some randomness added to the move that you specify, as with infinite precision there would be no difference between an easy and a difficult turn.

The Interactive Diagram basically is a table of piece images, where the table cells are made sensitive to mouse clicks, which then can bring about the desired manipulation of the images (e.g. move them to other cells) or background colors. Such a structure would not allow drawing of image elements that span multiple cells, such as the arrows in the video.

I guess that in theory it should be possible to break up the arrows in cell-sized 'puzzle pieces' of straight parts, corner parts, arrow heads etc., in all possible orientations, and synthesize cell-spanning arrows from those pieces. The Chess pieces are actually displayed as cell background image, and have transparent background themselves, through which a background color for the cell shows (which I then use for highlighting). So technically the cells are empty, and just show a background. Images of arrow segments could be put inside them, and the non-transparent parts would then cover the piece images in the background. But this would require the images of the arrow segments to exactly fit the cell (or the browser's display algorithm would just enlarge the cells to fit the image). So it would require a different set of arrow segments for each conceivable square size. And it is a bit hard anyway to make images fit exactly in table cells; most browsers want to take some margin between the image and the cell edges, especially at the botton. So the arrows might look more like dashed lines.

Of course there still would be the problem of how a user should indicate where he wants arrows. Or other types of highlights. All in all it would not be very easy.

The current diagram already records all moves you play to make them into a game history. And on a page with a diagram you can request presence of buttons to step through a thus recorded games. For the diagrams I post here I never included such buttons, because they just serve the purpose of illustrating the piece moves and initial position. But you can see them in operation at my turn-based server, which uses the Interactive Diagram as user interface..

Something is very wrong! I try to upload an updated betza.js file to the membergraphics/MSinteractive-diagrams. It says "file uploaded successfully". When I point my browser to the MSinteractive-diagrams directory, I see the betza.js file there with today's date. All as expected.

But when I then request the content of the betza.js file, it has not changed. It still gives me the old content, not the one I just uploaded. Flushing my browser's cache, or switching to another browser makes no difference, I keep getting the content of the file that according to its date does no longer exist.

It is true that new variants that just slam a number of sliders, leapers, hoppers and their compounds on a rectangular board of some size are not very innovative. Even if some of the pieces they feature have never been tried before. In a sense it is like they are all the same 'meta-variant' that has a number of adjustable parameters, and by turning the knobs you can set them to values that are never tried in that combination before. As Pritchard said: "it takes only 10 sec to invent a new chess variant, and unfortunately some people do". This doesn't mean that they cannot be entertaining to play, of course. Or that they are all of the same quality. Some non-trivial work can still go in picking the initial setup, making sure all pieces can be easily developed (remove any 'awkwardness'), all pieces are protected against possible quick attacks, and such. The spectrum of piece powers is also an important factor in how attractive the game is.

Still even there you can sometimes express a novel idea. In my variant Team-Mate Chess I used a collection of not-so-special pieces that were selected to not have mating potential (against a bare King) on their own, but always must force checkmate in pairs (similar to Bishop + Knight in orthodox Chess).

BTW, it seems my productivity is overrated in the list above: it says I invented 13 variants, but it attributes Wa and Tenjiku Shogi to me, while these are just historic Japanese games for which I made a rule-description page. (I also made such pages for Chu, Dai, Dai Dai and Maka Dai Dai Shogi, Paco Shako and Metamachy, but these were (justly) not attributed to me.) It also counts my article on FairyGen as a game invention, while this is just a description of a piece of software for generating End-Game Tables involvng fairy pieces.

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;
  }

That certainly makes more sense to me. One could still wonder about the case where the first-moved Bishop does not convert, but is captured before the second moves. The situation this gives rise to is not really any different from the one where it was captured before it moved. And you would need extra game state to distinguish the two.

I guess you need extra game state anyway, because a Bishop can move and return to his starting square without converting. The other Bishop must then convert, but from the board position you cannot see which of the two is the 'other' Bishop.

Possibly the cleanest solution to everything is to implement this by piece-type changing: start both Bishops as Dragon Horses. When a Dragon Horse moves, it 'promotes' to Bishop, and as a side effect, depending on how it moves, the other Dragon Horse (which must still be on its starting square in that case if not captured), promotes, either to Wazir or to Bishop. If a Wazir moves it always promotes to Bishop. All game state is then encoded in the board position.

I still wanted to comment a bit on legality checking and game-end detection:

There is no need to assign illegal moves the same score as a legal losing game termination. You can assign it an even lower score. This reminds me of the fact that there are many Xiangqi engines that prefer losing by perpetual checking over being mated in 1. But the behavior can entirely be controlled by setting the score for the various kinds of game termination; minimax or alpha-beta doesn't require a binary game outcome. (Luckily, or the heuristic evaluation would not be any good.) If losing by illegal move gets a lower score than any form of losing by legal means, minimax should always avoid it. Unless the game rules themselves are incomplete, and allow you to manoeuvre by legal moves into positions where you have no legal moves, but which are not defined as terminal. (Most common case of this is failing to define stalemate as game end in games where the goal is King capture, under the false assumption that you will always have pseudo-legal moves.) Even in that case the illegal-move score will merely show up in the root as the most dishonorable form of losing.

It is useful to distinguish 'direct' termination conditions (detectable from the move or piece counts, such as King capture or baring) from 'indirect' ones (depending on the location of pieces and how they move). 'Check' is already a complex condition, defined in terms of pseudo-legal moves. 'Legal' (and thus illegal) are again defined in terms of check. And 'checkmate' is defined in terms of 'legal'. These definitions taken at face value often imply search, being of the form "there must not exist a move that ...". The definition of checkmate even involves a two-ply search, as it requires all pseudo-legal moves to be searched for legality, which again requires all replies to be examined for King capture.

Now it is very possible that there exist shortcuts for doing these searches, e.g. check detection through the super-piece method, or mate detection through estabishing that the checker(s) cannot (all) be captured, nothing can be interposed to block the check(s), and the King has nowhere to withdraw to. This is pretty well developed for orthodox Chess, but can get arbitrary complex in arbitrary variants. E.g. for determining whether a square is attacked when there are hoppers, bent sliders or locust capturers around (not to mention Coordinators, Immobilizers and Pincher Pawns). The super-piece method requires generation of retrograde captures, which must be handled by dedicated code, which can easily be inconsistent with the prograde move generator used in search. And for mate detection, what if there is a Lion around that can capture two checkers in one move? Or capture one, and block the other? What if there are bent sliders, that can both be blocked on a single square? What if the checkers involve a hopper, and its mount can move away, capturing or blocking another checker? How do I determine whether a locust capturer will attack me after the evasion? If I just stick to the official definition of these game concepts I only need prograde pseudo-legal-move generation, and there is not nearly as much that could go wrong.

You mentioned the 'beaten path', but you should keep in mind that this is the path used by developers of engines for orthodox Chess, and thus might not necessarily lead to where you want to be. No matter how much smartness you built into your engine for more efficient detection of the game-end conditions, it will never hurt to be prepared for game rules where these shortcuts fail, and some illegal moves escape your dedicated detection for those. So I would recommend to reserve a score for 'illegal move', (which, with checking rules, would be the negated score of capture or extinction of royal(s)), so that your engine will not crash if you inadvertantly run into a King capture. And in any node detect whether enough of the moves you thought to be legal are indeed legal, so that you would not have to declare game end after all (with an appropriate score different from the illegal-move score, like a draw or a distance-to-root-corrected losing or winning score). Which is pretty easy by starting bestScore at the illegal-move value, and see at the end if it stayed there. In cases where your dedicated game-end detection fails, your would then have a safety net in the engine. As for the GUI, you could always subject all moves to a search to make sure they are legal, and make the depth of this search a parameter of the variant, which can then be increased for variants with unusually complex game-termination rules.

So just to be absolutely sure: when moving Kf1-f3, with a black Knight on g4 attacking f2 (but pinned on the black King on g5 by a white Rook on g3), this would be illegal if f2 was empty or occupied by a white piece, but legal if it was occupied by a black piece (assuming f1 and f3 not under black attack)?

The description of the Bishop conversion rule says this:

" for one of the bishops of the player, the first move made with this bishop must be of this special type. "

I take this sentence to mean that if one of the Bishops gets captured before it moves, the other cannot start with a normal move. This doesn't seem very sensible, though, so I am not sure whether my interpretation is correct.

Just to contribute my two cents: when you would keep one flag per Bishop to indicate whether it had been moved (or per square whether the original occupant is still there), which really should be considered a standard feature automatically kept track of in any chess variant, (considering how many variants endow pieces with virgin-only moves), the game state can be ancoded with only a single other flag per player, indicating whether a conversion has already taken place. The rule for a virgin Bishop is then merely that he cannot convert when a conversion was already done, and otherwise must convert when the other Bishops is not virgin (or, since the rule is only applied on a virgin Bishop, when not both Bishops are virgin). Note that the type of move (W or B) can be easily tested from the color of the square ((x ^ y) & 1 if you have separate x and y coordinates, nr*9 & 8 for 0-63 square numbering on an 8x8 board, nr & 1 on 0-71 square numbering on 9x8).

Note that as part of an attempt to get rid of the ridiculous names of some of the CwDA pieces it was decided the Fibnif should be renamed to Lancer.

And yes, a pair of Lancers is pretty good at checkmating. An overview for various board sizes:

Given that Knight + Wazir is already won, and that blocking plays virtually no role at all in the late end-game (especially when the losing side cannot block because the squares where this could be done are attacked by the piece itself), two WazirKnights should have no problem at all. My EGT generator does not do lame leaps, but with a pair of NW the stats are:

Note that the winning percentage for N + W is not as high as commonly found in general wins. This is because a Wazir can easily be chased to doom by a King, when it happens to wake up cut off from the rest of its army. So there are a lot more positions where the strong side loses a piece despite the fact that he has the move (which otherwise are usually limited to forks in configurations where one of the pieces cannot move away while protecting the other, or attacked pieces trapped against an edge or in a corner).

But then I am not so happy that this requires an alteration of the normal (full-turn) FENs, which would require w2 and b2 stm field in your proposal. I would much rather have it that the exceptional partial-turn FENs would require something special. As the full-move counter is actually completely useless, and in balanced Marseillais the first turn is special in that it only allows a single move, recognizing half-turn FENs by artificially setting their move count to 1 would be OK with me.

The WinBoard Alien Edition would not consider positions half-way a turn not as game positions; when you step through the game later it would always alternate player between two turns, and show the effect of the pair of moves (like it was dealing with castling). Animation of the move might tell you the order.

As to the legality issue: I took the pragmatic approach in my Shogi engines as well as WinBoard: I do not consider Pawn-drop mates illegal, just losing. If checkmate is detected, its scoring depends on whether the previous move was a Pawn drop or not. So even without engine WinBoard allows the user to enter the Pawn drop, which then will end the game for him as a loss. For Shogi this is of course entirely justifiable. But it would not disturb me if Marseillais was treated the same; if we thing it should not be allowed to stalemate yourself after the first turn, just detect the stalemate and declare it a loss if the user elects to play into it.

Capablanca Chess has about 16% draw rate between equal players, compared to orthodox Chess about 32%. (That doesn't account for the limit of near-perfect play, possibly with the aid of exhaustive opening theory that prevents mistakes before the game reaches the stage of a dead draw.)

Draw rates tend to fall for games within a group of players of very diverse strength, as many games will be a guaranteed win for the strongest player.

I implemented a new enhancement of XBetza notation in XBoard, to be able to more precisely indicate generation of e.p. rights on oblique moves. 'Non-jumping' is an ill-defined concept for those; nN could be a Mao or a Moa, so with the existing convention ifmnN would not sufficiently specify what the blocking square (and thus e.p. square) is. For that a multi-leg description fully specifying the path is necessary, like mafsW for the Mao.

XBetza uses the 'e' modifier to indicate e.p. capture, as alternative to the 'm' and 'c' modality. But this only seems useful in the final leg of a muti-leg move. So I redefined the meaning of 'e' in a non-final leg to me an 'm' move that generates e.p. rights on its target square. This would make the double-push of a FIDE Pawn ifeafmW. (And its e.p. capture feF, which can combine with the normal capture to fceF.)

[Edit] On thecond thoughts I wonder if it wouldn't be better to use the 'n' modifier instead of 'e' for indicating generation of e.p. rights by a non-final leg, and reserve the latter for actual capture. When laying out a lame-leaper trajectory one will almost certainly use a stepper atom (W, F or K), and 'n' can never have its traditional non-jumping meaning there. OTOH, e.p. capture on a non-final leg is not completely out of the question: one could want to define an e.p.-capturing Checker, feafmF, where the 'e' on the non-final leg then means that leg should end on the e.p. square (by definition empty), and that the move as a whole leads to removal of the previously moved piece as a side effect. Double-push FIDE would then become ifnafmW to generate e.p. rights.