Hi Carsten,
>> What do you think? Would this be interesting for GnuBG?
Just to say, YES - I don't know much about low-level coding but, as a QA Analyst, I do have some experience of Swagger docs and API calls / testing / scripting with Postman and how VERY useful APIs are.
If I am understanding this topic correctly, I think standardizing APIs across programs could be extremely useful in programmatically creating / manipulating / interrogating backgammon positions / running automatic Bot vs Bot tournaments etc
I've joined your Discord as interested in further developments.
Please feel free to let me know if you would like me to assist with some high level testing of your API
Kind regards,
Wayne
Send Bug-gnubg mailing list submissions to
bug-gnubg@gnu.org
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.gnu.org/mailman/listinfo/bug-gnubg
or, via email, send a message with subject or body 'help' to
bug-gnubg-request@gnu.org
You can reach the person managing the list at
bug-gnubg-owner@gnu.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Bug-gnubg digest..."
Today's Topics:
1. Backgammon API (Carsten Wenderdel)
2. New backgammon engine: wildbg (Carsten Wenderdel)
3. Re: Backgammon API (Lasse Hjorth Madsen)
4. Re: Backgammon API (Guido Flohr)
----------------------------------------------------------------------
Message: 1
Date: Mon, 13 Nov 2023 20:22:22 +0000
From: Carsten Wenderdel <chrisforen@outlook.de>
To: "bug-gnubg@gnu.org" <bug-gnubg@gnu.org>
Subject: Backgammon API
Message-ID: <8E4009A0-07AF-4C8C-977B-AA854A471CD1@outlook.de>
Content-Type: text/plain; charset="utf-8"
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
------------------------------
Message: 2
Date: Mon, 13 Nov 2023 20:20:39 +0000
From: Carsten Wenderdel <chrisforen@outlook.de>
To: "bug-gnubg@gnu.org" <bug-gnubg@gnu.org>
Subject: New backgammon engine: wildbg
Message-ID: <5300A2C7-34B6-4005-B7C2-F8DC3498393C@outlook.de>
Content-Type: text/plain; charset="utf-8"
Hello,
I’m about to send an email proposing some HTTP API for communicating between backgammon engines and clients like GUIs or bots.
For context, I do some advertisement first.
I have started work on a new backgammon engine: https://github.com/carsten-wenderdel/wildbg
The current strength is roughly 1800 ELO or an error rate mEMG of roughly 7.5 when being analyzed with GnuBG.
So far only the classic TD-Gammon inputs have been implemented, the expert features from Hans Berliner are missing.
It’s also still learning without expert features, so I’m optimistic that there is lots of room for improvement.
You can play against it on FIBS (bot name is wildbg).
If you are interested in particular positions, try out https://wildbg.shuttleapp.rs/swagger-ui/
Wildbg is doing many things similar as GnuBG, which is really a great project.
Some things however are done differently:
1. MIT/Apache 2 instead of GPL
It seams, some commercial apps have copied GnuBG source code and it seems it was not followed up.
On the other hand, legally GPL is not allowed on Apple’s App Store because of license issues, even if the app is free of charge and source code is provided.
Sometimes I have the impression that the GPL is not giving the protection someone would like, but makes it difficult for some honest people.
I don’t want to start a discussion here, but only explain my choice. There are very good reasons for GPL and against MIT too.
2. Rust instead of C
Rust has the features other modern languages like Kotlin or Swift provide which allow high level programming.
At the same time Rust allows very fast code without a tracing garbage collector. This is important when being embedded as a library in another app or in the web (via web assembly).
3. HTTP/json API instead of own GUI
Both engine and GUI are already quite big undertakings. The chess community has always separated those two, I think the backgammon community should too.
4. Usage of 3rd party machine learning libraries instead of self written neural nets
This allows usage of for example PyTorch and the ONNX format. Changing the topology of the nets (ReLu instead of sigmoid, adding hidden layers) becomes very easy.
All these choices are based on opinions, I very much understand if someone disagrees with them.
So my hope is that these choices can grow the number of contributors to computer backgammon.
Some people prefer C, some prefer Rust. Some people prefer GPL, others prefer MIT.
I’d be super happy if wildbg would evolve into a community project similar to GnuBG.
I don’t want to abuse this mailing list too much; if you are interested please join this Discord server:
https://discord.gg/Ckvf7y8nGz
All the best,
Carsten
------------------------------
Message: 3
Date: Tue, 14 Nov 2023 07:02:06 +0100
From: Lasse Hjorth Madsen <lassehjorthmadsen@gmail.com>
To: Carsten Wenderdel <chrisforen@outlook.de>
Cc: "bug-gnubg@gnu.org" <bug-gnubg@gnu.org>
Subject: Re: Backgammon API
Message-ID:
<CAJRJSxj0eYfiLZ7ugzKCh0-dBKXSfyKBg9ZyhXnLKCBAZ1BSaA@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnu.org/archive/html/bug-gnubg/attachments/20231114/b96f8f47/attachment.htm>
------------------------------
Message: 4
Date: Tue, 14 Nov 2023 07:45:38 +0000
From: Guido Flohr <guido.flohr@cantanea.com>
To: Carsten Wenderdel <chrisforen@outlook.de>
Cc: bug-gnubg@gnu.org <bug-gnubg@gnu.org>
Subject: Re: Backgammon API
Message-ID:
<0102018bcccb00d6-6bb37e63-3d7c-4a77-bf8a-1dc9c707496f-000000@eu-west-1.amazonses.com>
Content-Type: text/plain; charset=UTF-8
Hi,
> On 13 Nov 2023, at 21:22, Carsten Wenderdel <chrisforen@outlook.de> wrote:
>
> 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.
I have both implemented UCI and xboard and imho both ”protocols” are terrible. We should learn from their mistakes.
> In chess UCI uses standard input and output. I believe a modern interpretation should be based on web technologies.
Absolutely.
What would really help would be a documentation of the external interface of GNUBG. That should allow anybody with decent knowledge in _javascript_, Python, Perl, you name it to write an adapter that translates GNUBG’s external interface to a new protocol.
For that new protocol, I think it makes sense to look at the FIBS protocol. Of course, I wouldn’t use raw sockets nowadays but a REST API or GraphQL but if board representations, moves, etc. resemble FIBS, it should be easier to modify existing clients to speak the new protocol.
Cheers,
Guido
------------------------------
Subject: Digest Footer
_______________________________________________
Bug-gnubg mailing list
Bug-gnubg@gnu.org
https://lists.gnu.org/mailman/listinfo/bug-gnubg
------------------------------
End of Bug-gnubg Digest, Vol 237, Issue 2
*****************************************