Grande Acedrex

[hgm]

Mexican Chess I can add easily enough to SjaakII (which reminds me: do you have a working definition for Sac Chess that I can include?). Ciccolini's unfortunately not (the Dabbabarider is problematic).

I wouldn't bother about Sac Chess. It doesn't seem good enough to spread it. I just wanted it on behalf of the inventor, who describes himself as technically challenged. And it was a very useful exercise for debugging both Sjaak and WinBoard considering unusual castling.

Mexican Chess is also not so special, but I wanted a 10x10 variant without frills to test the new capabilities of Fairy-Max (to test the counting-from-0 code). So I went to the chess10x10.com website, and found this. It had Camels as extra pieces, which would put the new Camel piece I added to XBoard to good use. (Are there even camels in Mexico???) That made it more attractive than Roman Chess, which had Commoners, or any of the 10x10 variants that just use extra FIDE pieces. Ciccolini's Chess likewise had Zebras, one of the other new pieces (although it calls them Elephants). The obvious 10x10 choice, Grand Chess, is problematic for Fairy-Max because of the non-standard initial position (Fairy-Max assumes back-rank pieces and 2nd-rank Pawns), and promotion rules.

[Evert]

Mexican Chess I can add easily enough to SjaakII (which reminds me: do you have a working definition for Sac Chess that I can include?). Ciccolini's unfortunately not (the Dabbabarider is problematic).

I wouldn't bother about Sac Chess. It doesn't seem good enough to spread it. I just wanted it on behalf of the inventor, who describes himself as technically challenged. And it was a very useful exercise for debugging both Sjaak and WinBoard considering unusual castling.

Ok, fair enough.

Mexican Chess is also not so special, but I wanted a 10x10 variant without frills to test the new capabilities of Fairy-Max (to test the counting-from-0 code). So I went to the chess10x10.com website, and found this. It had Camels as extra pieces, which would put the new Camel piece I added to XBoard to good use. (Are there even camels in Mexico???) That made it more attractive than Roman Chess, which had Commoners, or any of the 10x10 variants that just use extra FIDE pieces. Ciccolini's Chess likewise had Zebras, one of the other new pieces (although it calls them Elephants). The obvious 10x10 choice, Grand Chess, is problematic for Fairy-Max because of the non-standard initial position (Fairy-Max assumes back-rank pieces and 2nd-rank Pawns), and promotion rules.

I could have sworn that I had something called Turkish Great Chess as a variant, but apparently not. Not that it's particularly interesting: it adds two (rather than one) Chancellors, an Archbishop and an Amazon. It has a mangled pawn setup though.

[hgm]

More interesting would be "Enlarged and Improved Chess", because it has two divergent piece types: one that moves as Rook and captures as Bishop, the other that moves as Bishop and captures as Rook. But because it has two of each, it has that same mangled Pawn line, and that prevents Fairy-Max from implementing it.

At least Fairy-Max now takes the promotion upgrade from a per-square table. So now it is only a matter of filling that. Not sure how I should make that configurable, though (and wether it would be worth doing so). Currently it just fills it with piece nr 7 for white, and 7 for black (or 9 if black has no nr 7). Perhaps I should just hard-code it, recognizing the name 'acedrex' to activate the code.

Tamerlane Chess, where the promotion choice moves with the Pawn rather than being determined by the file, would be a real pain. To weird for Fairy-Max, I guess. (Also the pieces.)

[Evert]

More interesting would be "Enlarged and Improved Chess", because it has two divergent piece types: one that moves as Rook and captures as Bishop, the other that moves as Bishop and captures as Rook. But because it has two of each, it has that same mangled Pawn line, and that prevents Fairy-Max from implementing it.

Presumably it could play it from a setup position though? In which case it could implement it with a simplified starting position.
SjaakII could play it easily (but I have no idea what the value for such divergent pieces should be).

At least Fairy-Max now takes the promotion upgrade from a per-square table. So now it is only a matter of filling that. Not sure how I should make that configurable, though (and wether it would be worth doing so). Currently it just fills it with piece nr 7 for white, and 7 for black (or 9 if black has no nr 7). Perhaps I should just hard-code it, recognizing the name 'acedrex' to activate the code.

Tamerlane Chess, where the promotion choice moves with the Pawn rather than being determined by the file, would be a real pain. To weird for Fairy-Max, I guess. (Also the pieces.)

I haven't really tried to implement that yet, other than defining most of the pieces and reserving space for three royal pieces in the piece list.

The promotions are an issue though. Each pawn has to be its own piece type, which means there are 20 different piece types in the initial array alone (add another 3-4 due to promotions). I actually don't have enough space reserved in the piece list for all legal Tamerlane pieces, but I could always stick promoted leapers into the "general" tail of the table - or make the index ranges dependent on the variant.

The rules for the "pawn of pawns" are really insane though: if it reaches the last rank, it becomes iron and gains the power to teleport to any square where it attacks a trapped piece, or forks two enemy pieces (and it then captures whatever was on the square it lands on). It then moves as a normal pawn again, until it promotes again, after which it teleports back to the third rank. Finally it can then promote to your third royal piece, which can defend the citadel from occupation by the enemy king.

I don't know much about Tamerlane, but he obviously liked overly complex and convoluted games.

[hgm]

Presumably it could play it from a setup position though? In which case it could implement it with a simplified starting position.
SjaakII could play it easily (but I have no idea what the value for such divergent pieces should be).

That was the approach I originally used for Makruk: XBoard would always consider it a setup variant (like it has to do for the shuffle variants anyway), so that the setboard could send the deviating Pawn setup to Fairy-Max. I dropped that when I hard-coded an exception for Makruk in Fairy-Max. But Makruk was a standard variant, so XBoard could do it by itself, and there was no annoyance to the user. But indeed a variant could be defined with a wrong setup, just for defining the pieces, so that the user could define the actual setup. In fact this is sort of what I still do in Courier, where it would be better to start in the position after the mandatory Pawn moves, but which is defined with all Pawns on 2nd rank.

I did measure mNcQ (~7) and mQcN (~5), which confirmed what I also saw on short-range leapers: captures are twice as important as non-captures. So when B=3.5 and R=5 then mRcB=4 and mBcR=4.5 would be pretty good guesses.

[Evert]

But indeed a variant could be defined with a wrong setup, just for defining the pieces, so that the user could define the actual setup. In fact this is sort of what I still do in Courier, where it would be better to start in the position after the mandatory Pawn moves, but which is defined with all Pawns on 2nd rank.

Yes - in fact, that is what Sjaak II considers the starting position, so they always have to play eachother from a setup position. Not sure what the point is of having a prescribed set of opening moves; it's a bit like this chess variant I invented which is just like normal chess except white has to begin with 1. f4 and continue with 2. g4.

I did measure mNcQ (~7) and mQcN (~5), which confirmed what I also saw on short-range leapers: captures are twice as important as non-captures. So when B=3.5 and R=5 then mRcB=4 and mBcR=4.5 would be pretty good guesses.

Squeezed it into 1.2 with those values just for the fun of it.

[hgm]

I think I completely managed 'variant grande-acedrex' in Fairy-Max now. I put in an alternative assignment of default promotion choice, taking the pieces that started on the promotion square, and the piece on the a-side of King for the King. I also made the pawn Rank configurable. (But still a closed rank.) Promotion bonus is now calculated with the true value of the default promotion piece and Pawn, even inside the tree, rather than a hard-coded Queen value, which should benefirt all variants with unusual promotion piece. (Ferzes were already scaled down by a factor 8 in the old code, but now thi sis only used for 6th and 7th-rank bonuses.) There also is a test that rejects under-promotions (i.e. any choice other than the default piece) as illegal.

So far this has to be activated in a bit of a kludgy way: moving up the Pawn rank happens by specifying a negative depth for the promotion zonein the ini file (which then leaves a 1-rank zone), and chosing 4th rank for the Pawns activates the file-dependent promotion and rejection of under-promotion. I guess I will only change that if another variant with 4th-rank Pawns emerges (which seems unlikely).

[Evert]

I have something that plays as well. It's lacking a transposition table though (I don't want to re-use the code I have because I want to try something different with it), and the search is plain PVS without bells and whistles.

It's also decidedly lacking in evaluation (just piece+centralisation, and it pushes everything forward in the end game).

It also needs a better name than the working title "GA". I haven't been able to come up with anything particularly witty though...

[hgm]

Hmm, I see what the problem is in XBoard now. It is not so much that it thinks a King without Betza 'O' move still can do the hard-coded castling, but that the ApplyMove routine interprets any sideway King step of more than one square as castling with the corner piece. One could even blame the protocol specs for that, as e1g1 is explicitly mentioned as the notation for castling. So iD or iH moves (or just D and H) on a King would always be mis-interpreted. It should only interpret sD steps as castling for Kings that have no D in their move definition, etc.

[Evert]

Hmm, I see what the problem is in XBoard now. It is not so much that it thinks a King without Betza 'O' move still can do the hard-coded castling, but that the ApplyMove routine interprets any sideway King step of more than one square as castling with the corner piece. One could even blame the protocol specs for that, as e1g1 is explicitly mentioned as the notation for castling. So iD or iH moves (or just D and H) on a King would always be mis-interpreted. It should only interpret sD steps as castling for Kings that have no D in their move definition, etc.

Maybe, but I don't think anyone interprets the protocol spec to say that "e1g1" refers to castling in variants that don't have castling.
Reading the protocol that literally can be interpreted to mean "e1g1" is the notation for castling even in variants where the king does not start on e1 (the protocol doesn't specify how it's sent in that case, although the implication is of course clear).

Still, I don't think anything is going to break if it's changed so it doesn't mis-interpret double king-moves in variants where it can't castle. The question is whether you want to change that in time for 4.9 (which always runs the risk of breaking something accidentally).

Actually, I have a question on how to implement the rules here, in comparison and in contrast with castling:
1. Since the move is a jump, it doesn't matter whether the intermediate square is attacked or not, right?
2. Is it allowed to do the initial jump to evade check? May not come up so much due to the size of the board.
3. Are you allowed to capture an enemy piece with the king's initial jump?

I think there is no real argument to interpret 1 any differently, but I included it for completeness sake (and it's an important implementation detail).
For point 2 it's not so clear. The rules don't say, the analogy with castling suggests not. In Ouk and Chaturanga the king has an iN move, but not when in check (Ouk) or after having been checked (Chaturanga, according to chessvariants.org, but this may be a mis-interpretation). I think that suggests that it should not be allowed (I currently do allow it).
Point 3 is again not so clear. For castling it's not possible because the path between the king and rook needs to be free, but I can't find any source to say that it wouldn't be allowed in Ouk or Chaturanga. Either way, I don't think it matters much. I currently allow it.