GUI and other standard protocols for draughts engines

[BertTuyt]

Gerard,

you can download the Horizon sources from the net ( see Harm Jetten topic, Feike Boomstra's Horizon draughts program released).
I will (most likely) start a separate topic dealing with the Horizon sources and related work.

Bert

[Ed Gilbert]

I noticed on the Talk Chess forum that HG Muller has enhanced Winboard so that it knows about a number of variant games, and now knows the variant "checkers". http://www.talkchess.com/forum/viewtopic.php?t=37634 In addition, Daniel Shawul has created a checkers program called Nebiyu checkers that uses the Winboard protocol. I downloaded these programs and tried them out. It works, although at the moment making multiple captures is slightly inconvenient because you have to use shift-click for the intermediate squares. This is interesting to me, because Winboard is a very complete open source GUI with some capabilities that the draughts programmers can benefit from. Once a month HG hosts an internet chess tournament, and any chess program that plays through Winboard can participate in this tournament because Winboard has the function to interact with the tournament manager. Typically a dozen or so programs participate in these. I think the tournament manager is a separate program, but IIRC it also is open source and it is probably possible to modify this to be able to run a draughts tournament.

I also think that UCI would make a good standard protocol for draughts engines. http://wbec-ridderkerk.nl/html/UCIProtocol.html I believe just about every UCI command applies to draughts as well as chess. There are many chess programs that use this protocol, probably because there are open source GUIs like Winboard that can control UCI engines (through a Winboard to UCI translator called Polyglot). Communication between engine and GUI is done via standard input and standard output. This also seems simpler to me than using LAN sockets.

-- Ed

[Rein Halbersma]

I noticed on the Talk Chess forum that HG Muller has enhanced Winboard so that it knows about a number of variant games, and now knows the variant "checkers". http://www.talkchess.com/forum/viewtopic.php?t=37634 In addition, Daniel Shawul has created a checkers program called Nebiyu checkers that uses the Winboard protocol. I downloaded these programs and tried them out. It works, although at the moment making multiple captures is slightly inconvenient because you have to use shift-click for the intermediate squares. This is interesting to me, because Winboard is a very complete open source GUI with some capabilities that the draughts programmers can benefit from. Once a month HG hosts an internet chess tournament, and any chess program that plays through Winboard can participate in this tournament because Winboard has the function to interact with the tournament manager. Typically a dozen or so programs participate in these. I think the tournament manager is a separate program, but IIRC it also is open source and it is probably possible to modify this to be able to run a draughts tournament.

I also think that UCI would make a good standard protocol for draughts engines. http://wbec-ridderkerk.nl/html/UCIProtocol.html I believe just about every UCI command applies to draughts as well as chess. There are many chess programs that use this protocol, probably because there are open source GUIs like Winboard that can control UCI engines (through a Winboard to UCI translator called Polyglot). Communication between engine and GUI is done via standard input and standard output. This also seems simpler to me than using LAN sockets.

-- Ed

Hi Ed,

Leveraging existing protocols would be very nice! However, I think there are some issues with UCI concerning the level of details that the GUI is taking care of, instead of the engine. IIRC, the GUI keeps track of the board state, and the engine is assumed to be stateless. Also decisions such as opening book, pondering, time management etc. are being handled by the GUI rather than the engine. What is your opinion on that?

Rein

[BertTuyt]

Rein/Ed, others....

Leveraging existing protocols would be very nice! However, I think there are some issues with UCI concerning the level of details that the GUI is taking care of, instead of the engine. IIRC, the GUI keeps track of the board state, and the engine is assumed to be stateless. Also decisions such as opening book, pondering, time management etc. are being handled by the GUI rather than the engine. What is your opinion on that?

Herewith my 5 cents....
* To my opinion the GUI should be more or else dumb
* Engine should completely be self propelling, opening book, time management, keeping track of all moves/positions (for example to detect draw).
* One can debate if the GUI sends a pondering command or not (and that still the engine can decide whether to ponder or not).
* I prefer a design where one GUI can also act as a host for a match between multiple engines.
* The option that an engine an GUI is not loaded on the same machine is important for me, so at least also socket communication should be possible. I dislike an implementation only relying on standard in/out.

I don't know the details of the current chess engine protocols, but when Michel and I discussed years ago a protocol, we took these standards as a base to work from. Also several of the GUIDE commands were loosely based on the chess program Fritz

Maybe we can start discussing some protocol architecture choices, and then focus on the higher level cluster of commands which we want to cover (without going in the details semantics and syntax yet).

Bert

[Ed Gilbert]

Hi Bert,

* Engine should completely be self propelling, opening book, time management, keeping track of all moves/positions (for example to detect draw).

I agree that the engine should make all moves, including book moves, not the gui. The engine should also make decisions about time management. I believe UCI works this way. It tells the engine how much time is left on each player's clock, how many moves are left, and what the time increment is, etc., and the engine decides how much time to use for the search.

Keeping track of game history is better done by the gui. That does not mean the gui does repetition draw detection. Before each search the gui sends to the engine the game history leading up to the current position to be searched, and the engine can then use this info in its decisions.

* One can debate if the GUI sends a pondering command or not (and that still the engine can decide whether to ponder or not).

Whether or not the engine should be pondering is affected by things happening in the gui, so I think the gui should control this. There is nothing really fundamentally different about pondering from normal searching, except for how much time it uses, and really the main difficulty with pondering is coordinating it with the gui. I like the way uci handles this.

* I prefer a design where one GUI can also act as a host for a match between multiple engines.

I guess if a gui could also be a tournament manager, that would be nice. Winboard allows engine vs. engine matches, but it's not a tournament manager. Writing a tournament manager "from scratch" is a lot of work. The fact that there is already one available that has been debugged and tested is a big advantage which is why I was interested to see Winboard supporting checkers variant.

* The option that an engine an GUI is not loaded on the same machine is important for me, so at least also socket communication should be possible. I dislike an implementation only relying on standard in/out.

I guess I don't understand the purpose for it. What is your application for engine being on a different machine from the gui?

-- Ed

[BertTuyt]

Ed,

the only purpose a different GUI and engine I can think of, is that I'm able to play a strong engine from my iPAD (which I don't have yet, as I'm waiting for the iPAD 2), or that I can leave my heavyweight systems at home, and control the engine during a tournament via Internet.
I recognize that there are other ways in controlling a PC from a distance.

But again, both Michel and I have already a GUI, and which protocol is chosen in the end i guess it is relatively easy to adapt.
And if there are better chess GUI's out there, even better.
As mentioned already in another blog, for me the long term perspective is the most important.
I think I really would like to see engine tournaments via the Internet, fully automated, which we can observe, comment, chat, whatever.

If there are is a software base available which enables this, and we need to use a specific protocol to utilize this option , I'm in favor of it.

I went through (low level) UCI and more and more recognize that more is less, and that GUIDE is too heavy and complicated, so I'm open for any suggestions....

Bert

[Rein Halbersma]

Ed,

the only purpose a different GUI and engine I can think of, is that I'm able to play a strong engine from my iPAD (which I don't have yet, as I'm waiting for the iPAD 2), or that I can leave my heavyweight systems at home, and control the engine during a tournament via Internet.
I recognize that there are other ways in controlling a PC from a distance.

But again, both Michel and I have already a GUI, and which protocol is chosen in the end i guess it is relatively easy to adapt.
And if there are better chess GUI's out there, even better.
As mentioned already in another blog, for me the long term perspective is the most important.
I think I really would like to see engine tournaments via the Internet, fully automated, which we can observe, comment, chat, whatever.

If there are is a software base available which enables this, and we need to use a specific protocol to utilize this option , I'm in favor of it.

I went through (low level) UCI and more and more recognize that more is less, and that GUIDE is too heavy and complicated, so I'm open for any suggestions....

Bert

Hi Bert,

At your website, I see this very beautiful screenshot of your new GUI. Very nice! Can you tell us a bit more about the release schedule?

Over at the Talkchess forum, I have been interacting with HGM and Daniel Shawul who maintain the WinBoard GUI and Nebiyu checkers engine, alluded to by Ed in an earlier post in this thread. Their programs now correctly support 10x10 draughts and 8x8 checkers. For engine programmers, it's relatively straightforward to make an engine WinBoard compatible, since all communication is through standard input/output.

I notice your GUIDE protocol uses sockets. I wonder if you can shield engine authors from this implementation decision? E.g. the UCI and WinBoard GUIs use pipes to connect the stdin of the engine with the stdout of the GUI (and vice versa). Is it possible to do something similar with sockets? E.g., you could still maintain the DamExchangeProtocol by simply emitting the various DXP messages with commands such as "dxp <dxp_message> \n". I have working DXP layers 1 and 2, but I would much prefer to only use layer 2 (the message layer) in the engine, and let the GUI handle layer 1.

Rein

[BertTuyt]

Rein, thanks for the compliments

I hope that the GUI is available around end July.
I still need to implement the Electronic Board interface (and as i received valuable input from Jan-Jaap i guess this timing is realistic).

Next to that there are still some bugs in the GUI (some known some i need to resolve).
And last but not least in this GUI implementation I did not include DXP and a graph-view of the game score.
I might implement DXP before the end of the year, but the graph is something for the 2012 version.

If you drop me a line ( h.tuyt AT chello.nl ) I can provide a link to the download location (you also might want to help with some GUI feedback and bug fixes).
Last (and not least) I really hope the community will use this GUI as a base for further development as I will provide source code of the total GUI for everyone who is inters ted (the only small problem is that the code is MFC based on VS 2010 )...

Next to that I'm planning to provide a Engine with a GUIDE wrapper with the modified Horizon code, also here all source code will be made available, so everyone can learn how to connect an engine to the GUI.
Later in 2012 I will also post almost all of the Damage source code .

I'm really open for any GUIDE suggestion, I'm not completely happy with this protocol (it should me simpler), so i hope some good suggestions will pop up. Also I think it is a good idea to allow multiple connectivity interfaces , such as the one you suggested.

With kind regards,

Bert

[Rein Halbersma]

Last (and not least) I really hope the community will use this GUI as a base for further development as I will provide source code of the total GUI for everyone who is inters ted (the only small problem is that the code is MFC based on VS 2010 )...

Next to that I'm planning to provide a Engine with a GUIDE wrapper with the modified Horizon code, also here all source code will be made available, so everyone can learn how to connect an engine to the GUI.
Later in 2012 I will also post almost all of the Damage source code .

That's great news and very generous! Looking forward to that.

I'm really open for any GUIDE suggestion, I'm not completely happy with this protocol (it should me simpler), so i hope some good suggestions will pop up. Also I think it is a good idea to allow multiple connectivity interfaces , such as the one you suggested.

Basically any protocol (DXP, UCI, WinBoard, GUIDE) is fine as long as you can separate a message layer from the connectivity layer. This is what bothers me a bit about DXP, or at least in Frank's DLL, because there the socket layer and the message layer are a bit intertwined. I have my own DXP implementation where the design is fully separated. It's also much easier to extend to new message types (I don't use unions but have a small class hierarchy).

If the GUI can shield engines from knowing how they are connected (either through sockets or pipes) then this will make life much easier for the engine programmers because they can simply use stdin/stdout for their communication to the GUI. It also makes engines much easier to port to different platforms.

Rein

[H.G.Muller]

Note that there already exists a version of WinBoard (the so-called Alien Edition) that has checkers / draughts amongst the supported variants. Compared to the standard version (which only supports Chess variants), this means that it solves the general problem of entering multi-captures, and handling them from the engine. There even is an engine for it that plays checkers and international draughts (and a host of other games), namely Nebiyu.



http://hgm.nubati.net/alien.html
download: http://hgm.nubati.net/WinBoard-Nebiyu.exe

[H.G.Muller]

After reading through the entire thread, I'd like to contribute the following comments:

Sockets are a concept from low-level I/O, and it is better to make standards independent of this level of detail. Note that WinBoard does support running of (Chess) engines on other machines then it is running itself. To acheive this you can use ssh or any other remote shell. It simply uses ssh with the necessary arguments to run the desired engine on the remote machine as the engine command. The remote machine of course has to be set up as a server, in this case by running a standard ssh server on it. The engine can the remain completely oblivious of this; in WB protocol it is a simple console application communicating through stdin/stdout, and all the low-level details of making a connection with it are handled by the GUI, or standard software for making inter-machine connections. This is much easier for the engine author then to implement server capability in every engine.

Most of the functions of a GUI for board games are completely game independent. E.g. the tournament manager part. The latest version of WinBoard does have a built-in tournament manager capable of running several flavors of many-player tournaments (round-robins, (multi-)gauntlets, Swiss), next to the simple two-player matches. But already for a long time there exist general tournament managers (e.g. PSWBTM) that invoke WinBoard as an external process, controlled through command-line arguments, to play a single game. And then wait for the game to finish (and WinBoard to exit) before launching a new WinBoard process for the next game. These would in principle be usable with any GUI that has some(quite limited) command-line-option compatibility with WinBoard.

WinBoard protocol itself is ugly, because it was never really designed, but emerged as a collection of 'historic accidents'. It does the job, though, and WB compatibility is extremely easy to implement in an engine. It just has to understand moves and a handful of simple text commands (new, force, go, level N M I, time T), and it would already be capable to play automated matches. WinBoard supports many non-native protocols through adapters. This is a very efficient and reliable method, and WinBoard has built-in mechanisms to completely shield this from the user. For instance, the user only has to tick a checkbox to indicate that the specified engine uses UCI ptrotocol, and WinBoard automatically forks of an adapter process that will run the engine, in stead of the engine itself. What program is used as adapter in response to a certain checkbox / command-line option is user-configurable.

As the features supported by WinBoard are very advanced, highly configurable, and generally applicable, writing an adapter for it to support a certain protocol is often a very easy way to obtain a high-quality GUI for that game. This is what I have done for Shogi (Japanese Chess) and Xiangqi (Chinese Chess).

[Yves]

Note that there already exists a version of WinBoard (the so-called Alien Edition) that has checkers / draughts amongst the supported variants. Compared to the standard version (which only supports Chess variants), this means that it solves the general problem of entering multi-captures, and handling them from the engine. There even is an engine for it that plays checkers and international draughts (and a host of other games), namely Nebiyu.



http://hgm.nubati.net/alien.html
download: http://hgm.nubati.net/WinBoard-Nebiyu.exe

Hello
I found the forum WinBoard-Nebiyu Version 1.41 draughts 10x10.
Thanks to your advice, I play NebiyuCheckers Draughts against itself with Peer to Peer and it works fine.
I tried the new version 1.45 Nebiyu but only playing the game of Checkers 8x8.
Thank you kindly tell me if the Winboard 4.8 version is compatible with Nebiyu 1.41
in the future to build a database.
Cordially