Easier for chess engine developers to support: easy to parse, create commands, almost no ambiguous, straight/simple code since it is almost not required automatic algorithms.

Remove the need of having extra configuration/init files for engines.Chess systems (chess GUIs and chess engines) may work more stably.

That reduces unsynchronised problems between chess GUIs and engines There is no way a UCI engine could know this. The time management in this case should act like you have 1:59 for 41 moves (but be aware of a 'cold-turkey deadline' for the upcoming move). Wasting the 59 sec on a single move now effectively reduces your time for the second session by a factor 2, which would be very sub-optimal. But you could also be in a 40moves/min game, where you got out of book after 39 moves, and receive only 1 new minute for the next 40. With movestogo=1 and wtime/btime=59000 you could be in a 40moves/hour game, at the brink of receiving another hour for the next 40 moves, in which case it would be wise to completely spend the remaining 59 sec on the upcoming move, as this is already below average. clocks there is a real problem: in classical TC the timing info accompanying the 'go' command does not specify how much time will be added after the 'movestogo' have been played. It is not only that it makes the communication unnecessarily verbose, but w.r.t. the game state (including clocks) in UCI was a very bad idea. Harm Geert Muller wrote on a Talkchess thread IMO statelessness w.r.t. It removes several critical engine-decisions that are best made by the engine, not the GUI. That is contrary to my design and I have no interest in hacking Crafty to support something that is so different from the WinBoard/XBoard protocol that has been around for a long time and which works perfectly. It tells the engine when to ponder, when to search, when to stop, etc.

It subsumes all engine control parameters.

Missing some useful commands/info: inform chess engines the results, no information about after movestogo GUIs will reset clock or notĮxcerpt concerning UCI from a Robert Hyatt interview by Frank Quisinsky in 2002 :.

It is hard for chess engines to process input/output without an extra thread for that duty.

GUIs may send very long commands (for chess positions) to chess engines.

While the UCI design makes it simple for engine programmers to integrate a 'stateless' chess engine, it was also disputed by various chess programmers, since it subsumes engine control parameters and delegates possibly game decisive stuff to the GUI. The UCI GUI may choose and play moves from an opening book and endgame tablebase. It is also an 'arbiter' instance to decide about the outcome of the game, for instance in declaring a game to be drawn after a threefold repetition has occurred. The UCI capable GUI is not only View and Controller of a chess MVC, but also keeps the Model with its internal game states.

Java chess game github