Ratings & Comments

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.