Re: Backgammon API

[Øystein Schønning-Johansen]

I've been thinking of a backgammon protocol the whole day now. Here are some of my viewpoints.

As Guido says, both UCI and xboard are terrible, and I think they have some weaknesses, yes. It is really hard to define a perfect protocol and it cannot be perfect on the first attempt anyway. I think it is important that we find the right balance. We don't want too much done in the GUI and we don't want too much at the engine side either. I think the state of a match can be handled by the GUI. The engine should hence be "stateless" and able to answer to the following commands:

evaluate 

find_best_cube_action

find_best_move

rollout_move
rollout_cube

In addition there should be some options exchanging keywords and some handshaking and initialisation instructions. The options description can be defined better later, but make sure that engine takes care of how to find moves and evaluate at different settings. I strongly believe that such things should be handled by the engine and not the GUI.

I actually disagree with Guido when it comes to raw sockets. I think raw sockets are good. With raw sockets a engine programmer can just write directly to stdout and never even think of XML, JSON, Protobuf, or what ever next will be the retired data exchange format. It works fine over ssh and it is easy for an engine developer to debug.

-Øystein

tir. 14. nov. 2023 kl. 08:46 skrev Guido Flohr <guido.flohr@cantanea.com>:

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