Protocols and tools

[Fabien Letouzey]

The first thing I want to work on is to process the move message (after the go).
Scan replies with a standard notion move ( such as 31-26) followed by (at least I assumed, didn't go into details) the first expected counter move.

It has the same structure as UCI; I just separated commands into smaller pieces for easier parsing (I was short on time). So Scan's answer here has the same properties as UCI's "bestmove". On the GUI side, UCI "position" + "go" becomes Hub "pos" + multiple "move"s + "level" + "go" (or "ponder"). The information is the same, but each command has a single purpose.

In GUIDE the move format is from to { Captures [capture-1] [capture[2] ... }
If there is no capture the output is (as an example) 31 26 00.

As the engine exactly knows what move including all the captured pieces, this format also also solves the ambiguous move problem.
It is also true that in 99.99% most likely only from and to is sufficient.
One can also solve the ambiguous problem by an capture notation (including turns or captured pieces) as also is used in pdn.

Actually, Scan's moves are not ambiguous. I guess it uses what you call "capture notation" here: from x to x cap x cap ... (without any space). I slightly favoured it over from x cap x cap ... x to which feels less natural for a computer.

Regarding spaces, look at any programming language other than the oldest Fortrans, and you won't see them in basic tokens such as number literals very often. My view is that GUIDE forces the programmer to use imperative (stateful) style for parsing moves. I prefer to split lines into space-separated tokens that I handle with dedicated functions. For the same reason, Scan's "FEN" is the same as GUIDE's except that there is no space between the side to move and the piece placement. I would understand if everybody saw this as nitpicking though; programming languages are another hobby of mine.

My question , is there a specific preference we can standardise, so I can include this in the Damage GUI?

I see two levels. Scan agrees with the "send all captured pieces" principle. The second level is representation; I picked something closer to the standard notation, but it doesn't look very important.

[Maurits Meijer]

I would prefer a format that fully describes what happens on the board and also is reversible. That way anyone can build an interface without the need to build a move generator. It would also speed up the execution of the moves, which may matter when you are executing a lot of moves on a slow platform.

Slagzet.com uses a JSON representation for this:

Code: Select all

 [
        {
          "start": 29,
          "land": 23,
          "pieceType": 2
        }
      ],
      [
        {
          "start": 18,
          "pieceType": 4
        },
        {
          "take": 23,
          "land": 29,
          "pieceType": 2
        }
      ],

Meaning a white man moves from field 30 to field 24; The black man on 19 captures the white man on 24 and lands on 30.
It isn't the nicest implementation of the idea, but it has served me well.

[Walter]

I built a (partial) web-based GUI a couple of years ago to play against engines running on a server (server side used sockets and DXP or GUIDE to talk to engines and used SignalR to communicate in real time with web client). Based on that experience I would have the same requests that the GUI does not need to have any kind of move generator.

So the Move information coming from the engine should include information about all captured pieces, all intermediate squares and piece types. With that information the GUI can produce a complete animation of the move without having to know any rules (allowing same GUI to work for Frysian Draughts or Killer Draughts etc.) and reverse it again.

Also important is that the engine can provide the list of all Legal Moves to the GUI. The GUI can use this information to control the user input.

On a different note, it would also be great if the engine could enable the GUI to get information from egdb (e.g. to get "Win in X", "Loose in X" information for each move).

[BertTuyt]

For pragmatic reasons I implemented the Scan format in the GUI, so I didn't need to change the Engine.
So 31-26 , 26x17x21

Bert

[BertTuyt]

Based upon a very rudimentary implementation of UDI, I started to modify the Damage GUI, to enable Engine Tournaments.
Although I'm still working on it, as the underlying program architecture needed a complete overhaul, I already share with you some results.
First of all I modified the Damage GUI internals to deal with 2 UDI pipes, and added an additional Engine View.

Next to that I extended the GUI ribbon with Engine Tournament buttons, see below.

Tournament Ribbon.PNG (14.78 KiB) Viewed 14935 times

With the Settings button one can set the Tournament conditions, and add/invite Engines.
They don't need to be stored in a specific directory, as the Dialog, stores Engine name and Engine Path.
Below the (current) Settings Dialog.

Tournament Settings.PNG (9.35 KiB) Viewed 14935 times

In this example I have added the 2 Engines Scan22.exe and Scan21.exe.
Basically these are the normal Scan engines , but I added the UDI commands, and the identification string sends a Scan 2.1 and Scan 2.2.

With Run the tournament starts, and during a tournament one can pause (which becomes effective after the last move of an engine), or terminate the Tournament.
With Info one can retrieve the Tournament status at any time (not yet implemented).
All games are automatically stored in a pdn file.
The pdn file name is the Tournament Name (so in this case "Test Tournament.pdf").

Below a screenshot of the GUI while a tournament is ongoing (in this case an Engine Match between Scan 2.2 and Scan 2.1).

Damage Tournament.PNG (946.39 KiB) Viewed 14935 times

The Engine active, is recognized by the Green Engine Name.

In case the Tournament is paused (again after the last move is received and processed), the Engine which should start the next search, is indicated by a yellow color.
Next to that the Game clocks pause.

Tournament Pause.PNG (68.05 KiB) Viewed 14935 times

Again much works still to do, but I wanted to share this with you.
If all works, Engine Matches (and Tournaments) will become very simple.
Even no DXP implementation is needed, only a very basic UDI protocol.

Keep you posted,

Bert

[Krzysztof Grzelak]

Please share this'll be a very happy man.

[BertTuyt]

Krzysztof, without any doubt I will share the GUI (for free) with our GUI Draughts community.

If Engine developers (like Harm, Michel, Fabien, Ed, .., to just name a few), would include a basic version of UDI (as described in a previous post), than for you setting up an Engine Tournament would become very easy.

And I guess to make a UDI wrapper for Flits and Truus, is also not impossible in the end.

As with UDI, one can also play a DXP Match (what I need to include is, to provide a file with openings for an Engine Match), programming efforts will become relatively straightforward.

So looking forward to remarks/suggestions from all involved.....

As I now start to see the beauty of pipes (and UDI), I might even abandon GUIDE one day, in favor of UDI.

Bert

[Krzysztof Grzelak]

So again, I am unhappy man. Thank you for your effort is inserted Bert.

[Fabien Letouzey]

Hi Bert,

If Engine developers (like Harm, Michel, Fabien, Ed, .., to just name a few), would include a basic version of UDI (as described in a previous post), than for you setting up an Engine Tournament would become very easy.

I am willing to implement UDI in full, but I don't see any specifications.

My proposal:
- stay as close to UCI as possible (keep "fen", "mate", ... even if not proper for draughts)
- decide on move and position notation
- keep extensions for later (tablebase score or probe, average leaf depth, ...)

UCI dialects have already been designed for Shogi and Chinese chess:
http://web.archive.org/web/201503260014 ... i/usi.html (Wayback Machine)
http://www.xqbase.com/protocol/cchess_ucci.htm (in Chinese)
A synthesis by Evert Glebbeek:
http://www.eglebbk.dds.nl/ustari_protocol.txt

Fabien.

[BertTuyt]

Fabien, thanks for your reply.

I think I already posted something about an minimal UDI specification.

So here another try.

• All communication is done via standard input and output with text commands,
• The engine must always be able to process input from stdin, even while thinking.
• All command strings the engine receives will end with '\n', also all commands the GUI receives should end with '\n',
• if the engine receives a command which is not supposed to come, for example "stop" when the engine is not calculating, it should also just ignore it.
• The engine will always be in forced mode which means it should never start calculating or pondering without receiving a "go" command first.

program udi , (example scan udi)
Tell engine to use the udi (universal draughts interface)

The engine should respond with
id author xxxx (example id author Fabien Letouzey)
id name xxxx (example id name Scan 2.0)

The order in which both are sent is not prescribed.

Than the engine sends a ready, signaling that initial start has been completed.

Than the GUI sends an init command telling the engine to load tables , etc....

After completing the engine sends another ready, so now the initialization process is finalized.

Move format:

The move format is from-to for a non-capture move, and fromxtoxcapture1xcapture2x..... for a capture move.
A nullmove from the Engine to the GUI should be sent as 0-0.
Examples: move 31-26 move 26x17x21
Note: the move may included an expected next move (but my GUI doesn't use this output so far).
The order of captures is not relevant.

To start the engine , the next 3 commands should be send

pos xxxx, the pos string starts with w or b (is positon to move) and than for the squares 1 to 50 the content e = empty, w = white man, W = white king, b = black man, B = black king,
(example pos wbbbbbbbbbbbbbbbbbbbbeeeeeeeeeewwwwwwwwwwwwwwwwwwww), initial position white to move
level numberofmovesleft timeleftinmsec (example level 75 300000), 75 moves to go, 300 sec. left.
go

In between search results can be provided with info xxxxxxxxxxxxxxxxxxxxxxxxxxxxx (so far any format is okish).

This was all I implemented so far.

At least much is missing, but already sufficient (in my case) to play a game.

Any comments and other suggestions welcomed.

Bert

[Fabien Letouzey]

Hi Bert,

I think I already posted something about an minimal UDI specification.

So here another try.
...

OK so that's not UCI at all, at least syntactically. I clarify for the sake of others: you are advocating using the Hub protocol (with a handful of changes) that Scan uses during on-the-board tournaments. The protocol is minimal ("designed" for a single engine/GUI/user/purpose) and IMO not suitable as is for the far future. We would have to extend it (engine-parameter description, more flexible search output, ...), forcing programmers to change their code. Moreover it would arguably be more and more similar to UCI.

That's why I see two directions:
- discuss necessary extensions before calling for implementation
- use UCI (with minimal changes); for me that's what "UDI" suggested

I'll follow regardless, but not piecemeal. As GUI author you will have more work, and for me that's reason enough that you can choose. But I feel that asking programmers to implement only a subset will give more work to everybody (including you) in the long run.

Don't get me wrong: I like the initiative very much, but I think that the protocol is not ready for prime time. For just you and me it wouldn't matter.

Fabien.

[BertTuyt]

Fabien, I cant disagree

I implemented a Hub-ish protocol so I could test the GUI changes needed (based on multiple stdin, stdout).
For this reason I only started with the minor set, and full blown UDI for me is/was not a necessity for this purpose.
And (just as an example) pragmatic parameter setting is also possible via the .ini file.

I also have no objection to draft a full UDI proposal.
But only if someone sees the need to.

Most programs have their own GUI (like Dragon, KingsRow), or can rely on an older one (Like MobyDam with Dam x.x).
Next to that most engines have implemented the DXP protocol.

So it could be that a UDI in the end is only for the museum, and I have more things I want to do with Computer Draughts (like eval learning).
At least I will continue to finalize (for my own purpose) the GUI, make it available via my Dropbox, and hope to hear form others........
Finally, I recognize that platform independency would be great, but I guess I only have the time when I retire.

Bert

[Yves]

Hi Bert
Thank you tell me the Protocols and tools to properly process
set options and start a test tournament scan21 and scan22.
Yves

[Ed Gilbert]

Bert,

A tournament manager for draughts would be a very nice tool. I would be happy to provide a kingsrow engine that implements UDI. But I agree with Fabien's points about defining it and doing it piecemeal. Select a subset of UCI commands that you think you can support and list them. Get comments from engine programmers. When there is a consensus that you have a workable set of commands, then we can implement.

(example pos wbbbbbbbbbbbbbbbbbbbbeeeeeeeeeewwwwwwwwwwwwwwwwwwww)

I don't know anything about UCI. But FEN is the standard notation for positions in draughts, so unless this example is to conform to some UCI standard, I suggest using FEN.

-- Ed

[BertTuyt]

Ed, thanks for your email.
So far I only implemented a Q&D protocol, while I wanted to connect Scan with my GUI.
So as I dont have the time, to define all ins and outs, I hope that this forum could provide some clues.
Im happy to adapt the Damage GUI for this purpose.

Bert