Sunday, December 10, 2006

Universal Chess Interface

I think I finally have glChess working with proper Universal Chess Interface (UCI) support. After testing with the Fruit engine I found I'd made an assumption in the specification - UCI engines do not have to keep track of the board state. This section is not clear so I've sent an email to hopefully add some clarification to the document.

What I was doing was reporting each move as it occured, like:

position startpos
position moves g1f3
position moves d7d5
position moves e2e3
position moves c8g4

This worked fine for Glaurung, as by not specifying startpos it must have just appended the moves to the existing ones. However for Fruit it would assume 'startpos' was missing thus every move reported was considered the first move.

So the solution is to send every move before requesting a new one like this:

position startpos
position startpos moves g1f3
position startpos moves g1f3 d7d5
position startpos moves g1f3 d7d5 e2e3
position startpos moves g1f3 d7d5 e2e3 c8g4

Seems a little inefficient? I guess that the engines could do a string compare to check if this position command is just reporting one new move.

I've tested the new changes by letting Fruit and Glaurung fight it out:

It was just painful to watch - Fruit had to twist the knife by slowly promoting two pawns to humiliate Glaurung. No love lost between these two.

UPDATE: Dec 16th
I emailed Stefan Meyer-Kahlen at and he confirmed that UCI engines are completely stateless and thus the correct behaviour is to send all the moves each time.

1 comment:

Thomas DA said...

Yeah, it does seam a little odd, that the client has to convert the entire game to algebraic notation or fen every time a new move is added.

On the other hand you have more control over the game, and black/white switching seams very easy