Warning, /games/knights/DESIGN is written in an unsupported language. File is not indexed.
0001 This file describes the design of Knights, especally interactions between the board and the protocols. 0002 It focuses on the interaction of various parts of the program, especially regarding offers and requests for game action other than moves. 0003 The description is not how it currently works, but a plan for implementation. 0004 0005 The central class managing the game is the Manager. 0006 It's a global static, created on application startup and destroyed only on exit. 0007 The main window, the Board, and both protocols never communicate with each other directly, but always through the manager. 0008 There are only two exceptions: 0009 - Creating the protocols is done in Knights class 0010 - The board emits the pieceMoved() signal to the local protocol, making sure the manager gets moves only from the proocols. 0011 0012 1. Interaction with the manager. 0013 The application (its actions: undo, redo, pause, adjourn, draw, resign) calls the Manager's methods. The Manager then create an offer of the appropriate type. Offers (rather than direct commands) are needed because of the FICS protocol, all these actions must be agreed upon by both players. 0014 0015 2. Manager <=> Protocol 0016 When the manager receives an offer, either from the application or from a protocol, it does the following: 0017 - If the sender is the application and exactly one protocol is local, it sends the offer to the non-local protocol 0018 - If the sender is a non-local protocol and the other protocol is local, it sends the offer to the application, which displays it in a drop-down. 0019 - If both protocols are local, all offers are immediately accepted 0020 - If both protocols are non-local, all offers are sent to the opposing protocol. 0021 0022 The protocol deals with the offer depending on its type: 0023 - The FICS protocol has to ask the opponent for approval of every action 0024 - The local protocol accepts them all 0025 - The XBoard protocol auto-accepts all offers except draws. If the program responds to the draw offer, it notifies the Manager about it. 0026 0027 When a protocol is accepted, protocol notifies the Manager by calling Offer::accept() and Offer::decline(). 0028 Alternatively, it can also use the Manager::setOfferResult() function with the offer's id. 0029 The manager then does whatever was offered (pause/start the timers, undo moves). 0030 At this point, the Manager's doesn't call any of the Protocol's functions except acceptOffer(), and this only to the protocol who originally sent the offer. 0031 0032 The protocols can also send offers to the manager, using the Manager::sendOffer() function. 0033 Because with FICS and XBoard, accepting the offer is often the same command as the offer itself, the Manager will make sure that Protocol::acceptOffer() is called if there's already a pending offer for the same command. 0034 If there is not, it will call Protocol::makeOffer(). 0035 0036 3. Manager <=> Board 0037 Manager emits a pieceMoved() signals, which is connected to the Board. 0038 The board then visualizes the move. 0039 Moves made by moving pieces on the board are not connected directly to the manager, but to the LocalProtocol's move signal.