Ratings & Comments

I have now added a message to that effect.

Which logical coordinates examples should I use in order to understand how to program griffin and aanca?

For now I'm not cpapable to do them!

That's right.  If it doesn't show anything then there are no time controls.  It would be better if there was a message to that effect.

I see that only in one case. I assume the rest of challenges are of the N/A kind!...

Time controls are shown right above the "Accept" button.

As I don't seem to find the answer myself: Is there a way to know before accepting a challenge what time requirements the game will have?

I've added to my previous post with some edits, in case anyone missed it.

If you mean the Frog Chess variant that I invented some year(s) ago, and submitted to this CVP website, I only know of the games that have been played so far on Game Courier (on this website), and at the moment there's been no draws in about 17 games (one opponent long ago deleted an unfinished game I had been playing with him, after he apparently realized he had been counting on an illegal frog piece move, that he tried soon enough).

However, other than myself, I don't know of any chess master who has played Frog Chess on Game Courier. Below elite player level in chess (that is, well beyond master level), draws are far less likely, in over-the-board games, simply because there are more mistakes made by non-elites, and it's assumed a very well played game of chess should end in a draw.

I don't know of the drawing percentages for Capablanca Chess, but on Game Courier (on this website), I wouldn't be surprised if there are next to no draws, even though many games have been played with it. Again, one reason would be that the players here are nowhere near world chess elite strength in terms of skill at chess or other chess variants, as far as I know, and my own guess is that Capablanca Chess is far from being an extremely drawish game (the same would go for Frog Chess). Lastly, it may be worth noting that there are no books on Frog Chess or Capablanca Chess (afaik), unlike for chess, so players of any level would be feeling their way in the dark rather more.

Here's a link to the logs of finished Frog Chess games as played on Game Courier so far:

https://www.chessvariants.com/play/pbm/logs.php?game=Frog+Chess&age=0&stat=finished

[edit: Here's a link to the logs of finished Capablanca Chess games played on Game Courier so far - one in 45 was drawn to date; it was one of my games, agreed drawn since there was a long delay before a bug to the preset was fixed, a bug which affected that game in particular:]

https://www.chessvariants.com/play/pbm/logs.php?game=Capablanca+Chess&age=0&stat=finished

[edit: Here's a link to the logs of finished Chess games played on Game Courier so far - ten in 159 were drawn to date:]

https://www.chessvariants.com/play/pbm/logs.php?game=Chess&age=0&stat=finished

[edit: For what it's worth, in International Master John Watson's 1998 book, Secrets of Modern Chess Strategy, he quotes monster chess database figures as 40-30-30 in terms of post-1965 White win-Drawn-Black win percentages for all levels of competitive tournament chess players taken as a whole, and says these rates have been quite stable; note the figures also mean that White scores 55%, and Black 45%, in terms of results.]

How does Frog Chess compare with normal chess and Capablanca chess in terms of percent draws?

In FIDE chess, 1.e2-e4 d7-d5 2.e4xd5 Qd8xd5 3.Nb1-c3 Qd5-d6 is a very popular way to play the Scandinavian Defence for Black these days, and so the sequence 1.e2-e5 d7-d4 2.e5xd6e.p. Qd8xd6 that you mention in your proposed variant would seem to be a whole tempo up on that popular Scandinavian Defence line for Black (although the pawns move differently here, it may not help White out much by comparison). So, at least for the sequence you gave, Black is not clearly hurting because of the different pawn rules.

Today I was thinking about large board variants and their typical "two step" pawn-at-any-time option and "three step pawns" and I thought of a possible idea for pawn movement in general, for ALL board sizes, even 8x8 or smaller.  The main idea is a way of speeding up the game and giving pawns just a bit more power at the right time, while keeping some restraints.

So here it is: what's to stop us from playing with pawns that can slide straight forward as far as they want?  They still capture only one square diagonally.  My added rule is this: ANY piece or pawn can capture en passant at any square that it just moved through.

1. e5 looks too powerful for White as a first move, but what about 1. .... d4 as a response?  If e x d6 e.p. then Qxd6.  Black isn't hopeless here. 

Admitedly I haven't studied it much or played it, but let's discuss!

Although I haven't got a response to my ticket, and the host still says "Virtual server not found", things do appear to be working again.

As far as I can tell, there is a problem with the server. It is somehow partly online and partly offline, and it is also affecting my blog, which has its own domain. I have submitted a ticket about this to the hosting service, and they will hopefully do something about it.

Testing again. The host says " Virtual server not found ", but pages are showing up, and I was able to log in. I haven't been able to move in Game Courier all day. I get 520 errors when I try to, but I've seen that other people have moved today.

I had this problem in the past but I thought it had been resolved ... six months ago maybe?

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.

Testing.

A while ago, one longtime member shared with me an extortion scam email he had received that included his CVP password in it. Today I received a similar email that included my CVP password. If you get such emails, just ignore them. It talks about installing malware on your computer, recording your passwords, recording you through your webcam, then conveniently removing all trace of the malware from your computer. It's just a scam, not a real extortion threat.

I don't think it's a coincidence that the password it included in the email was the one for this site. Until just now, I had not changed it in years, and several years ago, all passwords here were encrypted as MD5 hashes. This is very insecure, because there is a fixed relationship between the original word and the encryption, which allows people to build translation dictionaries that can identify your password from its MD5 hash.

If there were really malware on my computer monitoring my passwords, the hacker could just as easily steal my Paypal password, which would prove lucrative without going through the trouble of trying to blackmail me.

If you have not changed your password in a long time, it will still be encrypted as an MD5 hash. To fix this, sign in and change your password. Your new password will be encrypted in a format that does not have a 1-to-1 relation with the password, and it will be much more secure. While you could keep the same password and just update its encryption, that is what I had done, and this email proved that this was not enough to protect my password. The best thing you can do to protect your password is to change it.

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.

Hello. Do you have a clear, detailed video tutorial on creating your own chess pieces and variations? By changing the rules? Is it possible to introduce a diagonal on which some figures could be amplified? Is it possible to introduce pawn castles, so that the pawn could swap places with its own figure standing in front and walking diagonally, that is, with the queen, bishop, wizzard, lion, zanny ...? should only be transformed into the figure that stood on this square, only on the royal square in anyone?

I don't read Russian, but I will ask my wife to take a look.

Hello. Do you have the opportunity to add a description of this type of 100 chess to your site, as well as the opportunity to play it on ChessV?  http://lotos-khv.ru/game/games/chess100.pdf

I have had some more time to test.  This is a really an excellent CwDA engine.  I think I have found another bug though.  In one game, it insisted ChessV made an illegal move when the move was fine.  In that game, ChessV was white playing the nutters and KS was black playing the rookies.  KS promoted a pawn on g1 and chose to promote to a colonel.  ChessV then moved the king to g4 and KS called this an illegal move, presumably thinking that its colonel on g1 attacked it.

So I think the issue is that when KS plays black and promotes a pawn to a piece from white's army, it thinks that the piece moves "forward" as a white piece instead of as a black piece.

Also, good catch about the memory usage.  ChessV does not yet offer an xboard engine's configuration options but as a stop-gap I have added settings for the generic "memory" and "cores" options and it will supply them to xboard engines that support those featuers.

@Aurelian

Please note that the pair of personal invitations you gave me recently 

Modern+Chess&log=-Vernon+Parton-2019-159-445

Symmetric+Chess&log=-Vernon+Parton-2019-159-446

were wrongly addressed to a Game Courier user that does not exist: carlos cetina (with lowercase initial letters).

I am registered as Carlos Cetina (with uppercase initial letters) and userID: sissa.

Such logs are not listed in my "Your Games on Game Courier" page.

Now then, regardless of this random fact, I'm sorry to tell you that I'm currently focused on promoting the Symmetric Chess only; and, for reasons of time and energy savings both physical and mental, I have decided not to play other variants except those included in the current tournament.

So my dear friend, send me all the invitations you want as long as they be of Symmetric Chess!!!

Are you sure you got the new version, and that there was no problem with your browser caching the old version? It should say cwda-1.3 for the version number, and have 'dragons' as one of the options for the White/Black Army (not properly working yet, though). I tested it with a position "8/6P1/6k1/8/8/8/8/1K6 w - - 0 1" in FIDE vs Rookies, and it does play g7g8q without quote in that position.

In earlier versions I had some crashes too, which seemed to occur when the score got extreme. This disappeared after I calculated the interpolation between opening and end-game evaluation in a less overflow-prone way, and the version I originally posted had played several hundred games against Fairy-Max without a single crash. It could be that I broke something when changing the check test to also work with ski-slides. (But I see in the log that this happened for 1.2, so this cannot be the explanation.) This crash also doesn't reproduce.

Indeed I did not put equal armies in the list it announces in the variants feature. It would recognize the names in the 'variant' command, but of course a proper GUI would never send those if the engine did not announce it supported those. It is possible to play equal armies by selecting those through the White/Black Army options, and then select variant fairy. (This is how I test, as it currently is the only method where it is compatible with Fairy-Max, when I tick the option for old piece names, and turn traitor promotion off.)

BTW, in the log I see that you did not send a 'memory' command to set the hash size. That means KingSlayer would use its default hash size, which is only 1MB.

Also, it looks like it doesn't support both sides playing the same army?

Sorry, H.G., it looks like that did not solve the problem.  I am also getting an occasional crash.  I'll email you the debug output.  But when it doesn't crash or make illegal moves, it seems to win the majority of the time :)

A yes, this was something I couldn't test, because WinBoard doesn't accept dressed letters as promotion suffix yet. This was a bit of a subtle bug: the quote suffix was initialized to 0 when entering the MoveToText routine, and then set to a quote if promotion to the 7th piece type occurred before being printed. But by an oversight the suffix had been declared as a static char, so the initialization did not work on every call of MoveToText, but only at program start. So once a move with quote suffix was printed, all promotions would from then on be printed with this suffix. (But WinBoard happily ignored that.)

I uploaded a fixed version to the same link.

Nice!  I didn't have an opportunity to mess with this during the week, but I now have KingSlayer cwda integrated within ChessV cleanly.  It is pretty strong!

I am finding one issue, though.  Sometimes upon promotion KingSlayer sends the wrong notation. For example, ChessV was playing the Clobberers with the white pieces and KS was playing the FIDEs with the black pieces.  When it went to promote, it sent c2c1q' which is not correct.  The Queen is part of its army, not the opponents, so the quote shouldn't be there.  (ChessV then says it forfeited due to illegal move.)

The previous version was still plagued by a woken-up 'sleeper bug': all the end-game discounting worked fine when I tested it on setup positions for the end-game, but it did not apply it when the same end-game was reached in games! Turned out castling messed up the Rook counter, which had never mattered before, as the count was not used. But now it made the drawishness code think both sides had (tons of) Rooks. I uploaded a fixed version ("KingSlayer cwda-1.2") to the same link. This also prints some results of the drawishness detection for the root as part of the Thinking Output, so that it can be easily seen when it misjudges. Like Fairy-Max it slightly randomizes the first 8 ply of any game, (adding -8 to +7 cP to the score of each move in the root), to provide more game diversity in test runs.

OK, I seem to have produced something that works according to specs. I uploaded it to http://hgm.nubati.net/CwDA.exe. I had it play matches against Fairy-Max in FIDE-Nutters and Clobberers-Rookies, and there don't seem to be any illegal moves anymore. I did this using the old piece IDs of Fairy-Max, but in the uploaded version I replaced this by the new IDs we agreed on, but added a checkbox option that can be used to select the old IDs. The piece-to-char tables sent in the 'setup' command still always use the old IDs, though, and don't provide IDs for pieces of the opponent army; this is still something I have to fix. But I am not sure ChessV even looks at the setup command, and the pieceToCharTables probably have meaning for Win/XBoard only.

I also added a checkbox option 'Traitor promotion', where you can switch the possibility to have it promote to the super-piece of the opponent army on or off.

[Edit 2019-05-28] I fixed a problem with input of under-promotions, (which could not be tested by playing against Fairy-Max, as it never does those). It now also can do all under-promotions to pieces of its own army (the FIDE version of KingSlayer only considered promotion to Q and N, but not in all armies the other pieces are as redundant as B or R). The pieceToCharTables in the 'setup' command now use the piece IDs that are selected by the old IDs option, and merge in the super-piece of the opponent army, if the 'Traitor promotion' option is enabled.

I currently put an extra ~ in the names compared to what I proposed here earlier: A~B~(C) instead of A~B(C). This looked more balanced (the latter form suggested a tighter coupling between B and C). This would also make it possible to recognize '1-parameter' sub-variants by the ~ alone, e.g. bird~(10x8), carrera~(10x8).

Name explosion would occur when a sub-variant needs multiple parameters (such as CwDA); with a single parameter the possible parameter values would have to be mentioned anyway. We could solve it by introducing wildcards for the parameters: nutters~*~(cwda) would mean the variant group 'cwda' has two parameters, and 'nutters' would be a possible value for the first parameter. Such a partial variant declaration would be discarded if there weren't also declarations of the form *~rookies~(cwda) in the variants feature to specify some possible values for the second parameter. This is not backward compatible with existing GUIs, though; these would not recognize the * as wildcard, and take the names litterally. This problem could be ameliorated by making the engine such that it would also accept the names with the wildcard in it in the 'variant' command, and would treat the parameter value * as a command to keep the previous value of that parameter. A user could then still make the selection Nutters vs Rookies by first selecting nutters~*~(cwda), and then switch to *~rookies~(cwda). (On second thought, we could adopt the convention that a second parameter that is only given as a wildcard in all the supported sub-variants would be assumed by the GUI to allow the same values as the first parameter. The engine, when confronted with * for this parameter, could then use the previous value of the first parameter for it.)

BTW, many of the problems you mention for Cylinder Chess sound familiar. I remember that at some point of implementing XBetza support in XBoard I decided moves should be generated after 'lifting' the moving piece off the board, in order to allow bent multi-leg moves to pass back over itself (e.g. for igui). That caused XBoard to hang with an oR on an empty rank... I solved it by making the Betza-driven move generator such that it would treat all slides as finite-range slides with the maximum board dimension minus 1 as range. If you already support finite range slides, this would cause no extra overhead.

SEE is indeed troublesome, if there are pieces with fancy moves. But like you say, it isn't really necessary. Pure MVV/LVA already is pretty good, and Fairy-Max gets by with only sorting the MVV/LVA-wise best move in front, and searching the other captures in arbitrary order. My guess is that >90% of the beneficial effect of SEE comes from detecting if a piece is completely unprotected, so that HxL captures on it are safe. So I often use the simpler algorithm BLIND, which postpones HxL capture of protected pieces compared to MVV/LVA. This still requires you to know whether a piece is protected, though. The null-move reply could have told you, but in QS there is no null move. You could get (somewhat inaccurate) protection information as a side effect from the move generation that was done in the parent; this could have marked all pieces that block friendly captures as protected (e.g. in a bitmap of the board or of the piece list, or even a (packed?) set of counters, to be able to correct single protection for the piece that was moved).

KingSlayer uses MVV/LVA, but it has a provision to initially abort the search of HxL captures that go sour, to reschedule them until after the other captures have been searched. To this end it can pass the value of the victim as 'threshold' to the child. When that child then generates a capture of a piece more valuable than 'threshold' on that same square (which it would after H x protected L), it immediately returns 'abort score' INF+1 (so the caller can see that the capture was bad and needs to be rescheduled). As an extra it would also abort if the 'obvious gain' from capture on a different square would exceed 'threshold'. Where that gain is defined as the value of the victim if unprotected, or the difference between victim and attacker value if protected. This protection information is obtained from the parent (inaccurate as it is, but only used in 'second order'). Normally you would only abort on capture of a King (returning +INF, as no rescheduling is needed), i.e. use threshold = INF-1. This is what is done during the search of the rescheduled captures, to prevent it would abort again.

Duplicat moves are not really a very large problem; the duplicat should give a hash hit that makes it fail low immediately. Bifurcating pieces (e.g. bent sliders like the Griffon) also tend to produce them, if you are not careful to define the overlapping part of one of the branches as a lame leap.

Bent sliders (including the ski-jump case) are pretty nasty anyway. They blur the distinction single vs double check, as beside offering the possibility for triple (or even quadruple) check, they can cause double check to occur along a single path. So that contrary to normal double check, it can be resolved by interposition (but still not by capture of the checker). The ski-slide of the Wyvern thoroughly wrecks KingSlayer's implementation of check detection and handling. Perhaps I should not spent further time on that now, and try to get the other armies working as quickly as possible.

In that case I am nearly there; I have implemented a rather general material evaluation that reproduces the general trend of the EGT results, driven by a 32-bit 'properties' word for each piece type. The even bits in this word are used as flags to indicate whether that piece has the corresponding property (e.g. mating potential, color binding, lacking mating potential even as a pair, being rather weak for a major, etc.). As I won't do any score discounting with more than 2 pieces for each side, the property words can be added for each player, and when both pieces have a certain property, this cause a carry to the (originally unused) next-higher (odd) bit. This makes it easy to recognize conditions like having two majors (almost always a win), having a pair of Knights (draw), having only minors (draw against any defender), etc. Pieces with the 'super-piece' property will use a 2-bit field in the properties word to indicate their ranking, so that we can decide whether an extra minor on their side will make it a win.

It also detects uneven distribution of color-bound pieces over the square shades, to penalize that by a fixed score (which is equivalent to awarding a pair bonus), and declaring a draw when it happens to the only two pieces in absence of Pawns. And when both sides have full color binding on opposite shades it will discount the evaluation by a factor 2 even with many Pawns. This seems to capture the most important effects. I guess I could still have it invoke the existing code for detecting a KBP.K draw in all cases where the only remaining piece is color bound.

Still have to test everything, though.

Wouldn't it be more logical to use 'E' for the War Elephant? It is likely to be depicted as an Elephant, so this would have a better mnemonic value.

Yup, I agree with this.  I have updated the table.

Just let me know what exactly you want the xboard game names to look like.  I was thinking we could extend your idea a little and say that where game-specific parameters need to be encoded in the game identifier, they are formatted like P1(game) or P1~P2(game) or P1~P2~P3(game), etc.  CwDA has two parameters, P1 is white army and P2 is black army.  At some point I would like to come up with a better option for programs that support it so we don't have an exponential explosion of game names, but as a starting point, and for backwards-compatability with programs that don't support it, this seems like a promising approach.

I'm really looking forwards to having multiple interoperable CwDA engines.  I originally started writing ChessV because I wanted to better study CwDA and Zillions wasn't good enough (and there was nothing else.)

@HG

I had sugested, for one of his variants, the name platinum general for the drunk elephant. To me that seems more interesting. But that's a bit off topic!...

Wouldn't it be more logical to use 'E' for the War Elephant? It is likely to be depicted as an Elephant, so this would have a better mnemonic value.

You make a strong case for 'Lion'. (And it indeed is a very nice piece.) I suppose the reason I don't like it is that I am just too involved with Shogi, and that the Lion is such an iconic piece there. But I guess I just should come to terms with the fact that Shogi names often have completely different meaning than those in western chess variants, and that a (Drunk) Elephant is nothing like an Alfil, and a (Dragon) Horse nothing like a Knight.

I like Lancer as well.  So the Fibnif becomes Lancer (L), freeing up N for the Charging Knight.  Now we are only changing the names of pieces Betza didn't get around to yet and we still have pretty good one-letter notations.

I have updated the table below.

"Lancer" does seem a good name, as a Lance seems to be a weapon ill-suited for lateral combat.

A good name for the narrow knight could be searched in the realm of light cavalry, maybe. Lancer or hussar could be interesting options. Donkey is a fun option also for the not this "not that horse" piece, but maybe this is not that appropriate. 

How about this? I changed Bowman to Tower, which is probably a little better. It is unfortunate that I cannot find a historical precident. It seems like this is an obvious piece that would have been used log ago but apparently not. For the Nutty Knights, We have Charging Rook, Charging Knight, and Colonel all beginning with C. The Charging Rook can be R. The Charging Knight could be N, but then what about Narrow Knight? I think Jockey sounds like a reasonable choice for the Charging Knight (a piece that moves partly like a horse and partly like a man) and J is unused. Leaving us with:

I'm also open to something other than Narrow Knight if we can come up with a GOOD name that makes sense. Although, if we did that, that would free up N for Charging Knight, which would have the advantage of not reassigning names to those pieces that Betza already fixed. I suppose that the Fibnif could be Jockey since it also has horse-moves and man-moves, although not as obviously as the Charging Knight.

Today I was looking at the wiki re: the mathemematical concept of Game Complexity, which led to the following sub-link on Game-tree Complexity, that gave me food for thought about CVs that might one day compete in terms of popularity with such well known games as Chess (which arguably is slowly being played out at elite level, in terms of opening theory):

https://en.wikipedia.org/wiki/Game_complexity#Game-tree_complexity

If the mathematically inclined on this CVP website are interested, perhaps there might be a way to evaluate the Game-tree Complexity of various CVs on CVP, and even slowly compile a list of those CVs with very large Game-tree Complexity number estimated for them; thus such CVs, if they ever become popular, might have a longer lifespan than e.g. Chess, and part of popularizing such CVs could be pointing out their great Game-tree Complexity number (as estimated).

Just as an example, here's a link to a 10x10 CV of my own invention:

https://www.chessvariants.com/rules/sac-chess

I'm not mathematically inclined, but I'd guess that the branching factor for Sac Chess (based on the Chess and Sac Chess armies operating at maximum centralized power for each piece in each game's setup) would be 2 to 3 times higher than for Chess on average, and I'd also guess that the average game of Sac Chess (especially for well-played games) would be about 2 to 3 times more than for Chess in terms of number of ply (a piece is traded in Chess about every 10 ply, I've read long ago, so a game of Chess [or possibly Sac Chess?!] would thus be over on average with a total of 32-2x(70/10)=18 units left on the board), and thus Sac Chess' Game-tree Complexity may be ((35 [=avg. # moves in chess] x2.5) to the power of 70 [=avg. # ply in a game of chess] x2.5, if I understand the Game tree Complexity estimate formula right) which may well easily exceed that of e.g. the game of Go - see the chart given further below in the sub-link on Game-tree Complexity that I first gave. Note that in played Sac Chess games I've looked so far, it seems a pair of pieces are traded about every 8 ply (rather than every 10 ply, as in Chess) on average, but this is based only on a small observation.

But I'm not sure what the "correct" notations would be anyway.  I have assigned letters already but you probably won't like them.  I abandoned Betza's terrible, horrible, absolutely no good names at least a decade ago, using alternatives when they already existed. 

I completely agree. I am all in for renaming them, but I do think it is important we do it in the same way. 'Phoenix' is great, but what ID do you use, as the P is already taken? I would use 'X', as that is otherwise in little demand. 'Short Rook' (S) for the R4 would also be an obvious choice. I always liked the name 'Tower' for Rookish pieces (as there is also little pressure on T), but am not sure whether that would best fit the WD or the Charging Rook. 'Lighthouse' would also be a suitable name for an augmented Rook. 'Duck' for the HFD seems as good a name as any. Fairy-Max used 'Unicorn' for the Charging Knight, but this has already a Grant Acedrex meaning. How about 'Jockey' for a Horse/Man-like piece (other than the KN Centaur)? The Bede should probably have the name of some sort of (rather important) cleric. How about 'Ayatollah'? The FAD gives the impression of nervously jumping around, but the name Squirrel is already taken. It can be seen as an augmented Modern Elephant, but that seems a misnomer for a jumping piece in the first place. 'Kangaroo' would be fitting, but has occasionally been used for several other pieces.

I now managed to have KingSlayer play some CwDA games against Fairy-Max, which it eventually could do without illegal-move complaints (and even win some). This is just the basics (move generator and check test); the material table is not implemented yet. The non-standard a-side castling of the Clobberers works, though.

Nice.  That's progress :)

I currently programmed names like "fide~nutters~(cwda)" (all lower case; the space existing WinBoard versions reserve for these names in the New Variant dialog is rather small, and capitals take more space). This we obviously have to sync between ChessV, Quaddrox and KingSlayer, and then I will adapt the names in Fairy-Max' ini file likewise.

That's fine.  I will present the formal names to the user so it doesn't matter much to me what is sent to the engine in the backgrond.  I will synch to whatever you settle on.

The other issue is the piece IDs. I currently use the same as Fairy-Max already used. These are not very satisfactory, though; many were picked to match the piece symbol I picked to represent the piece in WinBoard (e.g. U for Charging Knight because I displayed it as a Unicorn, E for Waffle because I displayed it as an Elephant). They make no sense in a GUI that would use a less fanciful representation.

Yeah, there is that too.  But I'm not sure what the "correct" notations would be anyway.  I have assigned letters already but you probably won't like them.  I abandoned Betza's terrible, horrible, absolutely no good names at least a decade ago, using alternatives when they already existed.  The Waffle?  For real?  People will not take seriously a game with a piece called the Waffle...  And that piece is already know by the far more satisfactory "Phoenix".  Betza had already started fixing the names - the "Furhrurlbakking" becoming the Colonel for example.  Too bad he disappeared before he finished.

I patched it to allow use of the formerly unused type code 7. So that could be its own pieces plus the opponent's super-piece. But then under-promotion to an opponent piece will always be impossible.

This is not ideal, but is probably not all that big a deal.  How often will any engine pick something other than the two super-pieces?  I would think pretty rare, and then 50% of the time it will still pick one of its own lesser pieces.

I now managed to have KingSlayer play some CwDA games against Fairy-Max, which it eventually could do without illegal-move complaints (and even win some). This is just the basics (move generator and check test); the material table is not implemented yet. The non-standard a-side castling of the Clobberers works, though. No bent or ski-sliders yet, so also no Dragons Army.

This already touched on some compatibility issues. Like Fairy-Max KingSlayer now supports two methods for variant selection: in variant 'fairy' the armies are decided based on White Army / Black Army engine options. This is compatible with Fairy-Max, which has a single engine option to select a pair of armies, but the options have to be set by hand anyway, and mean nothing to WinBoard. The other method is through the variant names, but the names are incompatible with those in use by Fairy-Max; I currently programmed names like "fide~nutters~(cwda)" (all lower case; the space existing WinBoard versions reserve for these names in the New Variant dialog is rather small, and capitals take more space). This we obviously have to sync between ChessV, Quaddrox and KingSlayer, and then I will adapt the names in Fairy-Max' ini file likewise.

The other issue is the piece IDs. I currently use the same as Fairy-Max already used. These are not very satisfactory, though; many were picked to match the piece symbol I picked to represent the piece in WinBoard (e.g. U for Charging Knight because I displayed it as a Unicorn, E for Waffle because I displayed it as an Elephant). They make no sense in a GUI that would use a less fanciful representation.

Promotion to an opponent piece will always be somewhat problematic in KingSlayer, as it can only support 7 piece types per army (including Pawn and King), now that I patched it to allow use of the formerly unused type code 7. So that could be its own pieces plus the opponent's super-piece. But then under-promotion to an opponent piece will always be impossible. This is not very important for the purpose I wanted to use it for, but it makes it a somewhat incomplete implementation of the official rules. Things could be stretched a bit further by dynamically assigning the piece type during the game. But that would not remove all limitations, and add a lot of cumbersome code for something that would be almost entirely hypothetical.

I also discovered a problem in WinBoard: it does not relay castling rights in a FEN when the corner piece is not a Rook. This never hurt Fairy-Max, as this relies on the 'edit' command rather than 'setboard', which does not relay any info on castling rights. So Fairy-Max would reconstruct these just based on the corner piece being the one from the initial setup. KingSlayer takes the rights in the FEN seriously, though, and in an engine-engine game the initial setup specified by the first engine would be loaded in the second engine, which then would lose its castling rights. (With external configuration of the initial position both engines would lose these rights, if they rely on 'setboard'.) There is a WinBoard command-line option that can force the castling field to a desired value, though (to force compatibility with the broken Arena Chess960 FEN), so I suppose that would be a work-around. Obviously I have to fix this in WinBoard.

Yes, I rethought it and it's probably a programming error!...

You are taking on a couple of difficult problems ...

Being able to mix-and-match pieces is obviously difficult and the CECP isn't really suitable for this.  External configuration with a text file is probably what is required.  It wouldn't need to be all that sophisticated if your configurablity is limited to adding new piece types.  ChessV does offer a simple scripting language that will let you accomplish this.  What it supports is hit-and-miss but just adding new (basic) piece types is no problem.  Your ski-jump move is not presently supported however.  I need to add that anyway for the Grand Accetrix Griffin, but it won't make this next release.  It has been almost a year and a half since I've put out a new version and I have added so much new stuff since then that I just need to wrap up and get it out.

Knowing when to end a game due to insufficient mating material and when to return a zero evaluation is also obviously tricky.  The currently released ChessV 2.1 doesn't do anything about this at all.  IIRC, you can be down to two kings and it'll happily wander around until the 50-move rule is triggered.  The new version is somewhat better.  It knows about endings with standard chess pieces, and even includes customized evaluation for a few combinations (KRKP, KRKB, and KRKN), plus a "mop-up" evalution for lone king vs. rook or more.  But throw in any non-standard pieces and it goes back to not making any decisions... King + Camel vs. King and you are back to wandering around for 50 moves with it stupidly thinking the side with the Camel is ahead (although it is smart enough to know that if the other side has a pawn then the side without and less than a rook's worth of material should be scaled down massively.)  I would like to program in more smarts here, too, especially in light of all your work to quantify these endings.  I now have a material hashtable so it could be done without worrying about computational cost, but probably won't get to too much of this for this version.  Looking for low-hanging-fruit, like a simple piece property that says "this piece can't mate without help."  It would be really, really awesome to make it smart enough that, when a game starts, even if it is a user-define game through an include file, it does enough endgame table generation to make some basic decisions about this stuff, but that is probably a long way off.

I have written a small c++ program that calculates the crowded board mobility (betza style : https://www.chessvariants.com/d.betza/pieceval/betterway.html).

For a future variant I have studied what I'd prefer for now to call 2-picket bishop and 2-picket rook. Meaning a bishop that moves at least three squares (has 2 long mandatory blind slides before) and a rook that does the same.

It seems that the 2-picket bishop is slightly stronger than a than a 2-picket rook 12x12 and I think I figured out why, but first I'm curious on other opinions. The results averaged over the board having between 10 and 84 pieces (so 75 different cases) are

2pb mobility: 4.52381

2pr mobility: 4.22735

Sure there is still the issue of colour boundness but for compund pieces it is quite an interesting observation, I think!...

Good news.  I think I have ChessV working as a stand-alone CECP engine now.  I've played a few variants with it under Winboard and it seems to be working pretty well.  There's a little more that could be done but all the core functionality is there.

I haven't messed with programming Quadrox for CwDA yet but ChessV is ready when Kingslayer is (although I have not programmed understanding of all the endgames you've categorized yet...)  I've also been putting a lot of work into increasing its strength.  I have been playing 1600 game matches against FairyMax, Capablanca and variants, and it is now testing 106 ELO stronger than FairyMax.  I haven't tested recently, but it is probably still a good 150 ELO weaker than Joker80.

I know in Tamerlane chess the picket piece is a bishop that cannot move just one step but must cross the first step. What is the rook's counterpart for this piece? What about longer "blind" steps? I remember Ralph Betza naming a piece anti-rook. But I think it was different, although I don't recall the details!...

Except for the promotions to Buddhist Spirit / Teaching King because of 'contageon' in Maka Dai Dai Shogi

XBoard supports Maka Dai Dai with its 19x19 board and 50 piece types?  Holy crap!

Fairy-Max not supporting under-promotion, and only allowing promotion to the army's own superpiece, this problem so far did not occur in CwDA. I still have the feeling that this promotion to opponent piece types is an ugly solution to a non-existent problem, as the armies that supposedly would be disadvantaged by promotion to own pieces are already overly strong without that.

Yeah, I'm not sure this rule really needed to be this way.  The Nutters are the ones most likely to promote to another piece since their pieces can't move backwards quickly and so a promoted piece is stuck, greatly reducing the value of promotion.  But that army also seems to be over-powered and it is not obvious how to weaken it.  Preventing promotion to a piece from the other army might be a good way to go, but that would be a change to the game and not just a change to the army.

Any guess when you think you'll have your new cwda engine ready for testing?

Well, the U.S. is full of awesome places in itself. These national parks and forests are amazing. But indeed, trans-Atlantic travel is a pain.

And yes, the promotion suffix in this case would always need to be properly punctuated. This is one of the things I still have to fix in XBoard; as so far only the large Shogi variants taxed the alphabet so much that the punctuation had to be invoked, and promotion there is indicated by a '+'', I could so far ignore that problem. Except for the promotions to Buddhist Spirit / Teaching King because of 'contageon' in Maka Dai Dai Shogi. But I worked around that by using XBoards feature that allows defining a second 'nickname' ID for any piece (originally added to handle the frequently encountered non-compliant FENs for Xiangqi  that use N for H and B for E) to assign letters that otherwise were in very low demand as nickname to BS and TK, and have XBoard use the ninckname as promotion suffix when the real ID has punctuation.

Fairy-Max not supporting under-promotion, and only allowing promotion to the army's own superpiece, this problem so far did not occur in CwDA. I still have the feeling that this promotion to opponent piece types is an ugly solution to a non-existent problem, as the armies that supposedly would be disadvantaged by promotion to own pieces are already overly strong without that.

Congratulations on the new kitchen, and the Cyprus vacation.  That's certainly one thing I envy about Europeans - being able to pop off to so many awesome places without having to cross the Atlantic (which is a major PITA.)

Regarding SAN, for promotion, wouldn't you need to rely on presence or absense of the quote to determine which piece was being promoted to?  Note that I have no strong feelings about SAN.  ChessV doesn't do anything with it at present.

I was thinking.  If you're making a strong engine for cwda, I think I will join in and add cwda support to Quadrox.

Great! My kitchen is finally installed, nearly a week behind schedule due to several setbacks. (It was supposed to be finished while I was on holiday in Cyprus.) But my home is still a shambles, so it might take another week before things are back to normal here.

About the use of 'dressed letter' IDs in SAN (not really a protocol matter!): perhaps it is best to treat the punctuation just as an alternative form of disambiguation in the SAN parser. So that 'B' in the SAN move would match B, B', B", B!, ... A 'tie breaker' rule could solve cases where both a bare B and a punctuated B would match the input move, in favor of the bare B.

This would allow the user (or GUI designer) to generate the kind of SAN he likes best: either always writing puctuation, or never writing it, and rely on the usual coordinate disambiguation to indicate which piece was moved.

Ok, I've completed the change and everything seems to work.  The two sides can now have different notations for the same piece, so long as player 1's is upper-case and player 2's is lower-case.  When defining piece types when we aren't using this feature, the type notation is specified as it is for white and will automatically be changed to lower-case for black as it has always been so no existing code should break.  To specify notations when the players use different ones, just put a slash in between.  For example: "B'/b"

Here is a summary of what notations are now supported.  A notation can be a single letter.  It can be a single letter followed by ' or !.  It can also be two letters.  If the first letter of a two-letter notation conflicts with a single-letter notation, it must be prefixed by an underscore.  Use of an underscore is permitted even if there is no conflict.  The underscore is never displayed to the user.

Possible variant on that: use Q' etc. to indicate the pieces of black's starting army, and the plain letters for white's. That way, each symbol still means the same thing no matter which side it's on.

Thanks for the suggestions, but I don't think this is an improvement.  With H.G.'s approach, the apostrophe is only necessary in the rare case where a pawn promotes to a piece from the other player's army.  Also, his suggestion is backwards-compatible with Chess.  In CwDA, if both players are playing the FIDEs, everything should be identical to chess.  With this proposal, black's pieces would all have apostrophes.  Sure, you could further stipulate that the apostrophe is only used for pieces not found in the other army, but that requires additional logic for no obvious benefit.

Or use English symbols QRBN for one color and German symbols DTLS for the other

I don't think this solves any problem.  You could still have conflicts with other armies.  Besides, what's German for Bede?

Possible variant on that: use Q' etc. to indicate the pieces of black's starting army, and the plain letters for white's. That way, each symbol still means the same thing no matter which side it's on.

Or use English symbols QRBN for one color and German symbols DTLS for the other...

This is indeed the way XBoard does it; for protocol moves it forces the promotion suffix to lower case, for SAN to upper case. (Also in drop moves, btw.) In these contexts case sensitivity would not provide essential info, as it is known who is on move. I don't know any variant where one can promote to pieces of the opponent's color.

For FEN XBoard strictly adheres to the convention that upper case is white and lower case is black, even when asymmetry of the armies would not make this strictly necessary because the type already implies the color.

I don't see how this interferes with white and black using different ID for the same piece type, though. If they would take the ID from the same table they would certainly have to do a case conversion for one of the colors, or either in SAN or CECP moves. That they now take it from a twice larger table without first masking away the color info doesn't change that.

That is indeed a clever workaround, but it is a fairly ugly hack.  So I've started the painful process of having different piece -> notation mappings for each player.  Hopefully it won't be too bad.

I have hit my first road block however.  It seems that communication of promotion moves in CECP always uses the lower-case.  The example given in the standard documentation is "e7e8q".  Clearly, this is white's move, but the q is lower-case.  This far, I have always been sending in lower case.  How do we address this?  If I go forward with this change blindly, it will send promotion q for black but Q for white - which totally makes sense, but I'm afraid it will break engines that aren't expecting it.  An alternative, which seems ok (but please check my logic here) is to send the notation for the player which is moving, but forced to lower-case.  This shouldn't break anything, and it seems it will still work with what you are proposing.

Well, a work-around could be to define the FIDE and Clobberer Bede as different piece types, which just happen to have the same move. (And similar for Bishop.) As IDs would only occasionally clash, this means most of the time you would need 12 piece types for CwDA, instead of  10, which is probably well within the capability of ChessV. In Fairy-Max I often have to do that too, not because of the ID, but because it doesn't automatically flip the moves of black pieces. So pieces like Pawns always have to be defined as a white and a black variety. (And this posed the problem of allowing 'different' white and black pieces with the same ID.)

Oh, I certainly agree with those advantages.  I'm just concerned that this will require changes in tons of places.  Let me look and try to get a feel for just how much changing will be required...

I liked the idea because it creates complete freedom in the choice of id for any army, without having to worry about 'collisions' with other armies. Otherwise you would always get into trouble once the number of different armies gets large enough. It also looks a bit cumbersome to use unnecessary complex ids in a game between two given armies just because there exist other armies with which the ids would collide, while no actual collison occurs between any of the actually allowed pieces.

On vacation with only a phone so I can't type a long response.  I'm sorry, but I am not in favor of this idea.  ChessV expects pieces to have the same notation for both players (except for case.)  It would require a lot of changes to change that.  I don't mind changing things if there is a good reason but I don't like to complicate the system just to benefit one game.  I am doubtful this has any real advantage outside CwDA.  I think two letter notations would be best, but I understand that could be a radical change (needing to code in understanding of the prefix.)  I can live with heavy use of the suffixes.

This night it occurred to me that for CwDA we could adopt the convention that L' means a piece that is normally in the opponent army. Then B can be Bishop for FIDE and Bede for Clobberers, and in the extremely unlikely case FIDE would want to promote to a Bede, this would become B'.

Actually, you can't count on that.  A pawn may promote to any piece from either army.

O sh*t, I hadn't thought of that. Probably because it cannot happen in Fairy-Max.  I still wouldn't be unhappy with the dressed-letter approach, though. Charging R and N could be R' and N', Bede could be B'. To me that doesn't look any worse than CN, RN and Bd. For the classical armies this would give: NBRQ, WFB'A, F'N'R'C, W'HSM. In almost any situation the punctuation would be irrelevant, as you would virtually never promote to Waffle, Fibnif, Woody Rook etc. So if we choose to use conventional disambiguation in SAN rather than punctuation, it would never virtually never need to disambiguate anything. And if the FEN is considered just an arbitrary string for computer consumption, it becomes irrelevant how it is done there anyway.

I use an underscore as a prefix to force recognition of two-letter notations.

I did something similar for the internal representation of start positions in my engine HaChu, using colon instead of underscore, but I wasn't very happy with the result. If auxilary symbols are used, you might as well just require all pieces to be separated by commas. (This is the notation that is also used in the TSA rule books for the various Shogi variants.) Forsyth notation was originally conceived for human reading, in newspapers. For computers it would be much more convenient to have some fixed-length format. You either don't care much about the length, (like in GUI-engine communication), or you care so much (in database applications) that FEN is hopelessly inefficient size-wise.

My problem has always been that XBoard would have to be changed in uncountable places to support even just 2-letter IDs. Which makes me inclined to consider options that objectively might not be the best. With the dressed letters the Id currently still fits in a byte, and only on reading or writing a mapping has to take place of the ASCII range 64-128 on the three other available 64-bit ranges. If I would manage to change all variables ever used to hold piece IDs to ints, I could use a similar strategy in storing mult-letter IDs e.g. as firstLetter + 256*secondLetter + ...

Note that there is not really any need for pieces of opposing armies to have different ID

Actually, you can't count on that.  A pawn may promote to any piece from either army.

XBoard I finally adopted the solution of  dressed letters

Yup.  I've already added support for this.  You made a good case why this was logical for shogi variants with lots of pieces.

The problem with multi-letter ID is that they do not work in FEN when mixed with single letter. (And even if not mixed, it leads to FENs that are unreadable for humans).

I use an underscore as a prefix to force recognition of two-letter notations.  It is not required if the first letter of the two-letter code does not represent a valid piece on its own, although you can use it anyway.  The underscore is never displayed to the user.

As for human readability, I don't really understand this concern.  They're not readable already.  Can you look at a chess FEN and visualize the board (like which pieces are on the same ranks or diagonals?)  I certainly can't.  To me FEN is just a dense encoding for computer interpretation.  In ChessV, you can just paste an FEN into a dialog and it will load it.

The problem with multi-letter ID is that they do not work in FEN when mixed with single letter. (And even if not mixed, it leads to FENs that are unreadable for humans). As an alterative to FEN there could be DEMN, which uses piece IDs whith a first-letter upper case and the optional following letters in lower case, and then lists the white and black pieces in separate sections concatenated by #. (Advantage is that that this also works for multi-player variants.) I was still not happy with the human redability, though.

In XBoard I finally adopted the solution of ' dressed letters', where each piece ID is a single letter (captital / lower case used to distinguish color in FEN), optionally followed by a punctuation sign, like quotes or an exclamation point. So L, L' , L`, L" and L! all indicate different pieces. This gives FENs that are quite readable. It can also be use in SAN, but there alternatively only the letter could be used, conventional coordinate disambiguation sloving the problem that G can both be Gold an Great General. (The WinBoard Alien Addition currently uses this method in Tenjiku Shogi.)

Note that there is not really any need for pieces of opposing armies to have different ID; it should always be clear whose turn it is (in SAN), or which color (in FEN). So both Bishop and Bede can be B without causing any problems, as they will never occur in the same army.

I think this is a reasonable proposal.  For games with required parameters, I can provide some information about how the game variables are mapped into the xboard variant name.

It seems we will need two-letter piece names though.  One thing I do not want is for the notation of a piece to change depending on what the opposing army is.

I hope your kitchen renovation has gone well!

After having slept on it I realize there is a problem. General configurable variant engines will usually be configurable to play CwDA, but they will have been designed without the peculiarity of army selection in mind, and thus have no special features for it. The only way for such engines to play CwDA is by adding each flavor as a separate variant. If a GUI would not support this method, it would thus become incompatable with most engines that can play CwDA, as there will be very few dedicated CwDA engines. The partial naming I proposed in my previous posting requires engine support that they would not provide.

So it seems impossible to prevent variant proliferation in the engine's variant feature of WB protocol. But that shouldn't stop a GUI from keeping this proliferation out of its variant-selection dialog. So I want to propose a naming convention that would give special treatment to variant names of the form A~B(C) (e.g. FIDE~Nutters(CwDA) ). These should be considered as belonging to the "variant group" C, which should be enabled on par with primary variants. The GUI would collect lists of all A and all B occurring with that C in the engine's variants feature, and offer a separate selection method (e.g. a combobox) to select an A and a B.

This would give rise to rather long variant names, which would be clipped in the display of some existing GUIs; this is why I put the least-informative part at the end, rather than having something like CwDA:FIDE~Nutters. In addition, GUIs that do not support this convention would display a very long variant list, which they might also truncate. (This problem exists already with WinBoard + Sjaak II without the help of CwDA, and the latter provides a work-around for it through an engine-defined option defining the meaning of wild-card variant 'fairy'. In engine-engine tourneys selection through a WinBoard command-line parameter is always possible, though.) But newer GUIs would reduce the entire group to just a single item in their primary selection menu no matter how many flavors the engine reports, and provide additional methods for sub-selection of a flavor. (E.g. comboboxes behind the radio button that selects the item, or a separate dialog that pops up after the item gets selected through the primary dialog.) Engines don't have to know anything about this 'streamlining' of the variant selection.

P.S. due to construction of a new kitchen in my home I probably won't have much opportunity to think about these things or post here in the upcoming week.

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.

Regarding army selection, and other setup options:

I got the impression that you would like to have a separate dialog for setting the variant-specific options of the engines, which perhaps pops up automatically after you selected the corresponding variant. This would be feasible for CwDA, but in view of the above I wonder if it would be sufficient in general.

Yes, this is what I do.  It populates the dialog with any game variables that are not yet specified.  There are reasons why they may already have values.  The game may provide values, in which case they are there just as a configuration options, but the user isn't normally prompted.  Or the user may have selected a game that is derived from the game which fills in the options. (You could make a new variant derived from CwDA where the armies are always both Nutty Knights plus whatever other changes.)  Or the options may already be specified because the user has opened a saved-game file, which of course must contain this information along with the game.

You raise a number of other things though which could certainly be considered related.  For games where players take turns making choices or placing pieces, I view this as part of the actual game.  Ideally, the GUI prompts you when it is your turn to make a decision.  And the computer's clock should certainlly be running while it is considering its own choices.  That said, I have not implemented anything like this yet.  I haven't implemented any of the games you mention...  And for some choices, it may not be obvious how they would be communicated in the protocol.  For placing pieces, though, the existing @-notation for dropping pieces seems like an obvious choice.  This does, of course, require a lot of new code...  I agree it could be considered an "ugly" problem from a code-writing perspective.

In the latest XBoard I tried to expand the possibilities by allowing the engine to request opening of its entire settings dialog (as defined at that time) 'spontaneously'. So it could redefine its option list to define a dialog for the purpose, starting with feature done=0 (to temporarily remove its normal options), and end with done=2 (the forced popup request). This could have two comboboxes in it for the available armies, or (for Musketeer chess) comboboxes for selecting piece types and the files at which they would gate, etc.

Having this come from the engine just does not make sense to me.  There are potentially two engines but only one GUI, so it seems to me the GUI should be "driving the bus" here.  Which engine makes the request?  What if the other engine doesn't support the same armies (or other options)?  You could just pick one engine and stipulate that to run a match between engines they must support the same things (or that the use will only pick options supported by both.)  But then the GUI needs to tell the second engine, so the options would need to be named the same... It seems this approach still has game variables, and the GUI still must have an understanding of this concept to facilitate the hand off.  I think it is more straight-forward for the GUI to know which game variables and associated options the engines support, (the engines announce this anyway), and present the user a choice of the options both support.

I'll hold off on addressing the other topic for the moment.  I don't have enough time at the moment to think through it all and draft an intelligent response.

As to the selection of armies:

We definitely agree that it is useful to have options that are common for both engines. Putting some common prefix, and perhaps an agreed-upon special sysmbol in front of a set of option names is always possible, and doesn't interfere with any interface that would not treat it as special.

The main thing I worry about is that army selection in CwDA, and even more clearly selection of the 'guest pieces' and where they have to go (as replacement or through gating) in Superchess and Musketeer Chess, setup of the super-pieces in Metamachy, are all really parts of game play. According to the official rules of those games there is a prescription for how the players negociate an initial position. In the XBoard implementation of Superchess I dodged that problem by implementing it as a shuffle game; my justification for that was that this 'game prelude' is really a work-around for human-human games, where there is no third party that could make the decision for them in an unbiased way. When a computer is involved, it might as well make the decision for them. If they don't like the proposed setup for a human-comp game they can just keep pressing 'New Game' until they do. If comp-comp games need a specific start position you just play them as games from a setup position, and provide the desired FEN to the GUI that runs those games. Jocly, OTOH, takes these game preludes seriously, which makes the implementation of the mentioned variants enormously more complex, involving a lot of non-standard code. (Where other variants are implemented by simply giving a list of piece properties and their start location.)

For CwDA the issue is a bit more subtle, as there are potentially so many armies (even the Wikipedia lists many armies I had never heard of) that it is impossible to give the pieces a unique 1-letter ID. So which army the engine has to play with cannot be unambiguously specified through the FEN in a setboard command, even if the GUI would make the army selection at random.

Historically WB protocol contained a feature that would allow user-engine dialogs as needed in a prelude: the askuser command. This is equivalent to a single string option: in response XBoard will pop up a dialog where the user has to enter a text, which will then be sent to the engine on 'OK'. In the latest XBoard I tried to expand the possibilities by allowing the engine to request opening of its entire settings dialog (as defined at that time) 'spontaneously'. So it could redefine its option list to define a dialog for the purpose, starting with feature done=0 (to temporarily remove its normal options), and end with done=2 (the forced popup request). This could have two comboboxes in it for the available armies, or (for Musketeer chess) comboboxes for selecting piece types and the files at which they would gate, etc. Problem is that such things would not work in automated engine-engine games unless the GUI itself would be able to set the presented options. But in WB protocol the engine can know if the opponent is a computer, and then refrain from requesting the popup, and use the default values, or the values previously given for those options.

Things are really ugly if the rules for the prelude require the players to take turns on selecting things; in a human-comp game you would then have to go through a sequence of dialogs where the engine each time says "I did this, now what is your next step?", before we can actually start moving pieces. And what if it makes sense for the engine to really think hard about its decision? Should its clock be running?

I got the impression that you would like to have a separate dialog for setting the variant-specific options of the engines, which perhaps pops up automatically after you selected the corresponding variant. This would be feasible for CwDA, but in view of the above I wonder if it would be sufficient in general.