I’ve been thinking about a solution to a lot of problems no one is having
I’ve seen interest in fuzzy stone placement, apparently we have looked into adding this but it was not as straight forward as would seem
I’ve seen interest in eliminating opponent rank display, last move display, ECT ECT…
Personally I’d prefer to play on a perspective board as one sees it sitting on the table.
All of these problems have finished solutions, if we could only talk to them?
How about an OGS GTP bridge application? It would be used as a stand alone application to handle browsing and finding games that would then launch whatever GTP client while handle communication between OGS API and the gtp commands playing the game out on the client.
This would make it possible to play games on OGS with sabaki, glgo, or any other client you may have grown fondness for.
While there is not much work being done on it now, this would also be extensible later for projects such as the physical goban interface for OGS some have pondered building.
I think most of the things you describe are purely front-end, so with or without a bridge application, someone has to write the code for it. They might as well write it for the OGS site itself then and submit it to the Github right?
I’m not sure if GTP would be a better or worse way, but it should be noted that OGS already has some sort of open API that supports playing games via other clients (although I know very little about it beyond that it exists).
In fact, there is already an ongoing effort to develop a mobile app that uses this API:
Most of the things are front end, but I am proposing 1 solution to many problems. Sure someone could write the code to copy one feature or another.
But what if, 1 time instead of trying to code and recode OGS to look/act like out favorite client… We just used our favorite client?
The way I see it using the go text protocol to extend the interface in open and standard ways certainly has an advantage to endless frontend work valid in only 1 situation.
I think GTP is primarily designed to facilitate the interaction between a bot and a client (for the bot to play against a human using the client), or between a bot and a go server (for the bot to play against humans via the server). It might be less suitable for the interaction between the server and client software (for the purpose of allowing a human to use the go server via the client).
The existing OGS API might be better suited for interfacing a client to the OGS server. Other key things like finding and arranging games seems to be outside of the scope of GTP.
Edit: I reread your original post, and I think I now better understand what you mean. You’re proposing a program that acts as a sort of intermediary that interfaces with OGS for finding games, etc., but then provides a GTP interface that various end-user clients could connect to. Basically, software that makes the OGS server look like GTP bot for whatever client GUI the end user wants to use?
I think this is a neat idea, but there might be some difficulties surrounding two issues:
Time Control: GTP assigns the client as the master for keeping time, but in this application, the server (acting as a bot) would have to provide the official time control information to the client somehow.
Status/Scoring: marking dead stones is key to the scoring procedure on OGS, but GTP does not seems to support a method to tell the bot (server) which stones should be marked as dead/alive.
Maybe both of these issues would have to be handled by the bridge application directly, i.e., the bridge software displays the time controls (in a window separate from the client), and the user has to switch back to the bridge application to perform scoring.
However let us not get too caught up in bots.
Go Text Protocol is a replacement for Go Modem Protocol and has been used for one computer or program to send information about a go game to another computer/program.
This in and of itself has nothing to do with bots. However, if you ARE a bot who plays go, the standard computer go langue is a good thing for you to speak
But yes this would allow you to load the program and make a game request or otherwise manage challenges, and when it came time to open a go board it would open the client of your choosing and speak to that client I’m GTP.
Essentially, you would load this theoretical OGS-GTP bridge and make a game request. It would handle the OGS API calls and then open Sabaki, and you could play out your game in sabaki. It would stay running in the background as a translator between the OGS server and the standard go text protocol used by generic clients, allowing anyone who chose to do so to play OGS games on any client that supports GTP (most).
This would also pave the way for other projects, such as a hardware interface. Either purchased or DIY electric gonbans (not at all common) will typically support play through GTP as well.
The current gtp2ogs is very close, but designed for bots so I do not think it supports everything we would be looking for. If I continue to move forward it will likely be a good resource however.
