Backgammon API

[Carsten Wenderdel]

Hello,

in the past there have been several attempts to separate the engine part of 
GnuBG from the GUI. Two examples:

https://github.com/alcacoop/libgnubg-android
https://github.com/hwatheod/gnubg-web

Both attempts had a very specific goal in mind and were not continued.

In chess there is UCI, an interface understood by virtually all engines, bots 
and GUIs. Wouldn’t it be great if we had something similar for backgammon? 
Someone could write a new engine or GUI without worrying too much about the 
other. If someone wanted to create a JavaScript or Flutter GUI on top of GnuBG, 
it would be possible.

Such an API can’t exclusively be a C API. There are GUIs and bots written in 
other programming languages. Also it should easily work if both parts are 
closed source and distributed independently.

In chess UCI uses standard input and output. I believe a modern interpretation 
should be based on web technologies.
While protobuf is faster than JSON, a combination of HTTP and JSON is widely 
supported by programming languages and libraries.
If we find the right spot where to split engine and GUI, a few milliseconds 
more or less are not crucial.

Not all engines might use neural networks and be able to calculate winning 
probabilities. So maybe also a basic version of the API should be taken into 
consideration. For game play there are only two questions that need to be asked 
by the client and answered by the engine:
1. Given a certain position and dice (and state of the match, cube, etc.): What 
is the correct move?
2. Given a certain position (and state of the match, cube, etc.): What is the 
correct cube action?

I found one project where someone has ported GnuBG to the Go programming 
language and used HTTP and JSON for an API:
https://github.com/foochu/bgweb-api
The README of this project also has some examples how the API looks like.

For my project wildbg (https://github.com/carsten-wenderdel/wildbg) I slightly 
changed that API. Mainly I removed some information and changed POST to GET 
requests.
So if from the starting position 3 and 1 are rolled, this is how the request 
would look like:
https://wildbg.shuttleapp.rs/move?die1=3&die2=1&p1=-2&p6=5&p8=3&p12=-5&p13=5&p17=-3&p19=-5&p24=2

Have a look at the URL, it’s already deployed and working.
For more documentation around it, see
https://wildbg.shuttleapp.rs/swagger-ui

All this is completely stateless. So the engine does not need to remember 
anything, every request would carry all the information needed.

Currently missing: More HTTP parameters describing state of the match, 
Crawford, desired strength of the engine etc.

Also missing are rollouts. For that I imagine a POST request. Immediately 
returned would not be the result of the rollout but instead an ID. With this ID 
the status of the rollout could be queried and potentially also the rollout be 
canceled.

In general, responsibilities could be split like that:

Engine
- Evaluation of positions, not only 0-ply, but also 1, 2 or 3 ply.
- Rollouts

Client:
- Keeping track of the match state
- Match analysis
- Calculation of ELO or performance rating

I’ve already contacted Frank Berger, the author of BGBlitz. He might be 
interested in implementing such an API in BGBlitz, so other engines could use 
the GUI of BGBlitz.

What do you think? Would this be interesting for GnuBG?

Best, Carsten

ps: For discussions about computer backgammon (not only GnuBG) I’ve created a 
Discord server. So if you are interested in this topic or others, consider 
joining there: https://discord.gg/Ckvf7y8nGz