Protocols and tools

Discussion about development of draughts in the time of computer and Internet.
Fabien Letouzey
Posts: 283
Joined: Tue Jul 07, 2015 07:48
Real name: Fabien Letouzey

Re: Protocols and tools

Post by Fabien Letouzey » Tue Oct 04, 2016 06:11

Ed Gilbert wrote: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.
The spirit of UCI is to simplify engine implementation (think newcomer). A non-goal is direct user interaction, so standard notation is not mandatory.

UCI uses (chess) FEN indeed but I think it would be less appropriate for draughts. For example, multi-character "tokens" appear; this complicates parsing.

Additionally to positions, we also need to decide on how to represent moves. Again, I think that the PDN way is not appropriate. It should be obvious why, and this shows that standard (for humans) is not necessarily a good choice. UCI does not use standard move notation.

Regardless, I will also implement whatever we end up agreeing on.

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

Re: Protocols and tools

Post by Ed Gilbert » Tue Oct 04, 2016 17:06

UCI uses (chess) FEN indeed but I think it would be less appropriate for draughts. For example, multi-character "tokens" appear; this complicates parsing.
FEN must be quite different in chess from draughts. I was thinking about the FEN setups that are described in the PDN3.0 standard. For example, the start position is described as "W:W31-50:B1-20".

-- Ed

Fabien Letouzey
Posts: 283
Joined: Tue Jul 07, 2015 07:48
Real name: Fabien Letouzey

Re: Protocols and tools

Post by Fabien Letouzey » Tue Oct 04, 2016 17:57

Ed Gilbert wrote:FEN must be quite different in chess from draughts. I was thinking about the FEN setups that are described in the PDN3.0 standard. For example, the start position is described as "W:W31-50:B1-20".
I was talking about draughts FEN. What I meant was that, in chess FEN, pieces of information are represented by single characters. The draughts version is bound to complicate things (either lookahead or state).

Furthermore, it's not like the encoding I propose is alien: it's virtually identical to DXP (translated to English) and GUIDE (with a single space removed). I haven't recently checked though.

CheckersGuy
Posts: 17
Joined: Mon Oct 17, 2016 09:05
Real name: Robin Messemer

Re: Protocols and tools

Post by CheckersGuy » Mon Nov 14, 2016 12:04

Hello,
I have a question about the CheckerBoard GUI (8x8). I have programmed a checkers Engine in Java and would like to test my engine against a variety of opponents using the CheckerBoard Match-functionality. However, how can I communicate with CheckerBoard having my engine programmed in Java ? On the offical site it say's that I have to implement a couple of function and basically make my engine a dll. Is there any workaround for that, since I am using Java ? if not is there any UCI-CheckersGUI which I would find much easier to deal with.

Thanks a lot.

:wink:

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

Re: Protocols and tools

Post by Ed Gilbert » Mon Nov 14, 2016 14:38

The only way to interface an engine with CheckerBoard is with a .dll. I am not aware of another checkers GUI that has a more UCI-like interface. You could write a bridge .dll in C to connect CB to your program. You could also modify CB to interface to your engine through some other protocol, although that is probably a lot more work. The CB source code is at GitHub. Here's a link to the branch that is currently active: https://github.com/eygilbert/CheckerBoa ... ental_time

-- Ed


Krzysztof Grzelak
Posts: 705
Joined: Thu Jun 20, 2013 17:16
Real name: Krzysztof Grzelak

Re: Protocols and tools

Post by Krzysztof Grzelak » Mon Apr 17, 2017 12:47

Rein or You can use the program cutechess-cli 0.9.4 to run tournaments in international draughts programs.

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

Re: Protocols and tools

Post by BertTuyt » Mon Apr 17, 2017 14:15

The Damage GUI has now an embryonic implementation for Tournaments.
Hope that we can agree upon a standard protocol (see other posts in this forum) anytime soon.
So far I used a hubbish implementation and at least it works for a 4 engines tournamant (i cloned Scan 4 times, with different naming).

Below a screenshot for a tournament in progress between 2 identical versions of Scan (one with a 24 ply search, and the other with a 22 ply search).
ScanScan Tournament.PNG
ScanScan Tournament.PNG (29.58 KiB) Viewed 5020 times
The match is a 1 round match, where in every round 79 * 2 games are played , (with alternate colours), based upon a 2-move ballot FEN file as input.
The arbiter is based upon the DB-handler and DB-files from Ed.
The tournament has an option that the arbiter stops the game, when a decisieve endgame positon is detected.
One can change the setting from no arbiter towards 6P - 7P or 8P.

Bert

Krzysztof Grzelak
Posts: 705
Joined: Thu Jun 20, 2013 17:16
Real name: Krzysztof Grzelak

Re: Protocols and tools

Post by Krzysztof Grzelak » Mon Apr 17, 2017 14:42

Very cool thing - this tournament manager. Only the school that so few programs can participate in the tournament.

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

Re: Protocols and tools

Post by BertTuyt » Mon Apr 17, 2017 14:54

In a previous post I explained the hubbish protocol implementation.
But I agree with Fabien that it is extremely embryonic.

On the other hand the simplicity (based upon pipes not TCP-IP) makes it very easy to implement.

I gues that the for the next programs (who have implemented Hub, Guide or DXP) it is a few days work maximal.
So Dragon, Horizon, Kingsrow, MobyDam, Scan, Sjende Blyn, and Tornado, to name a few.

Some programmers are not active anymore like Adri for Flits and Stef for Truus, here we could rely on a wrapper (which Ed and I also have done in the past).

Think with this list you can already start (complete automatic) an interesting Tournament.

Bert

Krzysztof Grzelak
Posts: 705
Joined: Thu Jun 20, 2013 17:16
Real name: Krzysztof Grzelak

Re: Protocols and tools

Post by Krzysztof Grzelak » Mon Apr 17, 2017 15:18

I will write more Bert. It would be fascinating.

Fabien Letouzey
Posts: 283
Joined: Tue Jul 07, 2015 07:48
Real name: Fabien Letouzey

Re: Protocols and tools

Post by Fabien Letouzey » Sat Apr 22, 2017 08:34

Hi all,

Note that I'm not actually answering anyone in particular. Last time I just wanted to add a post here and instead a new thread was created; sorry about that.

Warning, long and technical discussion of protocols ahead. People who are not interested can safely skip the whole post!

First I would like to summarise some past events. In 2015 I introduced a protocol that I call Hub in both Scan and the Hub GUI I use in tournaments. I recently described this protocol as Hub-1. Meanwhile, Bert used a slightly modified one that he called UDI. I got confused by the name and thought that he meant UCI with a few draughts-specific changes. I just want to say here that all is fine, including the UDI name; we can now move forward.

I look at Hub-1 and I think that it's not so bad, and therefore a good basis for something more solid. That is of course subjective. A very superficial overview is that there is an engine-initialisation phase at the beginning, and the rest is only a sequence of searches. To try to explain this philosophy (which originates from UCI) in terms of programming, I would say that the engine is seen as a module, and the protocol is its interface. The term GUI is used loosely and actually means any tool that can connect to an engine. It is often a user-facing GUI, but can also be a tournament manager, an adapter that translates to a different protocol or adds some functionality, a testing tool for programmers, etc ...

The main problem of Hub-1 is that it is not extensible. What I mean is: if we add features, we also have to change all the software that uses it. Ideally what we want instead is: if we add features, old software just ignores them and hopefully keeps working. I have a proposal that goes in that direction. I'm not claiming 100% magic here, as I'm not sure it is possible to be fully extensible, but something much better than the current state.

But a change is a change and will require updating existing code. So in this post I want to describe the main idea, and wait for feedback regarding potential interest. If for instance Bert gives me a green light (since he has written code that uses Hub), we are in business.

There are two aspects in Hub-1 that require changes before it's too late:
- important features like more detailed engine parameters and search information
- extensibility
It just so happens that one, but admittedly big, change in syntax allows both. In programming languages (PLs) it is called "named parameters" (as opposed to the more common positional parameters). Staying with the PL metaphor, you write f(x=2, y=3) instead of f(2, 3). This allows a lot of goodies like default values, flexible ordering, and extending the parameter list later. It is also arguably more readable, especially for long lists.

Back to protocols; UCI already has named parameters, like in this example:

Code: Select all

info score cp 20 depth 3 nodes 423 time 15 pv f1c4 g8f6 b1c3
I claim that this is not enough, however. It's difficult to parse (at least for the GUI) and, maybe surprisingly, not extensible. The reason is that UCI syntax is based on keywords. To separate the keywords (names) from the values, you have to know all the keywords in advance. Anything that is between two keywords is a value. But recall that a value can be empty (for flags) or contain spaces (like the PV). If later you try adding a keyword, existing software can break down.

There is an obvious solution: quoting, and that's what I'm proposing here. In the example above, "cp 20" and the PV would be quoted. Atomic values can be quoted too, it's just not required. With quoting, all the values become self-contained and there is a strict alternation between keywords and values (at least if we replace all the positional parameters). For machines this will work, but it's still somewhat unclear for humans without knowing the keywords. So I recommend something extra like "name=value" pairs, and just "name" for flags. A literal conversion of the UCI example would be:

Code: Select all

info score="cp 20" depth=3 nodes=423 time=15 pv="f1c4 g8f6 b1c3"
I don't have any strong preference between "=" and ":", whether to add spaces, or whether to add commas. We could even take insiration from command-line arguments, which originally had the same problem to solve.

So here is my plan:
- start from Hub-1
- redefine the syntax using quoting and name/value pairs (probably everywhere)
- add more detailed engine parameters and search information
There are a lot of other details that need thinking about, and I welcome such discussion. But what I've described here is the essence.

Now, let's not forget the drawbacks. Additionally to having to update existing code, it would be more difficult to parse than what we've got. Still only "INI file" level though; I'm not talking about parsing C++ here!

So, what do you think?

Last-minute paragraph. I'm just realising that maybe some programmers don't want to be involved in protocol details and see such discussion as too low level; that's perfectly fine. In this post I wanted to justify the changes that I'm proposing, because of the consequences. I can also go all the way to a full proposal by myself that programmers can choose to implement or not. In that case I just need an indication that at least one person is interested before I go further.

Thanks for reading,

Fabien.

Fabien Letouzey
Posts: 283
Joined: Tue Jul 07, 2015 07:48
Real name: Fabien Letouzey

Re: Protocols and tools

Post by Fabien Letouzey » Sun Apr 30, 2017 19:39

Hi all,

Here I just wanted to show some examples of Hub-2 syntax. This is not a formal presentation of the protocol, which is not yet fully defined.

In spirit, the protocol is the same as Hub-1; only the syntax differs. All lines (both from and to the engine) have the form:
<command> <arg>=<val> <arg>=<val> ...
possibly with 0 arguments. Values can be quoted. It is in fact required if they contain a special character (such as a space or '=') or are empty.

I argued earlier that, once this syntax is used, it becomes possible to extend the protocol later without breaking existing software. It's very informal and not legally binding, but certainly better than the current protocols, including UCI.

---

For initialisation, the GUI sends something like this:
hub
set name=variant value=killer
...
init

And for a search:
pos pos=Wbbbbbbbbbbbbbbbbbbbbeeeeeeeeeewwwwwwwwwwwwwwwwwwww moves="31-26 20-25 34-30 25x34x30 39x30x34 14-20 44-39 18-23 49-44 12-18 30-25 19-24 25x14x20 10x19x14 36-31 7-12 40-34 4-10"
level time=60 inc=3
go think

Position information is much more UCI-like than before, with the move list on the same line. (Nearly) arbitrary change: the side to move is now in upper case, like in DXP. Contrary to Hub-1, time is in seconds and can include a fractional part.

Other possibilities for "level":
level moves=75 time=300
level time=300
level move-time=1
level depth=5

You just send what makes sense, in any order; no need to fill unused arguments with zeroes.

Or for search:
go ponder
go analyze

In my programs I use British spelling, but American is customary for protocols. Later, we can imagine "go perft", etc ...

---

The engine "greeting" (answer to the "hub" command) looks like this:
id name=Scan version=X author="Fabien Letouzey" country=France
param name=variant value=normal type=enum values="normal killer breakthrough"
param name=book value=true type=bool
param name=threads value=1 type=int min=1 max=16
...
wait

"id" is now all in one line. Separating engine name and version is arbitrary; I hope that it can help the GUI in some ambiguous cases (spaces in both the engine name and version). The engine-parameter list is UCI-like. The "type" stuff is imaginary for now, as my GUI doesn't display engine parameters. I propose to use programming terms instead of widget names like "combo box".

Search information is also very UCI-like:
...
info depth=18 mean-depth=19.2 score=0.00 nodes=5385538 time=1.576 nps=3.4 pv="32-28 23x32x28 37x28x32 10-14 41-37 17-22 28x17x22 11x22x17 33-29 24x33x29 39x17x22x33 12x21x17 26x17x21 2-7 44-39 7-11 45-40 11x22x17 46-41 5-10 41-36 6-11 31-26 8-12 34-30"
done move=32-28 ponder=23x32x28

Values can contain a decimal point: score is in "men" instead of cp, time is in seconds, speed in MNPS. Note the quotes around the PV, since it contains spaces. Engines can send any information deemed useful; we can agree on standard names for the most common concepts. The GUI is free to display any subset.

"done" marks the end of a search. Sometimes there will be no "move", like in perft. This avoids the awkward "bestmove 0000" in UCI. Later, new information can be added like "resign" or "offer-draw".

---

Now for my experience implementing this. It was more work than before (with only positional arguments). I wrote a separate lexer module in both Scan and the Hub GUI. The rest is as simple as before. All in all, I think that the flexibility and informal "future-proof-ness" are worth the extra work.

Comments welcome,

Fabien.

Post Reply