Winboard Forum

How could I handle FRC castle in a 0x88 engine? Wich data structures could help me? I want my engine being a native FRC player, but i dont figure how to handle castles in an efficient and clean way...

Move generation: I recommend doing it the same way you do it in normal chess, i.e. figure out which squares need to be empty/unattacked before the game. Of course, the initialization code is a bit more complicated...
Special case: you need to check for an enemy queen/rook on A1 (A8) if the queenside rook is on the B-file.

Makemove: IMO the only clean way is to clear both squares first.

Teemu Pudas wrote:Move generation: I recommend doing it the same way you do it in normal chess, i.e. figure out which squares need to be empty/unattacked before the game. Of course, the initialization code is a bit more complicated...
Special case: you need to check for an enemy queen/rook on A1 (A8) if the queenside rook is on the B-file.

Im not pleased with my old castle moves generator for normal chess too, so in the new rewritten version of RataAeroespacial, I plan to handle FRC and normal chess altogether, after all, normal chess is a subset of FRC.
I like the technique you describe, i could save the squares that need to be empty/unattacked into an array during initialization.

Teemu Pudas wrote:Makemove: IMO the only clean way is to clear both squares first.

The problem is: how i keep track of castling rigths after makemove? how i know if a rook is a-side or h-side when i move it, so i update castling rigths correctly? Im playing with some ideas here, but them are all too slow for being part of Makemove.

The problem is: how i keep track of castling rigths after makemove?

When in doubt, see what Fruit does:

Code: Select all

CastlingRights &= CastleMask[from] & CastleMask[to]; // CastleMask[WhiteKingRook] == everything but white kingside castling

I understand this is pretty common (both the method and the part about Fruit ).

Teemu Pudas wrote:
When in doubt, see what Fruit does:

I understand this is pretty common (both the method and the part about Fruit ).

Hello Teemu Pudas,

This definitely makes it to my post of the year short list!



Later.

I do't think FRC castling rihts need any different treatment than normal castling rights. If you have 4 bit flags (one for each castling) packed in one byte, you can use a 'castling spoiler' (tabulated per board square or per piece in the piece list) that you AND with the flags byte to clear the bits corresponding to the castling that moving or capturing this piece will cause. So you will AND with the spoiler for the fromSquare and toSquare, or with that of the movedPiece and victim, on every MakeMove(). Kings (or e1,e8 in normal) wil spoil both castlngs for that side, premordial Rooks (or a1,a8,h1,h8 in normal) will spoil only the one on their own side. Other pieces / quares won't spoil anything.

The only difference in FRC is that, when you tabulate spoilers per square, you need to move the spoilers to the actual starting location of the pieces. If yu store them by piece in the piece it, there is no difference at all.

In implementing the MakeMove and legality testing of FRC castlings, it probably helps to tabulate the from and to squares of King and Rook, the left-most and right-most square that should be empty (after removing the specified K and R), and the left-most and right-most square that should not be under enemy attack. It can happen in FRC that you have to test a great-many squares (e.g. in a b1xh1 castling), and this might seem very inefficient. But in practice you will almost never pass the test for emptiness in such cases (which is much easier to test).

Thanks, now i understand what Fruit does. Wasnt hard at all, but couldnt figure by myself how to handle castles effectively.