TalkChess.com

Asim Pereira · Joined: 25 Mar 2012 Posts: 31 Location: Bangalore

Hi,

I am planning to include engine support in my Chess apps.
I have never worked on UCI or Winboard protocols before and hence wanted your opinion on what protocol should I support, to begin with.
Which protocol will be easier to work with?

Note I am NOT planning to write my own engine but just provide an interface to existing popular engines.

Regards,
Asim

Ted Wong · Joined: 01 Nov 2010 Posts: 236

That depends on what engine you want in your Android app?

Asim Pereira · Joined: 25 Mar 2012 Posts: 31 Location: Bangalore

I am thinking of first getting the protocol right such that I get familiarized with GUI-engine communication.
Then I will use any of the strong engines available in either of the protocols.

Do you think the approach is ok?

As I understand there are strong (and open source) engines in either category.

H.G.Muller · Joined: 10 Mar 2006 Posts: 12765 Location: Amsterdam

If you support one of the protocols, you could support the other through an adapter. Especially for GUI engines to run UCI engines there are exellent open-source adapters.

Ted Wong · Joined: 01 Nov 2010 Posts: 236

I don't think it's difficult to support a protocol if you can communicate with an engine. In terms of software engineering, you just need a design pattern where you implement an abstract interface. I've used it, and it's much more flexible than integrating the whole something like UCI2WB into the source. Up to you, I personally prefer an interface with some pure virtual functions.

H.G.Muller · Joined: 10 Mar 2006 Posts: 12765 Location: Amsterdam

I was not implying the adapters should be integrated in the source. In fact I think that is highly undesirable, because it would deny the user the choice of adapter, and the possibility to adapt it. That I mentioned their open-sourceness was only to indicate they can easily be made available on any platform.

The design with an abstract interface is also my guiding design principle for WinBoard. Except that the abstract interface in that case is identical to WB protocol, as it is the most potent of all protocls. This can then translated to other protocols (or at least the subset supported by those protocols) by adapters, which for flexibility are kept as independent programs, automatically invoked by the GUI.

Matthias Gemuh · Joined: 09 Mar 2006 Posts: 2876

On the GUI side, UCI is easy to support, WB is messy.
Look at permitted move formats, for example.
_________________
My engine was quite strong till I added knowledge to it.
http://biglion.bplaced.net
http://w2410tmq9.homepage.t-online.de

H.G.Muller · Joined: 10 Mar 2006 Posts: 12765 Location: Amsterdam

Indeed, that it is alowed to send SAN, or that an engine can even request the GUI sends SAN to it, is an abomination. OTOH, a GUI would need to be able to parse and generate PGN, and thus SAN to be any good. Using the routines required for that makes it almost zero work to apply them to the engine communication. So in practice the impact of this is not significant.

Matthias Gemuh · Joined: 09 Mar 2006 Posts: 2876

H.G.Muller · Joined: 10 Mar 2006 Posts: 12765 Location: Amsterdam