Author: Tim Mann
Date: 18:30:18 11/29/00
Go up one level in this thread
[Note: I'm sending this before reading any of the other replies in the thread. If some of the questions are answered there, no need to answer them again.] Your new interface sounds like a good thing. My approach with the xboard/winboard protocol has always been to try to keep compatibility with existing engines, but that forces me to always drag along the ugly baggage of the way things used to be, and it makes it hard to fix certain problems. Even if I add a new feature to fix a problem, old engines that don't implement the new feature still have the problem. Starting with a clean slate lets you produce something clean from the start (assuming you do it well!), at the cost of having it work only with your own engine(s) until you persuade other authors to go along. Posting your interface for comments is a good idea; additional input should help turn up any problems early on, before a lot of engines and GUIs are committed to it. From the way your message is worded, it looks like you already consider the interface design complete and have implemented in some software that is already released. Nevertheless, I'm going to comment on it on the assumption that it's not set in stone yet. I like your approach to making sure the GUI always knows what the engine is doing: having the engine never start a search automatically, but only in response to one particular command, and having a "bestmove" response always come back at the end of the search, no matter how the search was stopped. I don't like the fact that you always send a FEN position and move history before every search (except when the special "ponderhit" feature can be used to change a pondering search into a normal search). In a long game, this could mean that a lot of data gets stuffed into the engine before every move. Note that it's not safe to simply send the FEN for the most recent position followed by one move (or zero moves), because in that case, the engine does not know the game history and does not know when it is legal to claim a draw by repetition. You would have to at least start from the position after the last irreversible move (pawn move, capture, or castling) and send all the moves since that point. This is certainly feasible, but seems quite awkward and potentially slow. One could address this issue by saying that the engine has to have logic that says "If the position I was sent is the same one that was already on the internal board, then I will assume that the game history I have stored internally is still accurate", but I think that would be an extremely bad idea. It would result in an absurdity in the case where the user actually set up a new position that just happened to be the same as the last one the engine saw. It also would violate the "stateless" spirit that you seem to be going for in this design. I suppose you could also say that the GUI is responsible for detecting and claiming draws by repetition. I don't think that's a good idea either, because sometimes an engine will tend to make the same move in a certain position repeatedly unless it *knows* the move has been made before, in which case the engine makes a different move and may end up eventually winning. A few more scattered points: Do you want to support chess variants? If so, you may need some extensions to the notation, such as bughouse/crazyhouse drops (N@e4). There also needs to be special notation for castling in Fischer Random; you can't always just give the king's move and be able to tell it is castling because that move wouldn't be legal otherwise. For example, the king can start at f1 and castle kingside, landing on g1. If "isready" is sent while the engine is searching, does the engine send "readyok" immediately, or not until after "bestmove"? What happens if the GUI sends other commands between sending "go" and receiving "bestmove", such as setoption, debug, position, or another go? What should the engine do if the GUI sends it an illegal move in a position command? What about an illegal position (several kings, etc.)? What bestmove should be returned by "go" if there are no legal moves? What if the engine's best "move" is to claim a draw by repetition or the 50-move rule, without making a move first? What if the engine has a draw by repetition or the 50-move rule, but only after making a move? Tournament rules require the player to claim the draw and demonstrate the move, but not actually make the move and hit his clock. The engine needs a way to say "make this move and immediately claim a draw." By the way, both ICC and FICS have special commands for doing that, but unfortunately they are different. (On ICC, saying "multi Nf3 ; draw" is guaranteed to get the draw claim in before your opponent can move. On FICS, you must say "draw Nf3".) If "quit" is sent, must a bestmove still be returned from a search that's in progress? I'd guess not, but then because the bestmove might already be on the way when the GUI says "quit", GUI implementors have to realize that they may or may not receive a bestmove in that case. Wouldn't it make more sense for the copyprotection command to go before uciok instead of after? Then the GUI can know for sure that it isn't going to get the command before proceeding further. In info, I guess the "pv" subcommand has to go last, because it takes a variable number of arguments. Or is the GUI supposed to understand "info pv e2e4 e7e5 depth 2 ..." because "depth" can't be a legal move? You might want to reserve some option names for future expansion of the protocol. That way, if you want to add an option with a standard meaning later, you are guaranteed not to clash with a private option that some engine author has defined. This kind of thing worked well in Internet email headers -- the standard there guarantees that no header standardized in the future will have a name starting with "X-", so such names can be freely used for application-specific extensions. --Tim
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.