RUCI

Rust Universal Chess Interface.

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

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.
  • Uses pest for parsing (ruci does it manually).
  • More dependencies; pest and chrono. Ruci only has shakmaty and two macros which don't get included in the final binary.
  • Lot more tests than ruci. However, ruci has simpler parsing and less code. But yes, I am guilty.
  • 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 message you are sending and receiving.
  • Less direct implementation of the UCI standard.
  • Maybe a pet peeve, but sometimes uses enum fields instead of separate types. IMHO this is bad because you can't represent just an id message, because the fields are baked into the whole enum.
  • Doesn't provide the actual 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.
    • Doesn't have any other dependencies.

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.