GUI and other standard protocols for draughts engines

Discussion about development of draughts in the time of computer and Internet.
Rein Halbersma
Posts: 1635
Joined: Wed Apr 14, 2004 16:04
Contact:

GUI and other standard protocols for draughts engines

Post by Rein Halbersma » Mon Nov 15, 2010 07:58

Let's create a new thread for the GUI / engine communication protocol discussion.

Rein Halbersma
Posts: 1635
Joined: Wed Apr 14, 2004 16:04
Contact:

Re: GUI and other standard protocols for draughts engines

Post by Rein Halbersma » Mon Nov 15, 2010 08:05

Below a list of links for the UCI and XBoard chess GUI protocols and PGN (game format)
http://wbec-ridderkerk.nl/html/UCIProtocol.html
http://www.gnu.org/software/xboard/manual/xboard.html
http://www.saremba.de/chessgml/standard ... mplete.htm

In checkers / draughts, we already have CheckerBoard (8x8 board GUI), Damexchange (10x10, P2P) and PDN (game format)
http://www.fierz.ch/cbdeveloper.php
http://www.mesander.nl/damexchange/edxpmain.htm
http://10x10.dse.nl/pdn/index.html

Bert: if you could post your GUIDE protocol here as well, that would be great!

Ideally, we as a programmer's community should be able to agree on a common denominator for a draughts GUI that is flexible enough to encompass the various draughts variants (like the PDN game format does).
Last edited by Rein Halbersma on Mon Nov 15, 2010 08:14, edited 1 time in total.

Rein Halbersma
Posts: 1635
Joined: Wed Apr 14, 2004 16:04
Contact:

Re: GUI and other standard protocols for draughts engines

Post by Rein Halbersma » Mon Nov 15, 2010 08:12

AartBik wrote:
Rein Halbersma wrote:On the other hand, if you could hack up a GUI for 10x10 draughts like you did for chess with pluggable engine support, that would give me a big incentive to look into this more quickly.
I am intrigued by the idea, as I enjoyed implementing the UCI support for Chess for Android (http://www.aartbik.com/MISC/uchess.html). If I can find the time, the 10x10 checkers GUI may look something like this.
Aart,

This looks pretty good already! How much does your Android GUI protocol differ from Checkerboard? To make things easier on engine programmers, it would be nice if the move format etc. are not too different from each other.

Rein

BertTuyt
Posts: 1328
Joined: Wed Sep 01, 2004 19:42

Re: GUI and other standard protocols for draughts engines

Post by BertTuyt » Mon Nov 15, 2010 22:33

Rein, whats the best way I can store a document in this forum?
Or is it better to provide the text as is....

Bert

Ed Gilbert
Posts: 768
Joined: Sat Apr 28, 2007 14:53
Real name: Ed Gilbert
Location: Morristown, NJ USA
Contact:

Re: GUI and other standard protocols for draughts engines

Post by Ed Gilbert » Thu Nov 18, 2010 02:01

Rein, whats the best way I can store a document in this forum?
Bert, when you compose a message for the forum there are controls at the bottom of the page for attaching a file.

-- Ed

BertTuyt
Posts: 1328
Joined: Wed Sep 01, 2004 19:42

Re: GUI and other standard protocols for draughts engines

Post by BertTuyt » Sun Jan 02, 2011 12:44

To all....

Maybe not related to protocols, but definitely dealing with standards.
As I already posted in this forum, Im trying to (re)-activate the Horizon program in Windows.
I think the sources contain much interesting ideas for everyone dealing with Draughts program development.

My question is related to the bitboard implementation.

Horizon uses 3 Bitboards as "general" board representation:
- node->white_black ( bit set for every white piece)
- node->man_king ( bit set for every man white/black)
- node->occ_empty ( bit set for every piece white/black/man/king)

The first board position corresponds with bit0 (#define FLD1 0x1ULL) and position 50 is defined as bit 0x20000000000000ULL ( #define FLD50 0x20000000000000ULL).
Also Horizon uses the principle of ghost fields.

Could we recommend to new programmers (who want to implement bitboards) to use this bit-scheme (as an advantage one could exchange movegenerators, eval-function, or maybe other routines)??

Do you think the choice of these 3 BitBoards is logical (note, at the start of several routines, the "normal" bitboards are derived from these 3), or do you recommend another implementation (more bitboards or different bitboards) ??

Bert

BertTuyt
Posts: 1328
Joined: Wed Sep 01, 2004 19:42

Re: GUI and other standard protocols for draughts engines

Post by BertTuyt » Sun Jan 02, 2011 12:55

Michel,

could you describe your protocol for Dragon GUI communication with the Dragon Engine.
Think it was originally based on our GUIDE proposal (still need to publish the document here on the forum).
I would like to add a communication-layer in Horizon, so it could be used as an Engine with the Dragon GUI.
Maybe you can sent to me the relevant source-part of the engine, so i could do some cut and paste....
Another option, I sent to you the modified Horizon sources (where I added a simple DXP-wrapper), so you could add the GUI <-> engine communication layer...

Thanks in advance,

Bert

BertTuyt
Posts: 1328
Joined: Wed Sep 01, 2004 19:42

Re: GUI and other standard protocols for draughts engines

Post by BertTuyt » Sun Jan 02, 2011 13:05

Herewith the (old , 2004 :) ) proposal for a Engine <-> GUI communication protocol.
Both the Damage and Dragon GUI are (or were) based on this protocol , but I'm sure, implementation on both sides is a little crippled, as we never standardized this protocol.
Basically this protocol is based on similar initiatives in the chess world.

Looking forward to comments, remarks, suggestions, ....

Bert (also on behalf of Michel)
Attachments
GUIDE Protocol Version 0.5 May 2004.doc
GUIDE Protocol Version 0.5, May 2004
(770.5 KiB) Downloaded 558 times

Rein Halbersma
Posts: 1635
Joined: Wed Apr 14, 2004 16:04
Contact:

Re: GUI and other standard protocols for draughts engines

Post by Rein Halbersma » Sun Jan 02, 2011 13:18

BertTuyt wrote:To all....

Maybe not related to protocols, but definitely dealing with standards.
As I already posted in this forum, Im trying to (re)-activate the Horizon program in Windows.
I think the sources contain much interesting ideas for everyone dealing with Draughts program development.

My question is related to the bitboard implementation.

Horizon uses 3 Bitboards as "general" board representation:
- node->white_black ( bit set for every white piece)
- node->man_king ( bit set for every man white/black)
- node->occ_empty ( bit set for every piece white/black/man/king)

The first board position corresponds with bit0 (#define FLD1 0x1ULL) and position 50 is defined as bit 0x20000000000000ULL ( #define FLD50 0x20000000000000ULL).
Also Horizon uses the principle of ghost fields.

Could we recommend to new programmers (who want to implement bitboards) to use this bit-scheme (as an advantage one could exchange movegenerators, eval-function, or maybe other routines)??

Do you think the choice of these 3 BitBoards is logical (note, at the start of several routines, the "normal" bitboards are derived from these 3), or do you recommend another implementation (more bitboards or different bitboards) ??

Bert
Hi Bert,

Best wishes to you (and all others here as well) for 2011!

It's really good of you to make Horizon a usable engine for others to experiment with. To keep in the spirit of the Horizon license, it would be even better if you could submit this code to Harm Jetten's repository. This way there is only a single download point for interested users.

To answer your question: I don't think it really matters which kind of bitboard representation you use. My own struct has this:

Code: Select all

        BitBoard pieces_[2];                            // black and white pieces
        BitBoard kings_;                                // kings
This allows symmetry between white and black in the eval() and move generator. The downside is that you have to generate non-occupied squares on the fly as "Board::SQUARES ^ pieces_[0] ^ pieces_[1]", where Board::SQUARES is the constant bitboard of all valid squares (i.e. excluding the ghost squares).

Rein

Rein Halbersma
Posts: 1635
Joined: Wed Apr 14, 2004 16:04
Contact:

Re: GUI and other standard protocols for draughts engines

Post by Rein Halbersma » Sun Jan 02, 2011 13:27

BertTuyt wrote:Herewith the (old , 2004 :) ) proposal for a Engine <-> GUI communication protocol.
Both the Damage and Dragon GUI are (or were) based on this protocol , but I'm sure, implementation on both sides is a little crippled, as we never standardized this protocol.
Basically this protocol is based on similar initiatives in the chess world.

Looking forward to comments, remarks, suggestions, ....

Bert (also on behalf of Michel)
Bert/Michel,

Thanks for this really professional looking document!! This will be a big help for me to make my engine GUI-ready. Now, if one or both of you could release your GUI binaries + API's (like Martin Fierz's Checkerboard) that would be even better!

Questions: how much of this is compatible with e.g. UCI/Winboard in chess? E.g. (I haven't had time to read the document in much detail) can the engine write to stdin/stdout and will the GUI handle the parsing of commands? What about pondering? And what about support for alternative rules/board variants (for me this is a big deal).

Rein

BertTuyt
Posts: 1328
Joined: Wed Sep 01, 2004 19:42

Re: GUI and other standard protocols for draughts engines

Post by BertTuyt » Sun Jan 02, 2011 13:35

Rein,

I agree that (in the end) several implementation options could/should/would work.
But from a standardization point of view, I like to make a choice.
Basically I have a slight preference for your implementation, based on symmetry principles.

I will await reactions of others, and i might want to change this in Horizon .
Also (one of my things to do for 2011), I want to implement the same structure in Damage.

Do you have a specific remark regarding the bit-numbering (i also thought that it could have an advantage to assign the second LSB to the first board position, and don't use bit0).

Also here I appreciate suggestions.

Bert

Rein Halbersma
Posts: 1635
Joined: Wed Apr 14, 2004 16:04
Contact:

Re: GUI and other standard protocols for draughts engines

Post by Rein Halbersma » Sun Jan 02, 2011 13:54

BertTuyt wrote:Rein,

I agree that (in the end) several implementation options could/should/would work.
But from a standardization point of view, I like to make a choice.
Basically I have a slight preference for your implementation, based on symmetry principles.

I will await reactions of others, and i might want to change this in Horizon .
Also (one of my things to do for 2011), I want to implement the same structure in Damage.

Do you have a specific remark regarding the bit-numbering (i also thought that it could have an advantage to assign the second LSB to the first board position, and don't use bit0).

Also here I appreciate suggestions.

Bert
Hi Bert,

I don't think it is useful to standardize BitBoard level implementation details. This is very program-specific and takes a lot of work to change. It would be better to explore and document the eval *concepts* in Horizon (or even just plain compile them and test against your own eval, like Ed is doing), rather than change the actual implementation.

Rein

PS: I used to have the same 1-column ghost layout as you have, but now I've got a C++ template that takes N columns of ghosts, rotated with a multiple of 90 degrees with respect to the usual board square numbering. You can understand why I wouldn't want to fix this flexibility.

BertTuyt
Posts: 1328
Joined: Wed Sep 01, 2004 19:42

Re: GUI and other standard protocols for draughts engines

Post by BertTuyt » Sun Jan 02, 2011 14:05

Rein, ok... got your point.

Basically i also want to document some Horizon details in this forum, so others can learn from this and/or improve Horizon or the own program.
The eval is really interesting, and i might do the same as Ed, integrate the Horizon-eval in Damage (so create a Hybrid, in Ed words :) ) , and run a match between the two.

Bert

BertTuyt
Posts: 1328
Joined: Wed Sep 01, 2004 19:42

Re: GUI and other standard protocols for draughts engines

Post by BertTuyt » Sun Jan 02, 2011 14:17

Rein,

some answers related to the GUIDE protocol proposal:

* Both the binary (so .exe) of the Damage as Dragon GUI can be downloaded from the net. There are no API's available. If one is interested, I can share the interface source of the engine part in this forum, so others can copy and implement in their own program.

* Think I'm getting older :). Don't remember in detail what we did 6-7 years ago, but yes this protocol was (more or less ) also based on UCI/Winboard examples (available at that time, maybe also these standards have changed, or implemented new ideas which we should adopt).

* The GUI will handle the parsing of commands, the standard is not based on stdin/stdout , but based on sockets (so GUI and Engine could run on separate machines).

* Pondering is possible.

* Alternative rules/board could be handles by the engine "setoption" command

Bert

TAILLE
Posts: 968
Joined: Thu Apr 26, 2007 18:51
Location: FRANCE

Re: GUI and other standard protocols for draughts engines

Post by TAILLE » Sun Jan 02, 2011 14:45

BertTuyt wrote:Rein, ok... got your point.

Basically i also want to document some Horizon details in this forum, so others can learn from this and/or improve Horizon or the own program.
The eval is really interesting, and i might do the same as Ed, integrate the Horizon-eval in Damage (so create a Hybrid, in Ed words :) ) , and run a match between the two.

Bert
Hi Bert,

That sounds as a very good initiative!
As you know we almost never discussed on this forum on our evaluation functions. Basically this subject is considered a trade secret and everybody is convinced that its own evaluation function used some original concepts he does not want to share with others.

A good way to begin a discussion on this subject may be to comment the Horizon evaluation function and I am ready for that. Can you tell us some interresting information on this function ? Where can we found this information ?
Gérard

Post Reply