Please turn on javascript in your browser to play chess.


Chess Programming


If a terminal node is evaluated one move before the side to move can win a piece, the position will very likely be assigned a value that underestimates the true merit of the position for the side on the move. For this reason, the program attempts to evaluate only positions whose value would not be open to substantial change if searched one ply deeper. Chess programs tend to cope with this problem by performing an additional search at terminal nodes. This additional search is called a quiescence search. Rival uses a method described by Beal (1990) although Beal describes it in a somewhat different context.

If, once the maximum search depth is reached, an additional search is performed that considers only capturing moves, the search will terminate when there are no captures available for the side to move. The value returned from such a search may be inaccurate because of the assumption that a capturing move will always be made if one is available. This allows a position to be valued as very bad for the side on the move if the only capturing move available is one which leads to a loss of material.

To lessen the problem of inaccuracy, at each ply of the quiescence search, the side to move is offered the option of making no move at all. This option represents any move other than a capture. At each ply, the quiescence search returns either the static evaluation value for the position or the value returned by an additional quiescence search, whichever is the greatest.

Moves other than captures can, and should, be generated in the quiescence search. The choice of moves greatly effects the performance of the program. It is a simple matter to generate capturing moves and moves of advanced pawns for consideration in such a search. Other potentially dangerous moves such as forking moves require more work. The data representation of the chess position is fundamental to how quickly such moves can be recognised and generated.