Move Determination
6.1 Move Determination Walkthrough
After establishing the XBoard protocol, the client (white) starts a game by indicating a move. The following sequence diagram shows an example interaction at the subsystem level from the input “e2e4” (white pawn e2-e4) to DokChess' response, which is the output “move b8c6” (black knight b8-c6, “Nimzowitsch defense”).
Fig.: Sample interaction for move determination
First, the Text UI subsystem validates the input with the aid of the Rules subsystem (→ Concept 8.4 “Plausibility Checks and Validation”). The move in the example is recognized as legal and performed on the (stateful) Engine (the performMove message) afterward. Then, the Text UI subsystem asks the engine to determine its move. Since move computation can take a long time, but DokChess should still continue to react to inputs, this call is asynchronous. The engine comes back with possible moves.
The Engine examines at first whether the opening book has something to offer. In the example, this is not the case. The engine has to calculate the move on its own. It then accesses the Rules and determines all valid moves as candidates. Afterward, it investigates and rates them, and gradually reports better moves (better from the perspective of the engine) back to the caller (the Text UI subsystem). Here, the observer pattern is used (implementation with reactive extensions).
The example diagram shows that two moves have been found (pawn e7-e5, knight b8-c6) and finally the message, that the search is complete, so the engine does not provide better moves. The Text UI subsystem takes the last move of the Engine and prints it as a string to standard output according to the XBoard protocol: “move b8c6”.