Implementing FRC, some pitfalls

Discussions about Winboard/Xboard. News about engines or programs to use with these GUIs (e.g. tournament managers or adapters) belong in this sub forum.

Moderator: Andres Valverde

Implementing FRC, some pitfalls

Postby Volker Böhm » 04 Jul 2005, 18:04

Hi,

I have recently been implementing FRC in Spike, here are some problems I had to solve:

1. General
Store the initial position of king and rook. Replace EVERY occurence of E1, H1, A1, E8, H8, A8 in DoMove and Generate Move.

2. DoMove
FRC-Castling is the first move where pieces may (temporarily) move to positions with own pieces. Don?t capture your own king or rook! Best to remove both pieces and after that place both pieces.

3. Generate Move
Don?t forget that you may jump over pieces as long as they take part of the castling (rook, king). Don?t check for a rook, but for the castling position of the rook (it may be the wrong rook).

The king may be in check after castling even if none of the positions the king have to move above where in check before castling. This can?t happen in standard chess. (Imagine black rook on A1, white rook on B1 and white king on E1).

4. Detect castle move from string
e1g1 is a castle move because the king will move from its castling-starting-position to the castling-target-position. With FRC you have to take care about moves like f1g1 that may be a castle move or a non castle move. One cannot tell (if king is on f1 and white has the right to castle king-side) which it is. Thus don?t code castle moves as king moves. Better use O-O and O-O-O and make sure that you only detect king moves that moves at least two columns as castling move.

Hope that helps!

Greetings Volker
Volker B?hm, Spike Team
Volker Böhm
 
Posts: 66
Joined: 27 Sep 2004, 18:52
Location: Germany

Return to Winboard and related Topics

Who is online

Users browsing this forum: No registered users and 11 guests

cron