DXP, Guide, Hub, UDI, what protocol(s) for a Draughts client ?

[mig]

Hi,

I'm working on a new board game client able to play Draughts.

Do you guys have recommendations about what client/engine protocols i must, should, should not, must not implement ?

As far as i understand, there are 4 existing protocols: Hub, DXP, Guide and UDI

The only open source Draughts engine i know is scan, which supports Hub and DXP. From my point of view, if there was only one protocol to support, it should be Hub (text and standard io based).

Are there specifications for the Hub protocol somewhere, or should i get it from the scan source code ?

Other than scan, is there any open source (my program is open source) engine out there i should test my program with ? (ideally on Linux, my development platform even if the final program is multi-platform)

In advance, thanks for your advice.
/mig

[Fabien Letouzey]

Hi,

I'm working on a new board game client able to play Draughts.

Hi Mig,

Thanks for your interest in protocols. As you know, I started a discussion on this subject here:
http://fmjd.org/bb3/viewtopic.php?f=53&t=6795

My feeling is that the community is in a period of transition from DXP to something else that is not clear yet. It could be Hub with additional features (engine parameters, detailed search information), or UDI. In my view, they differ only in syntax.

Guide is not ruled out either. The obligation to support sockets can easily be removed. There are minor syntactic elements that bothered me, but I only remember one part: I think it was about spaces in moves. Only Bert and Michel can comment on its current state.

Do you guys have recommendations about what client/engine protocols i must, should, should not, must not implement ?

As far as i understand, there are 4 existing protocols: Hub, DXP, Guide and UDI

The only open source Draughts engine i know is scan, which supports Hub and DXP. From my point of view, if there was only one protocol to support, it should be Hub (text and standard io based).

UDI is not used by anyone yet, but is a unifying candidate for the future nonetheless. In spirit, Hub and UDI are the same; it should be easy to convert code from one to the other. I have specific gripes with UCI that I haven't detailed; I would like them fixed before we use the protocol. Also, we haven't chosen a way to represent draughts positions and moves. So UDI is not yet fully defined.

Additionally I recommend that we implement DXP as a legacy feature, which I did in Scan. While I don't like it at all, for example the requirement to use sockets, it is ubiquitous. Ideally, programmers will feel the benefits of alternatives with time. Meanwhile, I suggest that we provide choice.

How about your interests: what will you do with the GUI?

Are there specifications for the Hub protocol somewhere, or should i get it from the scan source code ?

Not yet, but I will do so shortly.

Hub was never designed, but was an "implementation detail" of the Hub GUI that I use in tournaments. On top of that it was implemented in a couple of days, so you can guess that not a lot of thinking was involved.

To be future-proof, it needs some changes. Bert modified it a little in his own implementation. At least some of these changes have merit; we will add them to the protocol description when available. If needed, Scan (and Hub) will be updated to follow the movement.

So what I'm saying is: if you feel like going for Hub, you should get ready for syntactic changes in the near future. In my experience, it is a minor issue compared to connecting an engine to the rest of the GUI. I'm just warning you of what's ahead.

Other than scan, is there any open source (my program is open source) engine out there i should test my program with ? (ideally on Linux, my development platform even if the final program is multi-platform)

Yes: Moby Dam which supports DXP. I read in this forum that Harm was considering using Guide in 2009:
http://fmjd.org/bb3/viewtopic.php?p=75987#p75987
It's unclear what his decision would have been in the current situation. I assume that he would love avoiding sockets too.

Fabien.

[mig]

Thanks Fabien, that's clear and useful information.

How about your interests: what will you do with the GUI?

Basically i am developing a desktop application using the Jocly library on the Electron platform. There are a bunch of board games, all running the original Jocly AI, but for the most popular games like Chess and Draughts, i'd like to offer better AI alternatives when specialized engines are available. So basically, the features are a nice 3D/2D user-interface, multi-platform support (Windows, Linux, Mac), open-source, any AI/human players combinations, ... Then i guess, i'll wait for user requests / developer contributions for building more specialized features on top of it.

Other than scan, is there any open source (my program is open source) engine out there i should test my program with ? (ideally on Linux, my development platform even if the final program is multi-platform)

Yes: Moby Dam which supports DXP. I read in this forum that Harm was considering using Guide in 2009:
http://fmjd.org/bb3/viewtopic.php?p=75987#p75987

Excellent ! It compiles on linux. Supporting DXP in the UI now makes more sense.

[mig]

Fabien,

I am having a hard time using the hub protocol on scan.

Isn't the command 'new' supposed to restart a fresh board as it does with CECP and UCI (through the 'ucinewgame' command) ?

Here is what i get (added '<' and '>' to distinguish input and output):

Code: Select all

mig@jasm:~/git/jocly/tmp/scan_20$ src/scan hub
Scan 2.0 by Fabien Letouzey
> init
< init eval
< init book
< init bitbase
< ready
> new
> move 33-28
> go
< info 0 0.0 0 0 0.00 0.0 20-25
< move 20-25 39-33
> new
> move 33-28
< error illegal move

Even doing 'init' does not restart the game.

Is is a bug in scan-2.0 ?

[Fabien Letouzey]

Hi Mig,

I am having a hard time using the hub protocol on scan.

Isn't the command 'new' supposed to restart a fresh board as it does with CECP and UCI (through the 'ucinewgame' command) ?

Sorry about that. I thought you were going for DXP only so I de-prioritised my description of Hub to later this week. It was a mistake

"init" is used only once at the beginning, to ask the engine to load its data files, like this:

Code: Select all

hub
set <variable> <value>
set <variable> <value>
...
init

To initialise the board, you ideally use "pos":

Code: Select all

pos wbbbbbbbbbbbbbbbbbbbbeeeeewwwwwwwwwwwwwwwwwwwweeeee
time 1000
go

The position format is 1 character for the side to move + 1 character per square (standard order). w/b/e for white/black/empty, and W/B for kings. Time is in milliseconds. It’s also possible to use “depth <n>” instead.

However I see that I added a "start" command in Scan to designate the opening position. Then you can play moves one by one:

Code: Select all

move <xxx>

For quiet moves, the move format is the same as standard notation (from - to without spaces; square numbering is from 1). For captures, however, it is from x to x captured-1 x captured-2 … Examples: 30-24, 19x30x24

You can find additional information in these two posts:
http://fmjd.org/bb3/viewtopic.php?p=113449#p113449
http://fmjd.org/bb3/viewtopic.php?p=113456#p113456

Fabien.

[mig]

"start", that was it ! Thanks

My program now works with scan using the hub protocol. I started with hub rather than dxp since this is close from uci and cecp that were already supported. I may release the first version without dxp support.

[mig]

I am having a problem with the scan's "time" command.

In UCI (wtime/btime) or CECP (time/otim), the command tells the engine the remaining time for the whole game and the engine deals with it.

Here, when i play scan against itself in clocked mode, passed the few first moves, which i assume play on the openings database, scan uses the whole time for a single move.

Is it that "time" is supposed to tell how much time the engine has for the next move ?

If so, do you recommend a strategy to give scan a move time based on the game time. Like moveTime=gameTime/n , what should be the value for n ? 30, 40, 50 ? or maybe a smarter non-linear function to reflect the fact the engine needs more time when there are more pieces on the board ?

[Fabien Letouzey]

Hi Mig,

I am having a problem with the scan's "time" command.

...

"time" is a basic command; what you want is "level". Don't worry, the strategy is included in the engine.

I described the protocol here: http://fmjd.org/bb3/viewtopic.php?f=53&t=7754

Good luck,

Fabien.

[mig]

I'm afraid i did not understand.

"level <moves> <time> <inc>" is used for more complex time management, as in tournaments.
The arguments correspond to movestogo, wtime/btime, and winc/binc in UCI; I'm not giving a detailed explanation here. The engine can assume that at least one argument will be 0. The standard combinations are:
- <time> "alone" (the others are 0): sudden death for the whole game
- <moves> + <time>: x/y time control
- <time> + <inc>: x+y (Fischer) time control

Let's say it's White to move. White has 180 seconds remaining, Black 240 seconds. What should be the "level" command arguments ?

[Fabien Letouzey]

Let's say it's White to move. White has 180 seconds remaining, Black 240 seconds. What should be the "level" command arguments ?

level 0 180000 0

[mig]

Thanks, this seems to work.

It's fine for me, but just i find the engine does not make the best of its time credit. If i setup a 5mins/5mins scan/scan game, after one minute for each side, we are already in a 2 kings vs 1 king configuration. Anyway, a 5mins/1hour is clearly won by the 1hour (after a couple of minutes), so i guess it's ok.

[Fabien Letouzey]

Thanks, this seems to work.

It's fine for me, but just i find the engine does not make the best of its time credit. If i setup a 5mins/5mins scan/scan game, after one minute for each side, we are already in a 2 kings vs 1 king configuration. Anyway, a 5mins/1hour is clearly won by the 1hour (after a couple of minutes), so i guess it's ok.

It does seem strange indeed, but time allocation is also a complicated business. Could you record a log of the protocol communication so that I have a look?

In any case, it's unlikely to be an error on your side. If you're using milliseconds, consider your job done!

[mig]

Sorry, this was my fault.

I still had my timing variable divided by 40, as i had when i was using "time" instead of "level". It now behaves as expected !