Yes, that is exactly right.
I made several half-hearted attempts in the past (more than 15 years ago) and I have followed developments in computer go somewhat before AlphaGo. I also read parts of a book on how to make a go AI (Deep Learning and the Game of Go).
So I know something about go engines (and chess engines), but most of it is rather superficial. I’m far from an expert.
Hmm but it’s not quite an AI I need to build but a program that waits for user input from the board. Do you recall any resources that explain how that works?
Is a potential purpose of this hardware to allow two players to play over this board, while the game is recorded by a computer, while moves validated and captures indicated?
It seems like this hardware should instead be viewed as an alternative front-end interface that you might want to attach to Sabaki, rather than like something that would appear like a pseudo-AI engine connecting via GTP.
Yes this is exactly correct.
Though attaching an alternative frontend to Sabaki is tougher than I thought. I tried deciphering the source code but couldn’t quite get how Sabaki takes the frontend mouse click event into a stone placing event… Would appreciate if anyone familiar with Javascript and electron can give me some tips how to make sense of the codes.
Have you checked out this library yet?
It is also provided by the Sabaki developer and seems to be a Javascript module that appears helpful for what you want to do.
Yeah I did I actually included that in my code. I probably should look back into it. The board doesn’t have the nice frontend board display which is in the other module but that one probably requires more modules to work properly. I decided to look into gtp communicating with Sabaki because I want to take advantage of the nice frontend display of the board status. If I can get gtp communication to work then I can benefit from Sabaki’s own code upgrade.
I think I misunderstood you when you said go engine. I thought you meant a bot, but perhaps you meant gtp engine.
I did make gtp engines. It is not that difficult. You were already able to communicate board moves to OGS, which may be harder to make.
I’m sorry but I have to work now.
Yeah gtp engine is what I want to make. I was following this tutorial series
but want to implement the engine in a different language because I feel Python library might be a mess with applying the engine in Sabaki.
I wrote a simpler version of the tutorial code and got it to work. However, I couldn’t do the same for Javascript and Golang for some reason.
Sabaki showed connection failed for Javascript and never finish connecting for Golang.
And I really appreciate your help and response! Work is obviously more important 
Would the GTP protocol be suitable for a situation with two players playing over the board on the hardware?
I thought that GTP was mainly suited for situations where one player (i.e., the human user) is playing via the client (e.g., Sabaki’s interface), while another player (i.e., the AI engine) is serving moves in response to the client via GTP.
I just realized that you are right. We normally connect the gtp engine to either black or white stone. If I connect both colours to the same engine I would need to make sure the process that waits for human input send their move signal to the right colour. I haven’t been able to imagine how I would do that. Actually one way I can think of is for my gtp engine program to spawn three processes, one waiting for human input, the other two handling the gtp engine attached in Sabaki. I will then control which engine each move is being sent to… Sounds complicated 
I think 1 gtp engine can serve both players, if Sabaki is configured to do that. After all, you can use Sabaki to watch a game of KataGo as black vs KataGo as white. Although I haven’t used Sabaki that much, I think this is quite possible with GoGui gtp client.
One thing though: I suppose Sabaki also maintains a board/game state internally. So be sure that your physical go board matches your gtp engine’s internal board/game state and also Sabaki’s, including the rule set that the game is played under. I don’t know what happens when a gtp engine returns a move that is illegal according to Sabaki (or some other gtp client).
So perhaps your should decide which rule sets your gtp engine supports and perhaps check that this coincides with Sabaki’s implementations of those rule sets. Rule sets may differ on suicide and (super)ko and also on scoring a finished game (if scoring is part of your setup).
That is true. I can attach the same engine to both colours. I guess that tricky would then be how should the project software knows which engine to send the coordinate data to. I still need to figure out whether that is possible XD
I haven’t considered the rule set portion yet but I’ll keep that in mind. Once I know that connecting the board and Sabaki through gtp is possible I will start looking into implement the actual program.
Which language did you implement your gtp engine with??
In C#, my goto language for the past 20 years (before that it was C++).
I don’t know how your project software works, but I imagine the sequence of events during regular gameplay to be something like portrayed in this Sequence Diagram
(I made some assumptions on how everything to the right of the gtp engine works)
Yes this is precisely how it should work. The current version of the software receives the data from Arduino and that’s it. It doesn’t know about two gtp engines and how one colour should go to one engine.
Would you be okay with sharing the codes you wrote for the gtp engine in the past? I want to see another working example not written in Python if possible.
I still think that 1 gtp engine is enough (as in my diagram). Can’t sabaki just ask the same gtp engine instance to generate moves for both colors?
I don’t know if I can find it quickly, but here is the source code of Pachi (not written by me), an older AI (including gtp engine) written in c it seems:
