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 <[email protected]>: > Hi, > > > On 13 Nov 2023, at 21:22, Carsten Wenderdel <[email protected]> > 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 > > > >
