Computer Chess Club Archives


Search

Terms

Messages

Subject: Re: UCI - Worth Implementing?

Author: Daniel Clausen

Date: 12:29:55 12/08/02

Go up one level in this thread



On December 08, 2002 at 13:51:57, Dieter Buerssner wrote:

[snip]

>IMO, it would mean, that you need to enhance the WB/XB protocol and to find
>somebody, to implement such enhancements.

I agree. While the 'solution' write-config-file-and-restart-the engine works,
it's very ugly. (and not a solution from a technical POV) So a change in the
xb/wb protocol would be much better.


>As I see the status quo, I have no doubt, that the engine options settable in
>UCI interfaces are a significant advantage compared to WB/XB.

I agree.

But the fact that there's no free (or not free) UCI-GUI for non-Windows
available (Wine-versions don't count) makes xboard/winboard a clear winner _for
me_. :)


<random_thoughts>
I wish that a protocol between the GUI (or driver - it doesn't necessarily has
to be a GUI) and the engine would be defined on 2 levels:

A technical level, which describes exactly, how commands and replies are
structured and stuff like this. Types of commands could e.g be:

-a command which wants exactly one reply, immediately (synchronous mode) In this
case, a reply could be 'assigned' to a command (ie the reply would have a
'commandID' in order to see to which command it belongs)

-a command which 'activates' a mode in the engine, and the engine would send
several 'replies' to the GUI/driver over time. 'ponder' could be such a command
and the PV-lines would be the replies during the search.

-etc

One could write a library which implements this technical level, and
engine/GUI(driver) writers could use this.


The 2nd level would be an applicatoric level and would define basic commands,
like 'newgame' and stuff like that. It should define enough commands so that a
game of chess would be possible. But it should also be 'open' in the sense that
new commands can be added later, w/o having everyone rewrite their code.


When I look at xboard/winboard, this protocol definitely doesn't look like one I
described above. (although I only started to scratch :) I can't comment on UCI
too much, so I better shut up. :)

When I see at the source of some free engines, I see that a lot of the xboard
stuff is so hard-wired. I know it's tempting to do it like that, but in my
engine I try to be as independable on the protocol as much as possible. (my
engine sends reply-objects, which another class takes and converts them to
xboard-combatible output. Same goes when it comes to parsing xboard-input.

A clean protocol, where at least the technical layer could be coded once and put
in a library, would also help to 'clean' the code a bit and make it more
readable/debuggable. (or in chess-programmers terms: could give you a few ELO ;)

</random_thoughts>

Sargon



This page took 0 seconds to execute

Last modified: Thu, 15 Apr 21 08:11:13 -0700

Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.