Ratings & Comments

Note that I don't want to argue that this is an ideal solution for everything; I just indicate what is already possible in XBoard. The possibility to pop up complex dialogs was inspired by Evert Glebbeek's remark that he would like an engine to be able to use the GUI for design of a new variant (rather than requiring the user to edit config files), through an interface similar to the Design Wizard I put on the Interactive Diagram article here. The described method was trivial to implement in the GUI, as everything was already there. So it was just a matter of allowing the engine to invoke it (rather than a menu click).

Some steps occurring in typical preludes could indeed be covered by regular moves, so that they would not need any special provisions at all on the GUI side. E.g. variants that start with setting up the army turnwise on an empty board could use drop moves, and the engine can simply refuse premature attempts to move around pieces in the setup phase. This can be extended by adopting the conventon that a drop move on a square that is occupied by a friendly piece indicates a swap, and takes the original occupant back into the hand. That way a Superchess prelude could be implemente as: white substitution 1, black substitution 2, obligatory white symmetrizing substitution 2, obligatory black symmetrizing substitution 1, white substitution 3, etc. In Musketeer Chess you don't have to pick just pieces, but also assign them to a file. (Very bad idea, btw...) This could be done by making extra (initially empty) board ranks to drop the selected pieces on. But this would then turn their later gating into a double move, where they have to step forward as a side effect of the piece in front of them moving away. Of course if the protocol extension is used that allows general multi-moving, (as in the WinBoard Alien Edition), this would be no problem. It does seem a bit unclean, though (and for clarity the extra ranks should be differently colored than the normal checkering, so a lot of GUI support). Some people would attach value to the piece and its gating location being visible at all times, but I don't consider that an absolute necessity. (There is also no optical clue for whether you are allowed to castle, so not all game state is always visible.)

I am dwelling on this to decide whether there is any market for a protocol extension that could exchange arbitrary messages between the players (whether engine or human), which would then also switch the clocks and appear as a move in the PGN. E.g. "pseudomove <string>" both for engine->GUI and GUI->engine, depending on who's turn it is. At first glance this seems of little use if the GUI does not know what <string> means. But it could be used to change hidden game state, for instance to assign a file to a piece in hand, to play Musketeer as a modified Seirawan Chess (where the GUI assumes you would always be allowed to gate anywhere). The engines could then communicate the allowed gatings to each other through the pseudomove command, send the actual gating in S-Chess format (e.g. f1g3c to gate a Cannon), which would be understood by an S-Chess-supporting GUI. GUIs especially designed for Musketeer could apply some visible clue to indicate the gating pieces and files, which could go as far as displaying a piece just beyond the board edge. But you would not be dependent on such a GUI feature for playing engine-engine or human-engine games. (If you are willing to put up with the hidden game state.) In the latter the GUI would have to present the <string> to the opponent, and allow the user to enter one by typing. (The general mechanism.)

Note that playing different engines against each other is really something that almost no one does. TalkChess is really a very unrepresentative environment in that respect, full of engine developers and testers. But engine developers, and especially variant-engine developers, are a rare breed. In XBoard the 'second engine' is only used in 'Two Machines' mode. But XBoard is very tightly coupled to the 'first engine', taking it along with everything you do (e.g. in Edit Game mode). This because it originally was dependent on that engine for legality checking of the entered user moves. So what XBoard does is ignore the second engine completely (it is not even started up) until the user presses 'Two Machines'. Then that engine is started, and if it then turns out to not support the current variant, the mode switch is refused, and an error popup appears reporting "Second engine does not support this variant". For variants that are not fully specified (such as shuffle games) the first engine is in charge, and any start position it specifies will be loaded through setboard into the second engine. The engines should better be compatible w.r.t. how the pieces are called and how they move, but that always applies. If they don't agree on the initial setup (like the probably would, in shuffle games) it is no problem, the position indicated by the first (if the GUI or user had no desires on this) would be force-fed to the second to setboard. If they would disagree about piece names or moves this would wreck things, and XBoard currently doesn't check this. But this would always be the case, even in standard variants known to the GUI, where there isn't anything that could be checked. It just means one of the engines is non-compliant.

I guess the real problem is that different CwDA flavors are in fact different variants, so that treating them as a single variant leads to all kinds of unnatural problems. In a single variant, only partially supporting it (like: "I can play Chess, but the Knight is not implemented") is not an option. But there is nothing wrong with supporting CwDA except the Nutters. The only real problem is the unmanageable proliferation of variants this causes when you support many armies. Perhaps the GUIs should just provide a smarter selection method for variants in general, not just allowing ticking of one radio button from a list of 'full' variant names, but allowing a variant name to be synthesized from two parts, each selectable by a radio-button from a list. E.g. the engine could specify it plays rookies~CWDA and CWDA~nutters, where the ~ in the variant name would be recognized by the GUI as having the special significance of defining a partial variant name, where the all-capitals part then would be considered a place holder as well as a group identification. It could then present lists of such 'left' and 'right' partial names in the New Variant dialog, each with their own group of radio buttons and allow selection of two compatible (i.e. belonging to the same group, here 'CWDA') partial variants (and refuse 'OK'ing the dialog for incompatible selections), and combine the partial names to 'rookies~nutters' to get the selected variant. Depending on the preference of the GUI developer this could also be two combo-boxes (for left and right partial name), or even an arbitrary number of pairs of comboboxes (one for each variant group). The list of 'full' names would probably list 'selected below' as one of the possible choices to enable the comboboxes for selecting the partial names. Or one radio button for each variant group. E.g.

o normal

o xiangqi

o shogi

o CWDA: [combobox1] ~ [combobox2]

[Cancel] [OK]

The (first) engine would have full control (through its variants feature) over how this New Variant dialog would look. (And pedantic GUIs could ignore things in the list that they don't like or don't know; e.g. the standard edition of WinBoard would ignore variant tenjiku.) If a match with the second engine is attempted, the GUI will check if the current variant is in that engine's variant feature directly, or as a combination of partials. And refuse the request to play the engines against each other when it isn't.

This moves the selection of armies from the engine's private option settings to the GUI's variant-selection dialog, which is what you want. The variant is a common setting for both engines, so it also removes the problem of  'engine coherence', which is what I like about it.

I have some misgivings about engine-defined options that should be standardized, recognized by the GUI, and displayed in a separate dialog. This is just not what the option feature was desigintended for. For comparison: WB protocol allows 'size overrides' on variant names, like 5x5+5_shogi. (And users can select such variants in XBoard by using size-override rank, file and holdings controls in the New Variant dialog.) Normally the engine would consider each differently overridden version of a variant a separate variant, and list it as such in its variants feature. (E.g. Shokidoki lists shogi, 5x5+5_shogi (= mini-Shogi) 6x6+6_shogi (= Judkin's Shogi), 7x7+6_shogi (= Tori Shogi) and 8x8+6_shogi (Euro-Shogi). But I also did define a standard pseudo-variant 'size', where 10x10+0_size in the variants feature would imply that the engine will accept size overrides for board sizes up to 10x10 (but no holdings) on any of the reported variants. This is very similar in purpose to your concept of game variables, like having spin options for ranks and files with maximum 10. The equivalent of your castling option in this form of the protocol would be to allow a 'flex_' prefix on any variant name to indicate that variant uses flexible castling, (e.g. flex_capablanca) and define a standard pseudo-variant flex_castling to indicate that every supported variant also is offered in the 'flex' flavor. (Basically just a short-cut, to prevent very long variant lists.) GUIs understanding the flex_ thing could display / enable a checkbox 'flexible castling' in their New Variant dialog. This way of doing things looks more natural to me, because it puts the modifiers where they really belong: they basically create different variants, which deserve to have different names.

The Daring Dragons

I designed a new army, which in tests with Pair-o-Max scores about equal against FIDE. I named it the Daring Dragons.

Interesting feature that sets it apart from other armies is a piece with an unusual (meta-)color binding, the Dragon Fly: this is bound to even or odd board files, along which it moves like a Rook. It can switch between files through a sideway Knight jump. (It is in fact half a Chancellor.) It is worth slightly less than a Bishop, and can often force checkmate on a bare King. The other light pieces is the Man / Commoner, but to facilitate its development (which would otherwise heavily compete with that of the Dragon Fly), it has some additional initial non-capture Knight jumps. It is called a Dragoon. (Dragoons are mounted infantry, using horses for mobility, but fighting on foot.) The Rook replacement is the Dragon Horse known from Shogi (moves as Bishop or one step orthogonally), worth slightly more than a Rook.

The super-piece (called Wyvern) is a somewhat weird construct; first I wanted it to be a Centaur (Knight-Man compound), but then the army proved too weak. Then I replaced the wide Knight moves of the Centaur by a sideway Rook slide, to also have the latter in the game. This makes it a compound of a Man and a 90-degree rotated Dragon Fly. But this was not really stronger than a Centaur; with either the army scored only 40% with black. A sideway Rook slide should be worth more than four Knight moves, but the Centaur already covered the first step of it, so it did not add enough. I also did not like its low speed in the vertical directions, which was unworthy of a super-piece. After some experimenting, a compound of a rotated Dragon Fly and a Bishop proved a little too strong (60% against FIDE), although not out of line with what the other CwDA armies do. A suitable way to weaken it to exactly match FIDE was to replace the sR slide by a ski-slide, skipping the first square on the ray (jumping any occupant if needed).

Ski-sliders are interesting anyway: on a near-empty board they are obviously inferior to the corresponding ordinary slider, as they lack the moves to the adjacent square. That the more distant moves cannot be blocked on that square is of no import if there is nothing around to block them. But on a crowded board, where slides almost always are blocked before they hit the board edge, the ski-slider will have the same number of moves as the normal slider, each target just being moved outward one step. Which should make them nearly equivalent. So ski-slider strength will depend in a different way on game phase as the other pieces, relatively decreasing towards the end-game.

The castling issue is a good example of the different design philosophies that are possible, so let me respond to that first. If an engine supports Capablanca Chess, it is unlikely to support flexible castling. The only reason why the author would care to support such castling is that he is aware of Scholbook Chess, and wants the engine to be able to play that too. But if he wants that, why would he want the user to alter the start position (through setboard) and the castling rules (through an option) separately? It would be much simpler, for him as well as the user, to just add Schoolbook as an additional variant the engine can play. If there are other 10x8 variants that use flexible castling, but have a different start position from Schoolbook, these could then be played as sub-variants of Schoolbook (through setboard). Variants without castling are sub-variants anyway, as you can simply specify a start position without castling rights.

Having a castling option is a step towards defining the variant for the engine through option settings. If you have an option for castling, then why not one for how the super-piece moves (Queen / Chancellor / Archbishop)? Or options for how any piece moves? Or how large the promotion zone is? Or what you can promote to? (To play Janus as sub-variant of Capablanca.) This would all be possible, of course; it would converge on a design where the GUI manages all game descriptions (be it hard-coded or through a configuration file that the user can edit), and then instructs an engine how to play it.

This is not how existing multi-variant engines such as Fairy-Max, Sjaak and Nebiyu work, however. These manage the file with game definitions themselves. Which seems the logical way to do it, as then the file can also contain engine-specific info. (Like which pieces have mating potential, value of pair bonuses etc.)

Because of the way XBoard started (as merely a graphical front-end for an already complete ASCII-based user interface) things tend to be 'engine-centered' in WB protocol. From the early days on XBoard could already be used to play variants (as long as they were 8x8 with no more than 6 piece types, such as Shatranj) by switching legality testing off. (In fact in the earliest version it could not even be switched on, as legality testing was not implemented at all. Even when I first started working on WinBoard myself in 2008 it did not know about castling rights, and would always accept any castling.) Historically it was up to the engine to refuse moves it considered illegal, on which the GUI would retract the move and relay the info to the user. Downsite of this is that the GUI cannot indicate target squares of a move when pieces might move different from normal, and that it will generate crappy SAN (with missing or redundant disambiguation, but which it would still understand itself on reading it back).

I generalized the 'legality off' capabilities a bit by attaching a meaning to some otherwise unused combinations of mouse clicks; e.g. any sideway move of a King by more than 2 spaces is now interpreted as an attempt to castle with the corner piece in that direction (whatever it is), while dragging the King on top of the corner piece would be castling with it where the King steps one. (In all cases the corner piece ends up on the other side of the King.) Unless Fischer castling is specified by a GUI option (which by default is set for FRC and CRC), then capturing an own backrank piece with the King indicates castling with that. This covered all cases I was aware of, so the GUI doesn't really have to know the game rules to interpret the user move; assuming that what the user tries is legal, it will interpret it correctly. The engine watches over the latter, by forcing the GUI to take back whatever illegal thing the user might have done.

For better GUI performance w.r.t. SAN and target-square highlighting, however, it is essential that the GUI is also aware of the rules. Logically there are 3 ways to accomplish this:

1. Both the GUI and the engine are programmed / configured for the same rules independently.
2. The Engine transfers the rules to the GUI
3. The GUI transfers the rules to the engine

Your castling option is an example of the latter; through engine-defined options any info can in principle be transferred in this direction, but some standardization would have to be developed to make it possible for the GUI to do this automatically (rather than having the user decide on a per-engine basis what is necessary). For the start position the protocol has the setboard (or edit) command. For case (2) I extended the protocol with a 'setup' command as a reverse setboard, (plus a list of participating pieces) and 'piece' commands for defining piece moves.

Fairy-Max and Sjaak || use method (2); their game-definition file specifies how castling is to be performed, and (if this is non-standard) they inform the GUI of it as part of a King-move definition, e.g. "piece K KisO4", where the isO4 is the XBetza notation of a castling where the King moves 4 squares. Through this info XBoard itself can then already refuse any attempt of the user to move the King other than 1 step or slide it 4 (if still virgin etc.) without first consulting the engine. (And does this by not even highlighting other King destinations, and in general refusing any move to a non-highlighted square.)

I guess we agree that method (1) is undesirable; this was basically the situation that existed before introduction of the setup and piece commands, where the user had to provide a FEN (and even in an indirect way, as a .fen file with a GUI option referring to it) and a -pieceToCharTable option to specify the FEN's meaning, and switching off legality testing when standard glyphs were used to represent exotic pieces not in the standard set. For the case of castling it seems to me that method (2) is more direct than (3). In all cases the engine would have to announce something to the GUI at startup, either that it has a castling option that features 'flexible' as a choice, or just that it supports Schoolbook. In the case of the option the GUI will have to recognize it, look up in a list of known variants which variants would need any of the available settings for that option, and enable selection of those variants by the user (if their other requirements are also satisfied). In the other case it can just enable selection of 'Schoolbook' without having to worry about anything, or even know what 'Schoolbook' means. When the user decides to select Schoolbook, in the case of the option the GUI would now have to set the castling option in the engine to the value it knew to be required for Schoolbook, as well as enable that type of castling in its own move generator used for legality testing / square highlighting / SAN parsing and generation. In method (2) it would just configure its move generator likewise because the engine tells it so through a piece command. Again, it did not need to have any pre-programmed knowledge for that. The 'piece' command can be considered in this case just as a (somewhat cryptic) command to set a GUI option for the type of castling. This is much less of a hassle for the GUI.

I am perfectly happy with XBoard being a 'dumb' GUI, which leaves the engine in charge. But if you want ChessV to be a GUI that knows about many variants, and makes conclusions about which variants not explicitly supported by the engine can still be played as sub-variant of some other, supported variant, method (2) would still allow you to do it. In all cases the GUI would look which variants the engine supports, and what aspects of variants the engine allows to be changed in general (startposition by setboard, possibly other options), and then can run through its list of known variants to see which can be run as sub-variant. It doesn't really matter if a 10x8 variant has to be run as Capablanca + setboard + castling=flexible or through Schoolbook + setboard. If you want the GUI to have intrinsic knowledge of what Schoolbook is, it can simply ignore setup or piece commands the engine sends to specify start position and castling type.

Sorry it has taken so long to get back to you on this.  A lot to chew on here.

First you mentioned engine-defined variants the GUI doesn't understand but still allows to be played.  ChessV doesn't do this, and it's not high on my list of things to do, but there is certainly some value to it so it would be best if whatever we settle on supports this.

Then you mention my game variables concept and the more general concept of allowing engines to suppy additional options as things change (variant selected, other options selected, option buttons clicked ...)  Certainly the more general concept has value, but I also think there is value in being able to specify that an option is a game-specific variable.  This would make clear that, not only does the option only apply to a specific game, but that the option affects the rules of the variant being played and not just the internals of the engine AI (although it could certainly do that too.)  This tells the GUI that, in order to play, both engines must support the same options, and both should be automatically set to the same values after the user selects them.  And I think it makes sense that these options should be presented differently because they are an essential part of selecting what game is being played.  In ChessV when you select Chess with Different Armies, the first thing you get is a dialog box to pick your armies with random armies pre-selected.  (The same thing happens if you pick Fischer Random Chess - you get a dialog with a random position number selected, with a preview, but you can change it if you want to play a specific position.)  I think game variables can offer a better user experience - if you don't care about, or even don't understand hashtable size, etc, who cares, but you better understand what the armies are.  Picking the armies is part and parcel of picking what variant you want to play.  And, also, some engines might play CwDA and offer extra armies that others do not.

Another thing I like about game variables it the potential they offer to allow an engine to play variants it wasn't specifically designed for.  ChessV has some understanding of this now.  If the user selects Corridor Chess, it is smart enough to offer as options any engine that supports both orthodox chess and the setboard option.  Likewise, if it offers variant capablanca and has setboard, it will be offered as an option for Modern Carrera, but not for Schoolbook because of the flexible castling.  (You did propose a clever workaround for this but I haven't got around to implementing it.)  But engines that support flexible castling should offer the "Castling" option of "Flexible" in variant capablanca.  Then, even if they don't know Schoolbook, Grotesque, or Ladorean, they can still play them, along with new variants that meet the same rules.

10x8 is popular, in the sense that there are lots and lots of variants, but almost all use one of a few castling rules, which I have named "None", "Standard", "Long", "Fexible", "Close-Rook", and "CRC".  Likewise, on a 10x10, there are only a handful of castling rules, and a handful of rules for the pawn's multi-step moves that cover most games.

About a year ago you mentioned working towards a standard for defining variants so you don't have to configure Fairy-Max in one way and SjaakII in another.  I think this is also worth pursuing - it would be awesome if we could acheive it, but this is a steep mountain.  I respectfully suggest that this would make a good first step.  This is the low-hanging fruit...

Ok, good to know that I don't need to worry about that.  I was wondering because I have been experiencing some stalls when running ChessV vs. Fairy-Max games in batch mode and it only happens when Fairy-Max declares a draw and then only sometimes.  I don't think it's related to this issue though.  So I'll have to keep digging.

Regarding playing CwDA through CECP, this game presents some interesting challenges, most notably army selection.  Given the current state of affairs, there are two obvious approaches, but neither is great...

1.  We could consider each army match-up to be a different variant - FIDEs vs. Rookies is one variant and Rookes vs. FIDEs is another.  This is a little cheesy and leads to variant explosion.  Essentially CwDA becomes two to the power of the number of armies different variants.  That said, this is probably the easiest.  I think ChessV can do this now with no modifications to the code at all.  We could always start here and be up-and-running in no time and just back out these "dummy" variants later.

2.  We can do what you are doing now - have engine paramters for army selection.  This is arguably better, but I don't love this option either.  We are adding engine-level settings for things that only apply to one game.  This is somewhat cheesy, unintuitive, and doesn't scale well.  What if we have a different variant that also has army selection but different armies for choices?  What happens when we start adding configuration parameters to other variants?  (ChessV already has configurable game-specific options for other things, such as the castling rule in effect in Capablanca variants.)  I don't mind altering ChessV but when I add things I always try to add them in a general way.  I'd rather not add code just to "hack" this one specific variant.

I think what we want - ultimately - is a new concept.  ChessV has "game variables" which are configuration options that apply only to specific games.  Conceptually, this is exactly what we are trying to accomplish.  Ideally, CECP would be given a new feature which engines could declare support for.  If an engine announces support for game variables, the GUI could then ask it, for any given game, what options it supports.  But I realize that this requires significant changes to XBoard/WinBoard, and it is probably no small undertaking.  But I think it's something worth striving for in the long term, and would pay dividends down the road.

Actually, we might be able to get there with the first step just being naming convention.  If we make "cwda" to be the Chess with Different Armies variant, maybe the options could be named like "@cwda:White Army", for example.  At first, WinBoard could just treat them like any engine options.  But in future, it might parse the option name to understand that it only applies to variant "cwda".  Just thinking out loud here ... haven't considered it deeply.

That is purely a Fairy-Max problem. It has a pretty sloppy CECP parser, which doesn't bother to recognize most commands that require no processing (e.g. accepted, rejected, computer). 'Result' is also a no-op for an engine that doesn't implement learning. A GUI should not worry if an engine complains against non-essential commands. I think WinBoard only reacts to rejection of time/otim commands (concluing that it must be ealing with GNU Chess, and refraining from sending these commands for the rest of the game), and 'analyze' (informing the user that the engine doesn't support it, for the benefit of WB v1 engines that haven't announced this in advance through a feature analyze=0).

Before I get into playing CwDA, I want to ask a question first because I'm trying to debug something and really want to knock this out ...  When ChessV hosts Fairy-Max, I sometimes have issues with game termination when Fairy-Max reports a draw.  Here's a sample of the relevant part of the log:

<Fairy-Max 5.0b(0): move g8g7
<Fairy-Max 5.0b(0): 1/2-1/2 {Draw by repetition}
>Fairy-Max 5.0b(0): force
>Fairy-Max 5.0b(0): result 1/2-1/2 {Drawn game}
>Fairy-Max 5.0b(0): ping 28
<Fairy-Max 5.0b(0): Error (unknown command): result
<Fairy-Max 5.0b(0): pong 28

Fairy-Max reports the draw by repetition.  (It is correct.)  ChessV then turns around and tells Fairy-Max that the game is over and Fairy-Max complains that it doesn't know what "result" means.  Is this a problem with ChessV or with Fairy-Max?  (Should I not be reporting that the game is over?)

@Greg

Any progress on this? I am contemplating to also return to piece-value measurements. Because I want to measure the more subtle effects, such as mating potential and pair bonuses, this will require a less course approach than Fairy-Max. I have started to extend the capabilities of my engine KingSlayer (originally released as 'Simple', until I was told that name was already taken), which I wrote a few years ago as a demo source code for orthodox Chess somewhat more advanced than TSCP, to also support fairy pieces. And in particular CwdA. So I changed the move generator to support limited-rage sliding/riding on a per-move basis. (For Chess it was done on a per-piece-type basis, and the range could only be 1 or infinite.)

As that engine only supports 6 piece types per side (which, with a little bit of work, could be expanded to 7), I implemented this by initializing the tables with piece properties it uses during play from a larger table that contains descriptions of all supported piece types. (So far the 16 piece types of the 4 classical CwdA armies.) For a particular game it then just picks up to 4 of these in addition to the always participating P and K. Unlike Fairy-Max, this engine has a dedicated check test (rather than just trying a null move and wait for a King capture), and this had to be extended too in order to handle the new moves. Basically it works by having a 15x15 'board' indexed by the relative distance, where for each step a bitmap indicates which piece type in principle could make such a step, where for sliding moves a contact threat is distinguised from a distant one (to easily see if you need to test for blocking). By making use of the fact that some pieces are compounds of others (like Q=R+B), and decomposig some pieces into 'primitives' to make even better use of that, the number of different primitives needed to support CwdA was 13, too large for the byte originally used for this purpose, but less than half a 32-bit integer, so that I can now even use separate bits for white and black attacks, eliminating the need to test the piece for being an enemy by other means. This type of check test would become more cumbersome with hoppers (where you don't only have direct and discovered checks, but also have to deal with 'activation' by interposition), and very awkward in the presence of bent sliders (like the Gryphon). So this engine will probably never support those kinds of moves. Divergent pieces would still be a realistic possibility, though.

Unlike Fairy-Max this engine does have an advanced Pawn-structure evaluation, (e.g. passer recognition), which is directly usable in CwdA, as that uses the same Pawns. It did keep track of the number of pieces of each type that are still present, and used this to award a Bishop pair bonus (if there were two), or discount the static evaluation score when mating potential gets into jeopary for lack of Pawns (i.e. with 1 Pawn or less). This will have to be substantially refined, though, as with multiple color-bound types cross bonuses are to be expected, and you cannot conclude from the piece counts alone whether you have a pair or not. Also drawish cases similar to 'unlike Bishops' cannot be recognized this way, which was already a weakness in regular Chess. So I plan to add a 'material hash', which uses a hash key that depends on the present material, but counts color-bound pieces of the same type but on different square shades as different. (This can be done through a Zobrist-like hashing scheme that doesn't assign a different key to a piece type for each board square, but just one for each 'meta-color' relevant for that type.) Which piece combinations will have mating potential will now depend on the army, and will thus require a more complex analysis, but if the results of that analysis are kept in a hash table, this will not impact engine speed.

BTW, other types of (meta-)color binding can be interesting as well. E.g. odd/even file binding, such as for vRsD, which does have substantial mating potential. (Although a fortress draw is possible when the bare King cannot be cut off from the safe edge. A vRsDD would even be better in preventing that.)

You mentioned lack of standardization presenting a problem for having XBoard engines playing CwdA in ChessV. What would be needed here? Now that I am making KingSlayer into a CwdA engine, it might be good to have a closer look at the specific problems, and try to find ways to remove those. At the moment I have KingSlayer report in the CECP variants feature that it supports variant 'fairy', and gave it engine-defined combo options 'White Army:" and "Black Army:" that can be used to select the flavors FIDE, Clobberers, Rookies or Nutters, and will determine what variant fairy means. But in addition to that I could allow setting of the default value of those options through arguments in the engine command (so that you would never have to bother setting the option).

I see 12 moves and only 5 cards. How are moves distributed on each card ?

That's just the default behavior for a new submission, since most user-submitted pages are their own inventions.  I've updated the information.  Thanks!