GUI and other standard protocols for draughts engines

[Rein Halbersma]

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

[Rein Halbersma]

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).

[Rein Halbersma]

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]

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]

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]

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]

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]

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)

[Rein Halbersma]

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]

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]

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]

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]

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]

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]

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 ?