Re: Backgammon API

[Lasse Hjorth Madsen]

Hi Carsten,

I think this is exciting. I'm a data scientist, not a software developer, so I don't have a deep understanding of all the implications

of choices of technology. But to me the approach you describe sounds absolutely right.

Thanks,

Lasse

man. 13. nov. 2023 kl. 21.23 skrev Carsten Wenderdel <chrisforen@outlook.de>:

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