Grande Acedrex

[Evert]

This one looks a bit better (but would run into the Chu lion issues):



Not that it actually plays the game yet.

[hgm]

Actually, I'm not entirely sure now it really does what it must do: the Giraffe is basically a lame-leaper for its initial move, moving once as F, then as nH and then finally sliding onward as a rook. Does that work?

Well, for describing the Tamerlane Picket, f.e., you could use yafF which steps one and then slides further in the same direction. But you could also have said mafB, which slides as Bishop to an empty square and then again as Bishop. Any N+M slide with N>1 could also have been made as an (N-1)+(M+1) slide, and is thus redundant (duplicating an already existing move). So 1+M already provides everything N+M could provide, when they go in the same direction. So it doesn't hurt to use a slider move for the step to the blocking square. It is just that each distant destination would be generated multiple times.

[hgm]

The Knight-derived symbols look annoyingly similar. Perhaps I should flip some of them horizontally. (E.g. the Unicorn.)

[Evert]

Nice!

By the way, I assume this should have parent variant 12x12+0_shatranj to inherit the baring rules?

[hgm]

If you would want it to inherit those rules, then that would indeed be the only way to do it.

I am not so sure it had this rule, however. Unlike in Shatranj, where only Rook has mating potential, and even Knight + Ferz or 2 Knights don't have it, a lot of pieces here have mating potential, and Pawns do not promote to a worthless Ferz. If stalemate is a win, even more pieces might have mating potential. (But I guess that the only way to make it inherit the stalemate-is-a-win rule is also to make the parent Sjatranj. Xiangqi or Shogi do not seem suitable.)

[Evert]

If you would want it to inherit those rules, then that would indeed be the only way to do it.

I am not so sure it had this rule, however. Unlike in Shatranj, where only Rook has mating potential, and even Knight + Ferz or 2 Knights don't have it, a lot of pieces here have mating potential, and Pawns do not promote to a worthless Ferz. If stalemate is a win, even more pieces might have mating potential. (But I guess that the only way to make it inherit the stalemate-is-a-win rule is also to make the parent Sjatranj. Xiangqi or Shogi do not seem suitable.)

Well, pages suggest that this is the likely rule, but of course they also list likely incorrect moves for the pieces.

There's a snag though: by using shatranj as the parent variant, you lose the ability to specify virgin state for the king...

[Evert]

That reminds me: I encountered another snag.

Virgin state of the king can be set and remembered through the castling field in the FEN, but this seems to trigger normal castling rules as well.
The king move is specified as "piece K& KiDiA", but at least the version of XBoard I have still interprets a sideward jump (sD) as a normal castling move...

[hgm]

Indeed, this is still a problem. As XBoard did not have a general mechanism for keeping track of virginity of all pieces, the hack I used to implement initial moves in the Betza generator was just to check if the piece (or rather, one of the same type) was on the same square as in the initial position. Although this worked for Pawns, which cannot return to their starting square, is was not perfect (although bearable) for castling. So I used the kludge that castling, when not defined on a King's Betza moves through an O atom, would be handled by the original code of the parent variant. So that you would only have to suffer the imperfection of imagined castlings (left to the engine to refuse) when non-standard methods of castling would force you to define it in the Betza string. If you did not want any castling at all you could simply give no rights in the setup FEN.

This worked pretty well, except, as we now experience, for 'castlings' that are not really castlings, but other virgin King moves, not indicated by an O.

The obvious patch it to disable the hard-coded castling code not on occurrence of an 'O' in the Betza string, but of an 'i'. Any virgin move on a King would then be considered a castling alternative. And for 'i' moves on a King I could beef up the test in the Betza generator to probe the virginity of that King, which is kept by XBoard as part of the castling rights. (Next to the virginity of the partner assumed by the XBoard native castling code, which I could test if the 'i' prefix is on an O atom, if that atom did not specify another partner (through 'j' prefixes) as XBoard assumed. Best would of course be if XBoard payed attention to the Betza O definition of the royal piece when it decides during setup which pieces to monitor for virginity.)

[Evert]

I was able to squeeze in some more time to tinker with this.

It still doesn't play, but it does perft:

Code: Select all

perft 4
 1         59  0.00    830985.92nps
 2       3481  0.00   1064851.64nps
 3     206209  0.09   2323769.71nps
 4   12200523  4.91   2487284.41nps

The move generator here is about half as fast as SjaakII on Omega Chess (which is nominally 12x12 as well). If I remove the in-check test at leaf nodes it is about 20x faster, but of course the result is wrong in that case.

The in-check test itself is rather dumb: it just loops over enemy pieces and tries to capture the king with one. Are there any tricks I may be missing for efficient check detection on mailbox boards? Should I keep track of pinned pieces (which will be a joy with the oblique sliders in this variant)? Or is this just what it is?

EDIT: fixed numbers above, I forgot to clear the "virgin" bit after moving a piece, so the king could always do the AD jump. Oops.

[hgm]

The bent sliders are indeed a pain, as well as the large number of oblique leaps. I don't think scanning away from the King could be competitive. (For Chess it surprisingly is not that bad, as the King is tucked away safely for most of the game, so that most rays away from it very quickly meet an obstruction.)

So yes, testing the pieces to see if they check seems the best method here. I don't know how you check that, but a 0x88-type test seems possible, where you very quickly see if a piece is on a square where it would deliver check on an extra board, and tabulate the direction you would have to scan from the King (if the piece was a slider) to scan the ray for blockers. Complication here is that for Griffon and Rhino checks you would not automatically bump into the checker during that ray scan. So you would have to tabulate in addition on what square a bent check would turn the corner.

The above is for a 'from scratch' check test, though. If you merely want to know if the latest move delivered check, you would only have to test the moved piece in the way described above, and test for traditional alignment of the from-square and the King. If the ray scan from King then reaches the from-square, you would have to continue that scan not only testing for Rooks or Bishops on that ray, but also for Griffons or Rhinos on the squares on both sides next to it. (This could probably be done better using piece-list info, but as it is rare that the King connects with the from-square, that does not matter anymore.)

If you want to test if the latest move put yourself in check you would have to do the above test on the from-square for non-King moves, but the 'from-scratch' test when you moved the King.

If you already were in check, and want to know if the move resolved it, you test King moves in the usual way, but other moves should be tested forlanding on the check ray, closer to the King as the checker. So presumably the in-check test would have given you the check ray (e.g. by step vector) and distance of the checker (or the corner where it moved on the ray), and you would test the king-toSqr distance and direction against that. Complication here is that capture of the checker could now be off-ray, so for Griffon and Rhino checks you would also have to test explicitly if the to-square coincides with the checker location, as it is no longer implied by the distance.

As for Fairy-Max:
It turns out that about half the variables are (signed char), which is quite fatal for storing square numbers above 127. So I guess that to make progress towards support of larger boards I will need to convert all those to another data type...