Comments by HGMuller

Note that saying 'check' is something amateurs do; in official games this is even forbidden. In that light it seems the following convention could be useful for this game at amateur level, to help enforcing the checking rule (which might strike ordinary chess players as unusual):

A player that attacks a castle and suspects it might be checkmate can say 'check'. This obliges his opponent to point out at the end of his next move the Castle where his King takes shelter. If that Castle cannot be captured, the game just continues, because even if there was a genuine check it has apparently been resolved. If it can be captured, the player that pointed it out could be ruled to lose, or (in a more forgiving spirit) could be obliged to acknowledge his mistake and point out another Castle (or conceed he has been checkmated or played an illegal move).

As to notation: this is not really part of the game rules, and for orthodox Chess several systems exist (descriptive notation, coordinate notation, long/short algebraic notation). I don't particularly like the notation proposed here; personally I would just stick to an existing standard, like SAN. (Also for the reason of being able to process it with existing software.) This is based on identifying a move by mentioning the type of the moving piece and the target square, possibly augmented by as many coordinates of the starting square as is needed to distinguish it from other legal moves that would be witten the same without disambiguation.

Turnover Chess offers two new aspects one usually does not have to deal with: piece types are 'fluid', and besides capture there are the possibilities of (friendly) combination and turnover. in SAN one makes the distinction between capture and non-capture by inserting an 'x' symbol, (problematic on board with more than 23 files, but then, more than 26 files would be problematic anyway...), although this is redundant, as it is fully implied by the occupation of the target square. Apparently it is considered so helpful to make this distinction jump out that it is worth the redundancy. This would then likely be true for combination and turnover as well.

My first idea was to write any move to a non-empty square with 'x', but that would not distinguish combination / turnover from true capture. It is possible to make this distinction within the existing framework of SAN, however, by using promotion suffixes: any move that would not lead to the expected occupation (i.e. the outermost ring of the moving piece) of the target square could be written as a promotion to what does result. The use of 'x' would be determined by whether the former occupant of the target square was friend or foe. So Qe3 would be a non-capture, putting a Bishop on e3, while Qxe3 would in addition have captured an enemy there (Knight, Queen, Bishop or Castle). Qe3=Q would have absorbed a frienly Rook, Qxe3=K would have turned over an enemy Pawn. In all cases a Rook would be left behind, but that is implied in this game, and so common that it does not warrant introduction of more redundant symbols in the notation.

Some more remarks: I think that using K for Knight is a really bad idea. It is mega-confusing to chess players. Even if you don't have to use 'K' for indicating another piece type, it would be better to keep N for Knight. After all, you kept the names of the orthodox pieces, while they are really not pieces at all but just constellations of rings. You might as well keep their standard abbreviations. Not distinguishing Castles and Pawns in notation is probably also undesirable (even if they move the same). So I would always mention a Castle as C, (a good reminder for what is left behind), while Pawn moves could follow the normal SAN rule of using no type indicator at all, but always prefixing a 'x' symbol with their file coordinate. This remains unambiguous here, as Pawns can only have come from 3 squares to reach the mentioned target square, and only true captures can change file.

Well, that we today play this game both with and without drops is only out of ignorance. At the time this game was invented the rules were of course known, and nothing would have been optional about them. So it would either have been one or the other always. Based on the power of the pieces I am now convinced that the original rules would have included piece drops. And with piece drops there is no such thing as (meta-)color binding; any piece can get captured, and re-appear on any color it wants. Also note that the Heavenly Horse is a promoted piece. Because of the promotion zone being 3 ranks deep and the way the Liberated Horse moves you can promote on 3 of the 4 possible meta-colors.

Your diagnosis is entirely correct. Because KingSlayer was originally designed with only (2x) 7 piece types, it initializes the move-generator data for the four variable types from a larger list of all types depending on the army choice. But when 'Traitor promotion' is set it initializes the 5th variable type as a copy of the 4th, in the table for the opponent. But I forgot to flip the orientation. I will add a note to this posting when I have fixed it.

Good that ChessV now gives a memory command. I already had made KingSlayer a bit more robust to not receiving one, by having it interpret memory size 0 as 128KB and launching it with that size, and then check the memory size at the start of every search to see if it is still at 0, and allocating 64MB if it is. But relying on default hash sizes is likely to give rise to unfair use of resources.

[Edit] OK, I uploaded a version (0.1, same link) where the traitor orientation should be fixed. This was a bit tricky, as the initialization also collects all sliding directions of an army, to know from which directions it should expect discovered checks.

Note that it must be trivially easy to checkmate a bare King with a Rhino, powerful as the latter is, in addition to covering two orthogonally adjacent squares. The checkmating applet cannot really do crooked sliders, but assuming that blocking doesn't play a significant role with only another King on the board, you can let it calculate a piece that directly leaps to the squares a Rhino would attack.

As is well known, the Gnu/Wildebeest, whose targets all fall on the Rhino paths, has no mating potential. This is due to a coincidental collision with the King. But just adding a single W move to the Gnu (say fW) already cricumvents this problem. So WNC, which is a subset of the Rhino (but leaping) already has an easy mate (maximally 19 moves).

The Mirror Rhino fares even better, as FN in itself has already mating potential (maximally 22 moves). The longer distance moves of the Rhino were only needed because without them no two orthogonally adjacent squares would be attacked.

Piece values are an average over all plausible positions anyway, furthermore based on the assumption that the value of an army is the sum of its parts. (Although the B-pair bonus strictly speaking already is an exception to that). So it is to be expected that in individual positions the performance is not as good as the standard value suggests. E.g. the value of a Bishop is commonly considered to be dependent on the shade the Pawns are on. And a Queen is more valuable when the opponent has poor King safety, so you can effectively double-move it via intermediate checks.

What you show here is not evidence of that, however. That there is no obvious compensation doesn't mean there is no compensation. Apart from the Bishop-Knight imbalance, the position is quite asymmetric. So the absolute value of the position cannot really be attributed to material only. A better test would be to replace one of the white Bishops by a Knight, and then look how much the position scores on average. If white is then significantly worse you know it cannot be due to material, as that is perfectly balanced.

Stanislav's name and the fact that he brings this up at all suggests that he reads Russian. So why doesn't he put a discription of this variant on this website?

Google translate doesn't do too bad a job on this, BTW. It seems that this is a patented commercial variant (in Russia) that uses 2-step area-moving Ferz and Wazir as extra pieces, which furthermore aquire Bishop or Rook moves when on the same file as the King. Seems the King itself also has some extra capabilities, but I didn't really read that far.

Oops... It seems there has been a mixup of versions at some point. This code was added as a hack to do Peace Chess, where pieces can combine to 'embracing pairs' coexisting on the same square. The IDs for these combinations are generated here automatically. Piece Chess of course only has 6 basic piece types, so for that purpose having the pair codes start at 64 located them well beyond 'nType', with a large safety margin. But I should never have used that hacked version for replacing the script that powers the diagram in general, at least not without modification. There is no reason why the 64 could not be replaced by (say) 400, to not wreck any variants with fewer than 400 piece types. (Without this hack the limit was 512 piece types; the 512 bit is used to indicate piece virginity, the 1024 bit for piece color.)

Thanks for spotting this; I will fix it soon.

Are you talking about Game Courier now to play it here on-line, or about ChessV? I don't think that in ChessV you can do any of these things; ChessV is not a general configurable variant engine, although it does have a mechanism to configure some (mostly minor) rule variations on the games it supports. And I don't think it is open source. Greg can tell us more about that.

As for Game Courier; I am sure all that is possible there, but in practice you have to be a programmer to be able to write a rule enforcing preset. For this reason the large majority of presets have no rule enforcing at all, and just leave it to the players to enforce the rules. Erroneous rule enforcing is much worse than having no enforcement at all. This should be a good option for the mentioned 100-cell chess, as the location-dependent move rules seem to give it above-average complexity.

And a Shogi board is 9x9, not 9x10. (Xiangqi is 9x10, but this also doesn't qualify as a Xiangqi board, which has a Palace and a River.)

This would not only bite you when you limit QS depth. Even if you do an unlimited-depth capture search, you would see phantom mates if you don't consider non-capture evasions (interposition or King withdrawal). You either must consider all evasions (effectively switching back to a d=1 search) on a check, or you should allow stand-pat even in the face of a check, assuming that a non-capture evasion that doesn't give away any score always exists. (Which would obviously make you overlook true checkmates in QS. This is not as bad as it sounds, as most checks are indeed not checkmates.)

QS explosion is a serious concern in general variant engines. MVV/LVA sorting might not be good enough to suppress plunder raids if capture modes other than replacement are possible. E.g. Lions in Chu Shogi are disastrous, when they can jump into the opponent's camp to a save square, and then then just sit there eliminating all neighors in combinatorially many different orders. Fire demons are even worse.

On my Linux system on an Intel PC I never had any such problems with XBoard + Fairy-Max. Which is the essential change that finally made it work for you? The fflush(stdin)?

Currently the diagram is limited to a single locust capture. Which already makes the Lion Dog of the large Shogi variants fall beyond its capabilities. If this were solved (e.g. by allowing an array of locust-victim coordinates), the XBetza notation could specify each number of victims separately, e.g. RcdafRcdafcdafR ... Which for a big board like Taikyoku's 36x36 becomes of course very cumbersome.

Perhaps there would be some benefit of extending XBetza notation with a 'repeat count' on a group of modifiers. This would then replace the 'a' modifier. A leading '0' on the number could indicate 'exactly that many', where otherwise it would mean up to that number. So cd02fR would then mean cdafcdafR. Where the expansion rule is that the repeat count would group with preceding modality modifiers, and following directional modifiers. (So that you could still slam an initial directional modifier on the first leg, and a different modality modifier on the last one. That would allow description of the Tenjiku jumping generals as multi-hoppers: Rp14cR or Rp0cR.)

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.

As an opposing army for orthodox Chess this seems way too strong. A leaper with 16 targets typically is worth about 7 Pawns, and with 24 targets about 11 Pawns. Together with the Sages, which are about Knight value, this already balances the fide army. But in addition you have the two Flying Jesters, which are major pieces, and should be worth at least a Knight, and more likely about 4 Pawns each.

So pitting this against fide is like being Rook + minor ahead...

Well, now you are testing, perhaps you can also test this: when I was submitting my latest chess variant, the submission form was using cached data every time I opened it to make a change. With as a result that the modifications I made would have disappeared next time I opened the input form, unless I would first refresh it with Shift + Load to ignore cached data.

I am not sure if this is just a problem with my FireFox settings, but it seems very undesirable behavior.

Alfaerie is one of the six preconfigured settings in the design wizard for the interactive diagram, (setting the right values for the image directory, square size, white/black prefix and graphics type at the press of a button), and in fact the default choice. Other buttons give you Abstract, Motif, Utrecht, 2 sizes XBoard presets. And of course you could use your own uploaded graphics, by supplying the location and other parameters to the design wizard explicitly.

For the pieces I needed Alfaerie was not too bad. I had to improvise a bit for the (Mounted) Veteran, using the Wazir(-Knight) instead, thus only indicating the non-capture move correctly. But that seemed acceptible.

Some of the other Alfaerie pieces look embarrasingly simplistic (e.g. Elephant), so I usually prefer the XBoard theme when I need any of those. Even the orthodox pieces look pretty ugly in Alfaerie; they are not anti-aliased, giving them a very ragged appearance. This is so 20th-century... I think it is high time someone would take the trouble replacing all the Alfaerie image files by anti-aliased versions (with alpha channel).

versus  

BTW, I am happy you like Veteran Chess. I have not programmed it into any engine yet, but I play-tested it against a regular participant of the Dutch Superchess championship over the board, and it seemed quite playable. That 1:1 trading is discouraged by leaving the opponent with a promoted piece seems compensated well enough by that in 2:1 trading you can promote your second piece to compensate for the loss of the first. E.g. a Pawn protected by a Pawn is pretty much unassailable in orthodox Chess, but here after BxP, PxP, NxP=M promoting the Knight to a Rook-class piece plus capture of two Pawns seems enough compensation for the Bishop. So you don't get into stand-off situations too easily.

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.

Note that the rules of this game aren't really described anywhere. Through a large detour (the game's comment page, the actual preset, the 'Rules of Sosarian Chess' item in the 'Related Pages' menu) you finally get to a rule page, but it is the rules of 'Lions and Unicorn Chess' instead.

Interesting game. It begs some questions, however:

• What made you decide the move of the Demon and Jumping Generals in Tenjiku Shogi make that game 'unplayable'?
• Why do you prefer the standard Shogi promotion rule over the Chu Shogi rule?
• What is the point of disallowing a jump for the double King move of the Demon? The area move it has would be able to reach the same squares through multiple paths, and they are unlikely to be all blocked. Especially since any obstructing enemy can be destroyed in the process. So in practice it would only delay development of the Demon, when the latter is still behind a solid wall of own pieces. Which you probably would not want to develop very quickly anyway, valuable as it is. So it doesn't seem worth introducing a new type of move, rather than just taking Demon = Buffalo + Lion + Area Move.
• The value of the Demon with the move you give it would not nearly be 3 Jumping Generals. I am not even sure it is worth more than a single VG or GG (even when the latter have limited jumping power). The Lion power isn't worth that much, since most Tenjiku pieces are 'Lion proof' (i.e. have all King moves, so you cannot bring igui to bear on them as an attack). Note that some Tenjiku players value the Lion Hawk (as Bishop + full Lion) less than a Queen. BTW, the rule of thumb that a Demon is worth three Jumping Generals in Tenjiku Shogi only holds when these Generals are still able to inflict smothered mates, which can only be averted by giving a Demon back. Otherwise Demons that burn are priceless: losing one is losing the game. Conventional pieces have no defense against a Demon.

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 unfortunately runs into one of the limitations of FairyGen: it assumes there are always at least two white pieces. It uses that for the application of symmetry to save memory: it only tabulates positions with the first piece in the triangle a1-d1-d4, and when it is on the diagonal a1-d4, with the second piece in a1-h1-h8. Other positions are mapped onto these by vertical, horizontal and diagonal flipping. But this is only done after white moves. The assumption was that a bare royal would never be able to win. Of course for 3-men EGT memory is not a very large concern, and even for 5-men the EGT would only measure 1GB (=64^5), which isn't much for today's memory technology. When I wrote FairyGen even my largest computer had only 1GB. I guess I could compile a version that doesn't apply any symetry at all, and try if that one does 1+2-men without problems. (I already have versions that I made for private use, that can handle reduced symmetry, like needed for the pieces of the CwDA Nutters army, but even there it still does horizontal flipping.)

To define divergent moves in the piecedef.ini file you can add an 'm' or a 'c' to the third parameter. E.g.

X: 1,0,sm* 1,1,sc*

would be a piece that moves like a Rook but captures like a Bishop. To define a piece that doesn't capture at all you just make all its moves 'move-only'. If you want a piece without any moves or captures, perhaps you can just leave the entire line after the colon empty. I never tried that, but I think it should work.

It seems awful to have the Queen (a non-jumping piece) starting trapped in the corner; you now cannot develop it without breaking the Pawn shield, so j-side castling becomes very unattractive. Two-step castling sucks anyway, on 10-wide boards.

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.

Oops, my bad! Non-capture only is indicated by 'n', not by 'm'. I was mixing it up with Betza notation. :-(

So the non-capturing Rook (Betza mR) would be R: (1,0,sn*). An 'm' would be simply ignored; FairyGen checks for occurrence in the string behind the second comma for 'n', 'c', 's' and '*' only. You don't have to specify anything about captures if you don't want them.

Using (0,0) as step for a completely immobile piece might work, as the piece would see itself in the target square, and captures of friendly pieces is never allowed. It should not be needed, though. But there must be a space behind the colon, perhaps this was the problem.

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.

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.

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.

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

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

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

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.

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.

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

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.

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.

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

When the Cannon was introduced it could be called ground-breaking, because it introduced an entirely new class of moves: obligatory hopping over other pieces. Such moves are not as elementary as leaps, because they depend on occupancy of other squares than the origin and destination of the move. But one could already say that of sliding moves, which require all passed-over squares to be empty; the hoppers just impose another, more general condition than emptiness on such squares. Xiangqi is also somewhat unique in that it confines certain pieces to certain zones of the board; this could be seen as a special case of endowing pieces with location-dependent moves (namely scrapping precisely those moves that would leave the zone, in each location), which is very un-chess-like.

You are correct in pointing out the large Shogi variants are mostly just run-of-the-mill Chess variants, except for perhaps a hand full of innovative pieces (Lion, Hook Mover, Fire Demon.) But they still have a very different and easily recognized 'flavor': pieces tend to move only along the principal (orthogonal or diagonal) rays, and oblique leaps are almost completely absent. (And those that are there are then usually an incidental consequence of some multi-move rule, such as Lion = double-move King.) I have a theory that this is a consequence of the different Pawn move: the FIDE Pawn, capturing diagonally, tends to form chains of Pawns protecting each other. Which are very hard to break down by frontal attack once the chains interlock. You then need oblique leaps badly to be able to undermine these structures by attacking their weak spots in the rear, which are usually unreachable by Queen-moves only. And it doesn't matter much how few pieces you have that can make the move required in the case at hand, as the Pawn chains are quasi-static structures, and won't go away. So you will have enough time to manoeuvre the required piece into position. Shogi has none of this, as Pawns can never protect each other there (and after the invention of drops they added a rule for keeping it that way!). So there is no great need for oblique moves, and to get a large-enough variety of pieces with Queen-moves only, they turned to pieces with very low symmetry.

Another distinctive trait of the Shogi flavor is that virtually all pieces can promote (usually only with modest gain in abilities), while in western variants promotion is reserved for Pawns, offering the possibility to turn the weakest piece into the strongest one. In principle these traits could be easily mixed, but in practice this is not often done. Scirocco is a good example of a chess variant that combines design characteristics of Shogi and western chess variants.

But since the invention of the Cannon and the Grasshopper, and the introduction of asymmetric pieces, putting such moves on a piece in some combination that was never used before can no longer be called 'innovative'. There must be millions of such combinations possible even on an 8x8 board, and I am pretty sure the combination of moving diagonally forward like a Cannon, leaping like a Camel, and moving backwards like a Xiangqi Elephant (just to name something crazy) has never been tried. So what? Unless there is a very good reason why this move would make the game it appears in better than any other, 'inventing' the piece is not more creative than writing down a random number of 60 digits of which you can be virtually certain no one in the Universe has ever used (or even thought of) it before.

Truly innovative pieces are for instance Mats Winther's bifurcators, which generalize the principle of a hopper in various ways (by not only allowing change of move/capture rights on encountering an obstacle in their path, but also of the move direction, and the exact location where this change occurs). Inventors also often resort to associating a move with side effects to create something new, usually locust capture at squares that in various different ways can depend on the move (e.g. Advancers, Withdrawers), but also displacement of pieces on such squares (Magnetic or Catapult pieces).

I do not consider games like Ultima or Aarima chess variants at all. Even Paco Shako is a dubious case. Replacement capture is one of the defining traits of chess variants, and while it is OK to have the occasional exception (such as e.p. capture), a game that does (almost) entirely away with it no longer feels like chess at all. You might as well call Checkers, Ataxx or Amazons a chess variant. Clobber is a somewhat dubious case. 'Chess variant' is not a synonym for 'board game'.

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.

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

@Kevin: I was mostly worrying about the existence of non-rule-enforcing presets, which I think we should not have at all. I would have thought that creating such presets would almost never present any problem, as it basically just requires specifying a board size and topology (square/hex), putting a number of piece images on a board in the desired (starting) location, or put them in a 'holdings' next to the board. This doesn't seem to require any special skills beyond those needed to use a computer in general (i.e. using mouse and keyboard). So I am shocked that you say over half of the popular CVs would be beyond your abilities. And I fear the answer to the question of how many rule-enforcing presets you would be able to make for those 107 variants.

I think this is pretty serious, because I consider you as a quite representative example of our target audience. Since you have already investigated the matter, can you give a few examples of CV traits that made you decide creating even a non-rule-enforcing preset was beyond you?

I don't see why it should ever be a problem to define a rule-enforcing preset for a CV with "just sliders/leapers on a rectangular board". Specifying a move on each of the pieces does seem a rather trivial task. And perhaps not even needed for most pieces, as the piece images could have a default move associated with them, so that you only would have to take care of this when you wanted to change that move into something unusual. I would be very surprised is CVs that use the Bishop image (say) would not have it move like an orthodox Bishop in >95% of the cases.

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.

This is a trial for using the Interactive Diagram for Alice Chess. Custom-supplied functions BadZone and WeirdPromotion take care of refusal of moves to squares of which the mirror square is occupied, and take care of shuttling the moved piece to the other board, respectively. The boards are separated by strip of 'hole' squares, which has to be two files wide to prevent Knights from crossing it.

I implemented e.p. capture as a move by the Pawn on the board where the doubly pushed Pawn started. This seemed the least illogical way to do it, as the e.p. square on that board will always be empty (or the double push would not have been allowed). And it is the square the double push really passed over, and thus where it could have been blocked. The move could still be illegal because the corresponding square on the other board is occupied, but that is normal for any move to an empty square in Alice Chess that would be legal on its own board. There has to be no extra rule to prevent double capture this way. This method of e.p. capture corresponds to one where the doubly pushed Pawn must first make a single retrograde step before being captured, rather than replacing its double step by a single step. That this is not the same is the fault of an Alice double push not really being two consecutive single pushes.

I still have a comment to make about the legality of moves (an aspect that the diagram doesn't address). The ambiguity here seems to be caused by not making proper distinction between legal and pseudo-legal moves, but heaping them all under the term 'legal'. A more precise description would have said that a move in Alice Chess is pseudo-legal if (before transfer) it would have been pseudo-legal in orthodox Chess on the board where it is made, and the target square on the other board is empty. And then an Alice move is legal (as usual) when it does not expose the King to pseudo-legal Alice capture. This prevents solving distant checks by interposing a piece that was on the board where the checked King resides (but then disappearing to the other board, so that the King can be captured) from being considered legal. Despite the fact that they would have been perfectly legal orthodox Chess moves on the board with the King.

Is it better than Nebiyu?

I though about castling for a while but it does not seem a good thing. It would have involved one step diagonally back which is also uncomfortable. Any thoughts are appreciated.

For this reason I did start the King in Elven Chess on the back rank, and put one of the unorthodox pieces (the Lion) in its place next to the Queen.

@Dax00: I agree completely that calculatory methods for piece values are usually no good. They qualfy as 'fact-free science'. The known values of the six orthodox pieces can be reproduced by infinitely many numerological recipes, which can be designed to give arbitrary values for any fairy piece.

I therefore do always determine piece values in an empirical way, by having a computer program play games in which the pieces are pitted against a combination of pieces of known value, and measure their performance. Through such measurements the Gryphon turned out to be worth about 8.3 on 8x8 (IIRC), on a scale where Q=9.5.

It seems pretty obvious that this piece should be far stronger than an ordinary Bishop. Even the "chiral half" of it (which only has the moves that start with a turn in the same relative direction) has on average more moves than an ordinary Bishop; on non-edge squares it in fact has the same number of moves as a Rook. With both the left-handed and the right-handed moves it doesn't really have double the number of moves, as half of the moves overlap. But even then being able to go there along two paths must be worth something extra beyond having just a single way to get there. (There is no compensation for the fact that the left-handed and right-handed moves overlap on the F-squares, though, as these moves were unblockable anyway.)

No, it would not. Betza atoms never describe null moves (unless one would have defined an atom especially for that), and even if the number of steps is variable, such as in B or R, it must at least make one step and cannot stay in place. The use of the 'a' modifier to define multiple legs doesn't alter that: each leg must at least take 1 step (and if it is a leaper leg, that would be the only step). All the moves you specified are bent two-leg moves, (they have 'fs' after the 'a'), and a Rook move isn't.

BTW, I would use gafscF instead of pafscB1; 'g' describes a range-toggle after hop, as in the Grasshopper (slide -> leap) or Contra-Grasshopper (leap -> slide). What you wrote should also work, but is a bit more cryptic. gafscF means an F step to the mount, followed by a Rook slide that can only capture.

As far as I am concerned, something is broken when doesn't fully work as it should. But this doesn't seem worth quibbling about, as long as we agree there is an issue.

It is unfortunate enough that the list of comments to the Betza Notation article gets cluttered with messages like this not directly related to the topic, and losing all relevance in a short time.

@Ben:

How do you know it is the browser? It doesn't look like it is the browser to me. In FireFox, when I press Shift during reload, it will always bypass the cache for the files the main document links to (like images or JavaScript code). And the main page will never be cached. But that does not happen here: I access chessvariants.com/membergraphics/MSinteractive-diagrams/betza.js directly (so that the browser should never have cached it), and it still shows the old content. When I load the directory it is in, it gives the file with today's download date, so the correct file must be on the server.

When I append the requested betza.js link with a dummy CGI argument "t=19", to be sure no one can cache, I do see the altered content. But if I then omit it again, it reverts to the old content.

This happens on two browsers (FireFox and Chrome). After I use the Chrome menu to delete all cached files, I still get the old contents. I don't think it are the browsers.

I guess adding a dummy CGI argument that contains a dynamically requested time to the link in the page that refers to betza.js should fix it. But it is crazy that such a work-around would be needed.

[Edit] I added the dummy "?t=19" suffix to the link to betza.js in the Betza Sandbox comment, so that this at least uses the updated version. But it is not really a feasible solution to do that in every page that refers to the file. And when I update again the "?t=19" would be the cached version, and all the suffixes would have to be updated to a value never used before...

I discussed this once with an official of the Japanese Chu Shogi Association, who wanted to revive the interest in Maka Dai Dai Shogi, and had written a manuscript defining the 'modern' rules. He insisted that it would be the last piece captured. And for a Lion Dog he insisted that jumping two squares out to capture something, and then retract one square to capture what you jumped over, was not a legal Lion-Dog move, but that you would always have to capture what is on the adjacent square in the outgoing leg if you wanted to finish there.

It didn't make much sense to me. I would also be happy if you were allowed to choose. Of course this is all highly theoretical; no one would allow both his most-valuable pieces to be in Lion or Lion-Dog range.

Such a setup breaks the possibility to change any of the articles and their associated uploaded files, as these are not PHP scripts. It makes you entirely dependent on manual intervention, because any update will with certainty be screened from all remote clients. If you want that, notification of the site admin or an editor that such intervention is needed should be automatic; having to post requests through the comments channel clutters the comments with garbage, as is now happening to this article.

Can the submission / upload script not automatically notify an empowered person that action is required, through e-mail or some specific requesting mechanism? It would of course be even better if these scripts would invoke a program that would purge the cached version in Cloudfare automatically.

Strange anomaly

I have started an attempt to determine piece values on a 12x12 board, about which very little is known. I use Fairy-Max self-play for this. To not make the games too long, the basic start position I use consists of a FIDE army augmented with 4 Pawns (to close the Pawn rank). So the board is pretty thinly popuated. The 4 central Pawns start on 4th rank, to speed up engagement, but the 3 Pawns in each wing start on 2nd rank, to provide some King shelter. The Knights also start in a somewhat advanced position, on 3rd rank behind the central Pawns, as does the Queen (to not have too many unprotected Pawns in the start position.

To determine piece values I delete some pieces from this setup, or sometimes replace them by fairy pieces. The side with the weaker piece can be compensated by giving the opponent Pawn odds, for which I always delete the same Pawn (on the h-file). Such Pawn odds alone results in a 68-70% win of the side with the extra Pawn. I only trust results when the total advantage is closer to equality than Pawn odds.

I don't want to delete more than a single Pawn, because Pawns are highly cooperative pieces, and I cannot be sure that deleting two Pawns gives twice the advantage of deleting a single one. By always granting the same simple Pawn advantage (or none at all), I can get a reliable 'measuring stick' on which the values of other pieces can be mapped. This poses a problem if there is a gap of more than 2 Pawns in the 'piece-value spectrum', though: I cannot play those 1-on-1 without getting an imbalance that is too extreme. I solve that by also introducing fairy pieces with values in the gap, and also determine their value.

I try to avoid Bishops, (and color-bound pieces in general) because of the pair-bonus problem, which would introduce yet another unknown. Which, if not handled properly by the engine, might invalidate the results. So I tried to find a very 'Bishop-like' piece that is not color bound. My first choice was this: to break the color binding of a Bishop, I gave it Wazir moves. To compensate for that (and prevent mating potential), I take away the Ferz moves. But to not affect the more distant B moves, they can still be blocked on the F squares. (So basically this is a Tamerlane 'Picket' + Wazir.)

Such a modified Bishops beats a Knight on 12x12 (as ordinary Bishops also do). The strange thing is that when I then handicap them with Pawn odds, they still beat the Knight, by about the same score. The extra Pawn doesn't seem to help the Knight at all! I have never seen that before; normally deleting a Pawn lowers the score by about as much as the pure Pawn-odds advantage. I watched a few games, and often they end in Knight + Pawns vs modified Bishop + Pawns, where the Knights are still judged by the engine to be ahead (because there are more Pawns on their side). But the Knight then almost always loses. The 'WazirPicket' can easily prevent advance of many isolated Pawns, by guarding a diagonal. And by just stepping in front of a Pawn it attacks as well as blocks it, so that the Pawn easily falls. Even connected passers are easily destroyed this way, if they still have far to go. (And on 12x12 they usually have; I use promotion on last rank only.)

I guess the WazirPicket is just unrepresentatively dangerous to Pawns, in the absence of pieces that can protect those. (And Knights are pitifully slow on 12x12...) So that the value of opposing Pawns shrinks to almost nothing in the late end-game.

My next attempt at a non-color-bound substitute for a Bishop will only change the mF moves of a Bishop to mW, but leaves the captures in place. This will also have the advantage that it cannot be blocked on a square that it doesn't attack, so that it cannot be blocked with impunity (as lame leapers can). Such a piece cannot do more damage to Pawns than ordinary Bishops can, but the mW move does allow it to switch color on non-captures. (Hence I dubbed it Swishop.)

This is very strange. Why do you need custom evaluation for KRK in the first place? Fairy-Max had absolutely no trouble to win KRK on its normal evaluation. (Which has Rooks completely neutral, and use the parabolic centralization table for Kings.) In the latest Fairy-Max version I use what you could call custom evaluation for checkmating a bare King (it just multiplies the centralization bonus for that King by a large factor), but that was only needed for end-games with many centralizing pieces (such as KFFFK in Makruk), because these did not bother to leave the center just for driving a single piece into a corner. Checkmating with Rook is very easy on any size board; you almost need no search depth for it at all. You just shephard the King towards the corner with your Rook, keeping the latter protected from behind by your King.

I suppose you do switch off null move?

The only thing I can think of that causes what you describe is contamination of the hash score with draw scores resulting from repetitions. What happens when you disable repetition detection (accepting PV hash cutoffs)? I don't really understand how a line that makes progress could get draw scores from this, though.

Can you post a game of how it typically plays KRK? (Best would of course be one that it bungles.)

Here is thinking output from a version of Fairy-Max that doesn't use the special bare-king evaluation, for position 8/8/8/5k2/3R4/8/5K2/8 w - 0 1 :

mover viewpoint		fewer / Multi-PV margin = 0 / more
exclude: none best +tail                                          
dep	score	nodes	time	(not shown:  tbhits	knps	seldep)
28	  #12 	121.4M	1:17.65	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kg5 4. Re5 Kg6 5. Kg4 Kf6 6. Re4 Kg6 7. Rf4 Kh6 8. Kf5 Kg7 9. Kg5 Kh7 10. Kf6 Kh8 11. Kf7 Kh7 12. Rh4 
27	  #13 	61.4M  	0:40.03	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kg5 4. Re6 Kf5 5. Re4 
26	  #12 	46.8M  	0:30.38	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kf5 4. Re4 
25	  #12 	28.3M  	0:18.23	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kf5 4. Re4 
24	  #12 	15.6M  	0:09.85	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kf5 4. Kg3 
23	  #12 	10.3M  	0:06.45	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kf5 4. Re4 
22	  #13 	7.44M  	0:04.55	1. Kf3 Ke5 2. Rd3 Kf6 3. Re3 Kf5 4. Re2 Kg5 5. Re5 
21	  #14 	5.88M  	0:03.52	1. Kf3 Ke5 2. Rd3 Kf5 3. Re3 Kg5 4. Re5 Kg6 5. Kg4 Kf6 6. Kf4 
20	  #18 	4.72M  	0:02.74	1. Kf3 Ke5 2. Rd1 Ke6 3. Kf4 Kf6 4. Re1 Kg6 5. Re3 Kf6 6. Re5 Kg6 7. Kg4 
20	  #22 	4.50M  	0:02.59	1. Ke2 Ke6 2. Kf3 Kf6 
20	+4.59 	3.68M  	0:02.07	1. Ke3 Ke5 2. Rd8 Kf5 3. Re8 Kg5 4. Ke4 Kf6 5. Re5 Kg6 
19	+4.57 	2.37M  	0:01.27	1. Ke3 Ke5 2. Re4 Kd5 3. Kd3 Kc6 4. Kd4 Kd6 5. Re5 Kc6 6. Rd5 Kc7 7. Kc5 Kb7 8. Rd6 Kc7 9. Kd5 Kc8 10. Ke4 
18	+4.56 	1.54M  	0:00.81	1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg6 4. Rf4 Kg5 5. Kg3 Kh5 6. Rg4 Kh6 7. Rg8 
17	+4.55 	1.12M  	0:00.57	1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg6 4. Rf4 Kg5 5. Kg3 Kg6 6. Kh4 Kg7 7. Kg5 Kh7 8. Rf7 Kg8 9. Kf6 
16	+4.54 	729185	0:00.35	1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg6 4. Rf4 Kg5 5. Kg3 
15	+4.54 	518699	0:00.25	1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg6 4. Rf4 Kg5 5. Kg3 
14	+4.54 	354924	0:00.15	1. Ke3 Ke5 2. Re4 Kd5 3. Kd3 Kd6 4. Kd4 Kc6 5. Re6 Kc7 6. Kd5 Kd7 7. Ke5 
13	+4.53 	218794	0:00.09	1. Ke3 Ke5 2. Re4 Kd5 3. Kd3 Kd6 4. Kd4 Kc6 5. Re6 Kb5 6. Kd5 Kb4 7. Ke5 
12	+4.53 	150300	0:00.06	1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg5 4. Rf4 Kg6 5. Kg4 Kh6 6. Kf5 Kh5 
11	+4.52 	107753	0:00.04	1. Ke3 Ke5 2. Re4 Kf5 3. Kf3 Kg6 4. Kf4 Kf6 5. Re3 Kg6 6. Ke4 
10	+4.50 	54436  	0:00.01	1. Ke3 Ke5 2. Re4 Kf5 3. Kd4 Kf6 4. Re5 Kg6 5. Ke4 Kf6 
9	+4.52 	36093  	0:00.01	1. Ke3 Ke5 2. Re4 Kf5 3. Kd4 Kf6 4. Re5 Kg6 5. Ke4 
8	+4.51 	20251  	0:00.00	1. Ke3 Ke5 2. Re4 Kf5 3. Kd4 Kf6 4. Re5 Kg6 
7	+4.50 	9192    	0:00.00	1. Ke3 Ke5 2. Re4 Kf5 3. Re8 Kf6 4. Ke4 
6	+4.49 	5719    	0:00.00	1. Ke3 Ke5 2. Re4 Kf5 3. Kd4 Kf6 
5	+4.49 	2747    	0:00.00	1. Ke3 Ke5 2. Re4 Kf5 3. Kd4 
4	+4.48 	559      	0:00.00	1. Ke3 Ke5 2. Re4 Kf5 
3	+4.48 	223      	0:00.00	1. Ke3 Ke5 2. Re4 
2	+4.48 	23        	0:00.00	1. Ke3 Ke5 
1	+4.49 	13        	0:00.00	1. Ke3 

You do realize that this drives up the bandwidth it requires to download the page, and increases the server load? Browsers would display a table of individual piece images without any further server access, once the complete Alfaerie set is in their browser cache. And the most commonly used pieces certainly would be, from visiting other pages on this site. Perhaps a rare piece (such as the Grasshopper) would have to requested once (from Cloudfare!), and then the user would have that cached too.

A monolythic image of the entire position would be unique for every article though, and have to be downladed. Using a PHP script to generate the image 'on the fly' means it cannot even be cached by Cloudfare.

The 'diagram designer' was not made by me, but by Fergus. I am only responsible for the 'Interactive Diagram'. Because you explicitly address me, I will answer for the latter:

It is certainly not possible in the Interactive Diagram to use other board topologies, such as hexagonal bords, or circularly deformed boards. All boards must consist of a corner-connected grid of squares. Irregular shapes of such boards (such as e.g. in Omega Chess, with its wizzard squares, or the citadel of Tamerlane Chess) can be emulated by declaring some squares in the smallest surrounding rectangle to be inaccessible 'holes'. The Design Wizard in the Interactive Diagram article has no provisions for defining those, though. But you can just edit the HTML code that it delivers to add the holes; you only need to define an extra 'piece' with the name 'hole', followed by a list of squares that should be holes.

Now I am confused. I thought you exempted PHP scripts from caching by Cloudfare, through one of the rules. I don't see how it could be otherwise. PHP scripts are running on the server, not in the client. Surely Cloudfare is not running PHP for us? That would be a much heavier task than just caching the output these generate. (And how would it get the scripts? Normally scripts should not be loadable from other machines, just their output.)

Indeed, its absence is unintended. When we split the mc leg into mNmafsWcafsW it does work as intended, so the presence of both m and c on the same leg seems to confuse it. I will have a look at the script, to see if it is just a matter of more carefully recognizing the condition that has to add the pawn on hover, or whether the Betza parser should already split up such move in the internal representation.

[Edit] OK, I fixed it. It was not only that the hover did not work, but the W squares were not indicated at all as (locust) capture targets in the primary move diagram. Turned out the code for indicating those was in a branch that only treated cases where there were no m rights. Now I also test for locust captures on non-final legs with m rights, and that automatically makes the hover work as well.

For 'engine-defined variants', the definition in the fmax.ini file should also specify a 'pieceToCharTable' (to indicate which images should be used for what piece) and a 'parent variant' (normally 'fairy', unless there are some special rules that you want to borrow from another variant, such as a wider promotion zone, or the possibility to gate pieces). They go on the 'Game:' line, after the name of the variant, separated by #, like

Game: frog # PNBRQ.FKpnbrq.fk # fairy

if you want to depict the Frog as an elephant (because the F is in the 7th place of the pieceToCharTable, and WinBoard's 7th piece image is an elephant). The last piece mentioned for each color will always use the King symbol.

It will also be helpful to make Fairy-Max inform WinBoard on how the Frog moves, so that you will be able to play the games with legality testing on. To this end you should append the following two lines to the game definition:

#
# F& FH

This will make Fairy-Max emit a 'piece' command at the start of the game for F (the '&' indicating it applies to F of both colors), to indicate it moves as a (Betza) FH. (The other pieces move as WinBoard would expect a piece with that image to move, so there is no need to (re)define their moves.) Unfortunately Fairy-Max is not smart enough to construct the Betza notation that XBoard needs from the move definition as it was given on the 'f:' line. I still hope that I can make some future version of Fairy-Max work entirely from Betza move definitions in the fmax.ini file, rather than from the list of step vectors and primary/secondary move rights it uses now.

I am sad to say that there still seems to be a problem with the ChessV.Engine.exe WinBoard engine, which I failed to catch and report before, even though I should have realized something was amiss by the long time it took to load ChessV. When I run this engine from the command line, it nicely prints "feature done=1" at the end of a long list of features (ending with the variants feature), in response to "protover 2". But when I run it under WinBoard it does not do that. So that WinBoard, after a timeout (which fortunately occurs after 10 sec, as ChessV did not start with feature done=0), WinBoard qualifies it as a WB v1 engine, which apparently sets the variants list to just the current variant, 'normal'. (This is arguably a WinBoard bug, but it was a hack to make WB v1 engines dedicated to a specific variant, such as TSCP-G work.)

This doesn't seem just a failure to flush the feature done=1 when running under a GUI; in the WinBoard debug log the "feature done=1" never appears, but after sending the engine a move, before it starts thinking, it resends the option definition for "Weakening" instead.

Btw, the syntax of that option definition is wrong (which causes it to be rejected by WinBoard): the closing quote should be at the very end, not immediately after the option name, like

feature option="Weakening -slider 0 0 15"

[Edit] And from the command line it doesn't seem to respond to the 'quit' command.

Well, for one the spaces are missing behind the # and & in the piece-descriptions for WinBoard, which probably leads to WinBoard ignoring them altogether. Which is just as well, as HH and WH are not the Betza notations for the moves of the Hannibal and Waffle: you defined the Hannibal for WinBoard as a Trebuchet-rider. But for Fairy-Max you defined it as a Modern Elephant, which has no moves in common. But even when ignoring the piece definitions, WinBoard will revert to the default move of the piece, which for the Elephant that you use in all cases will be the Alfil move.

The F moves of the Hannibal and the W moves of the Waffle will then be rejected by WinBoard as illegal, when Fairy-Max plays them. And Fairy-Max can recognize checkmates where WinBoard still sees a possibility for the King to escape, to a square that the Hannibal or Waffle attack without WinBoard being aware of it. And then WinBoard would judge the mate claim by Fairy-Max illegal.

OK, I sort of fixed this too. To show the move diagram the move generator must be run in a special mode. Normally (i.e. when playing moves on the board) it would just indicate the pseudo-legal moves. But running t on an empty board for the purpose of displaying a move diagram would then omit all captures. So in this mode it applies extra highlights on empty squares, to indicate what could happen there if it was occupied. In particular red or yellow highlights when enemy pieces could be captured there. (And it also indicates 'virtual' hopper mounts / locust victims on the end-point of non-final legs.)

But the highlighting for the 'destroy' mode (capture friend) is not really well developed. There are 7 possible non-empty combinations of mcd, and mc (yellow), m (green) and c (red) have their own color. There are no distinct colors for d, md, cd and mcd, though, there only is blue. Considering that I haven't really encountered any variant where friendly capture is possible, it seems wasted effort to elaborate very much on this. The problem is compounded by the fact that the highlighting for entering moves is not completely consistent: on empty squares it distinguishes mc (yellow) and m (green), even though capture is never possible there for lack of anything to capture. But actual captures are always highlighted in red, without distinction between mc and c. So when an mcd move hits an opponent, should I highlight in red, to indicate it is a capture, or in blue, to indicate that a friendly capture would also have been possible on that square?

I think the real problem is that the ChessV.Engine.exe is defective; see my posting in the ChessV comments.

Note that Fairy-Max calls this game 'frog' only because the user configured it this way; Frog Chess is neither pre-cofigured in Fairy-Max, nor an XBoard standard variant. It would be just as easy to make Fairy-Max use the name that ChessV uses.

I am not sure it is 'unfortunate' that XBoard protocol only defines a very limited list of standard variants. The problem is that such a list, no matter how long you make it, will never be (or stay) complete anyway. To be future-proof, any name should be allowed. This means the names are not really part of the protocol anymore than the names of chess engines are; they are just data, and the protocol prescribes only what commands should be used to communicate them.

IMO the list of standard variants is already way too long; many variants in the list have no special properties, and only differ from each other (or from orthodox Chess) through board size, array, and piece moves. And the latter properties have basically become freely specifiable parameters for 'engine-defined variants'. So variants like Capablanca Chess, CRC, Great Shatranj really have become redundant, and are maintained only to deal with 'legacy engines'. Because the latter would not reply to the 'variant' command that selected them with a 'setup' command for specifying the array and board size.

The concept of engine-defined variants does raise the problem of name standardization, though. Which becomes more than a cosmetic problem when we want to play engines against each other. Perhaps GUIs should already provide a work-around for cases where engines disagree on the name of a variant they both play, like a per-engine 'alias list' of variant names. Which the GUI then should apply (in either direction) on both variant names received from the engine and sent to the engine.

Ughh, this was a case of a >= that should have been a > in the Diagram script. The algorithm is that the promoOffset is added to promotable pieces (all types from 1 up to and including maxPromote) to get the promoted type. When this gets larger than the number of defined pieces, it is replaced by the promoted type of the first piece. The latter was introduced to not explicitly have to define all the Golds that result from promotion of a host of different Maka Dai Dai Shogi or Thai Shogi pieces; if the first piece is a Pawn, and promotes to Tokin, all pieces that also promote to Tokin can then be put last amongst the set of promotable pieces. After that can follow the unpromotable pieces, and then all the promoted types that are explicitly defined. So if (say) maxPromote=10, and promoOffset=15, piece 1 will promote to piece 16, pieces 11-15 will be unpromotable. Piece 16 and higher are the promoted types. But if only six are defined (16-21), these will be the promoted versions of 1-6, and 7-10 will all promote the same as 1, to 16.

I fixed it now, thanks for reporting.

Just an idea: some chess GUIs allow 'reverse' entry of moves, by first clicking the destination square, and then the piece that should go there. (Usually in combination with some 'auto-complete' mode, where the move is executed immediately if only a single piece could reach the clicked empty square, and pieces that you click move immediately if there is only one place they could go.)

If you would in general allow the origin and destination of a move to be swapped, the difference could in exceptional cases (such as fast castling) be given a special meaning. Such as the reverse order (empty square x King) would indicate the castling, and move the Rook as a side effect.

I always like the 'not castling through check' rule as a form of e.p. capture: the King makes a double step, and can then be taken by a capture-capable move to the square it passed through in the subsequent move. As exposing your King to capture is illegal, such a castling would be illegal.

In this interpretation it would be legal to castle over a square that was diagonally attacked by the Joker from a distance, as after the castling that Joker would no longer move like a Bishop, and thus not be able to execute the e.p. capture of the King. I am not sure how the Joker moves after castling: as a Rook, as a King, both or neither. The rules would have to specify that. If it would move as a King, then a black Joker on e2 would make white castling illegal, as that Joker could in the reply become a King and attack f1/d1. Basically the rule would become: the King cannot pass a square during castling that it could not legally move to.

It is always a tricky question whether a Joker can deliver check. In most positions this is not important, as most moves would alter the Joker's capabilities in a way that resolved the check. But it can be important to distinguish checkmate from stalemate. Basically the question boils down to how the Joker would move after a turn pass of the opponent, because the 'in-check' definition involves the fiction of a turn pass. Must it also pass a turn, or will it just keep the move it had on the turn before? In the former case the position w:Ke3, Je2 b:Ke1 would be a stalemate, in the latter case it might be a checkmate (if white black moved Ke1 on the move before).