# UCI

UCI is an acronym for **U**niversal **C**hess **I**nterface. It is a standard for communication that competes with
XBoard/Winboard. [http://wbec-ridderkerk.nl/html/UCIProtocol.html](UCI) 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.