angrygoats
/
uci
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity
An implementation of the Universal Chess Interface in Rust.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
12 Commits
2 Branches
0 Tags
74 KiB
Tree: bee54e617c
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'bee54e617c'
${ noResults }
uci/README.md

3.1 KiB
Raw Blame History

UCI

UCI is an acronym for Universal Chess Interface. It is a standard for communication that competes with XBoard/Winboard. http://wbec-ridderkerk.nl/html/UCIProtocol.html makes communication a little easier, but it seems there's a nearly religious debate on which is better.

Here are some benefits to using UCI:

  • It works with Chessbase 14
  • Simple to use
  • Fewer bugs in code
  • Built from scratch rather than ad-hoc
  • Flexible time controls
  • Additional search information can be displayed

and to be fair, some downsides:

  • Stateless
  • Delegates some important decisions to the GUI
  • Difficult to add new features on top of it
  • Sends the whole move list each turn

Overall, UCI seems to be fairly popular and is worth considering for your next engine.

Why

People shouldn't waste their time implementing protocols that really should be libraries. With this, you can include it in your project, build your engine on top of it, and be able to focus on what matters - beating Stockfish.

Will You Implement Winboard?

Yeah, probably.

Why GPL 3.0?

I have noticed that there are no good free solutions so that anyone can build a chess engine. Since UCI is a common format, and something all engines (should) implement, making this chunk of it free makes total sense.

Usage

UCI is designed to complement your chess engine rather than be a one-stop shop for engine development.

As such, you will be responsible for maintaining the game loop. What UCI provides is a series of functions that will help you send data to, and receive data from the GUI.

First Steps

Your engine will first need to wait on STDIN for a command uci from the GUI. This indicates that your engine should switch to UCI mode. You can use commands::UCI to make sure the command text you are waiting for is correct.

Next, you'll need to create a copy of Engine by calling Engine::new. Once this is setup, you can call Engine::identify to send identification information to the GUI.

Once identification is done, you need to send your configuration options. This is dependent on your engine. Refer to the UCI standard for the available options. You must configure this before calling Engine::new so this guide assumes you've done that already.

To send your configuration options simply call Engine::send_available_options. Once this finishes uciok will also be sent, indicating to the GUI your engine is ready to roll. At this point you need to set up two threads, one to calculate with your engine, and one to read STDIN.

EXAMPLE HERE WITH LOOPS IN THREADS AND BLOCKING AND WHATEVER

Notice how in our STDIN thread we are calling Engine::parse and the handling the output using a match statement depending on what kind of token it was. You are responsible for obeying the commands from this thread, the UCI library just makes it convenient to work with.

TODO: MORE STUFF WITH EXAMPLES THINGS LIKE SENDINB BEST MOVE AFTER CALCULATING, ETC

Other Options

TODO: Talk about the additional helpers available in the UCI library and what-not.

  • Copy protection checking
  • Registration checking