Chess Theory: Double check response - always king move?

Hello,

I'm implementing a chess engine. My current issue is about -fast- generation the list of legal moves in the situation where the king is in check. During some quick thoughts about possible situations I found some "rules", which I would like -you- to have a look at. Maybe I have overlooked something...

== 1. Situations with 1 piece attacking the king (simple) ==

a) King may move to an unattacked neighboring field

b) King may take attacking piece, if unprotected

c) Any other piece (except king) may block (=move between) or take the attacking piece.

== 2. Situation with 2 pieces attacking the king (double attack) ==

a) King must move to another, neighboring unattacked field (which may also mean: taking an unprotected neighboring opponent piece; which can of course be one of the attackers)

While the 1. Situation is clear, I'm not 100%ly sure about the double attack scenario. My "proof" is like the following: taking only one attacker (not using the king) leaves the king in check (=> other attacker). AND: Blocking two attacks at the king with one figure is not possible. Reason: The two attackers must attack from different directions (else one attacker would block the other one's attack).

Rule Next: More than two attacks at the king aren't possible (such a position is not reachable by legal moves). As the 1. king must have been -not- in check before the opponents move -and- 2. at most the last moved piece and one additional piece (which's attack was blocked by the last moved piece before) may start to attack a king during one move. Reason: one piece (last moved one) may only unblock one attack, because attacks must come from different directions or one pieces would block the other.

What do you think about that? Am I correct? Any mistakes?

Thanks for checking...

Stefan

You are correct that in the case of a double attack on the king, the king must move.

True. I concur, etc. 

To your first list I would say, item b is unnecessary -- it is a part of rule a) the king may move to an unattacked field (if that happens to involve capturing the piece giving check, well that's just gravvy.) And rule c should be made into two slightly expanded rules:

b: "interposition" a piece may move to block the check so long as that move does not expose the king to check

c: "capture" a piece may move to capture the piece giving check so long as that move does not expose the king to check

@Kingpatzer: Thanks for having a look at it...

@JG27Pyth: I also thank you. Yes rule "b)" can be put together with "a)". Spliting in "interposition" and "capture" is actually not needed for my case.

My engine currently generates moves for all pieces when placed on the board. These move lists are updated when interfering pieces are placed on the board (or are removed from it). Also attacked fields are tracked for white and black pieces seperated and also pinned pieces are detected (rook, bishop, queen attacked pieces with king behind with no obstacles between). The number of pieces attacking the king is counted; also the first attacking piece will store the "way" between it and the kind + its own position. ((in the end it will actually not be a list, but some quicker processing. But for now this explanation should do...)).

The legal move list is then combined as following:

1. If king not attacked: Combine the move lists of all pieces (of the side on the move) which are not pinned.

2. If king is attacked twice: only do king moves.

3. If king is attacked only once: combine king moves + all moves (including exchange moves) of pieces (except pinned ones) to positions in the position list which was saved by the attacking pieces.

If the combined move list is empty:

1. if king is attacked: mate

2. if king is not attacked: stale mate

Using these quick incremental updates I hope to be able to gain some speedup in comparison to engines that rebuild their entire move list at every single move. I think this method is usually avoid because of it's complexity... which could introduce a lot of errors during calculations. But once it works stable, it should work fine.