RUCI

Rust Universal Chess Interface.

This crate parses and creates UCI messages. It follows the UCI standard and uses shakmaty for relevant types.

#![no_std] compatible, unless you enable the engine-connection feature.

See the examples for a demo on how to send and receive messages.

Comparison

There's two other crates that I'm aware of which serve a similar purpose. Keep in mind that this is a shallow comparison, I haven't looked extensively and I am not an expert.

• vampirc-uci:
  • Doesn't use shakmaty, which AFAIK is the go-to chess crate now.
  • API problems:
    • Doesn't separate GUI and engine messages. This is bad if you want to communicate with an engine/GUI, because you're going to need functions like send_message and read_message, where you want to specify which type of message you are sending and receiving. It's not impossible to do this with vampirc-uci, but you won't have strong type guarantees.
    • Doesn't have separate structs/enums for messages. Similar to the above, this is bad if you want to represent a specific message. With vampirc-uci, you can only represent the whole enum.
  • More dependencies; pest and chrono. RUCI only has shakmaty and two macros which don't get included in the final binary.
  • Not #![no_std] compatible.
  • More tests than RUCI.
  • Doesn't provide IO communication with an engine.
• shakmaty-uci:
  • This library is based on/inspired by vampirc-uci, so all of the above bullet points apply, except:
    • Uses shakmaty.
    • Uses nom for parsing and doesn't have any other dependencies.
    • Is #![no_std] compatible.

RUCI might also faster since it doesn't use a parsing library, but I'm not making any claims or showing results because I only have some toy benchmarks (but yes, they do technically favor RUCI).

Feature flags

• engine-connection: enables a structs to manage the IO when it comes to working with a UCI engine. Note that this will add tokio and parking_lot as dependencies. If you're making an engine, listen to stdin and parse it into a gui::Message, then print a string representation of an engine::Message.
• serde: enables Serialize and Deserialize for most types. All of the implementations are derived with no parameters.