Hi Guido, Thanks for your feedback.
> In chess, you have two competing protocols, UCI and XBoard/WinBoard. > > ... > Stateless vs. stateful: I’m not very familiar with XBoard. But UCI has both > approaches. You can specify the current position with one string (FEN, > Forsyth-Edwards Notation) or you can pass a starting position and then all > following moves that lead to the current position. In practice, everybody > uses the second approach but this is specific to chess with its three-fold > repetition rule. That rule can only be honoured when the engine knows all > previous positions. That makes perfect sense, thanks for the info. > > Separate protocol for UI connection and connection to servers and tournament > managers? Why? Both chess protocol are used for both purposes. And no chess > engine that I know can play directly against another engine. They all need a > separate application (cutechess-cli, fastchess, BanksiaGUI, …) that connects > them. For connection to a servier, there are a couple of Python programs that > can run bots. Uups, I thought it would be dead easy to select from several AIs for Player1/2 (as it is in BGBlitz. Ok right now only 3 versions of TachiAI and GnuBG only if installed) In our case I think we have several levels that should be IMHO supported: - you have bots that make only moves and have no cube abilities. Here it is enough to present the state of the board and get back the best move. This would enable even pubeval and on Fibs you have several bots that play only 1-pt matches. This is sufficient for bot-vs-bot scenarios but not enough as a BestMoves/Evaluation/Rollout/analysis-replacement. - the bots delivers equities for every situation. Then you can use it for bot-vs-bot play and you can also use it as a complete replacement - Alex Strehls bg-engine is a bit in between because it supports cube decisions, but only for unlimited games. I think it is not much additional effort to support it as well (allowing 1-pt matches and unlimited games) > I also don’t think that a stateless protocol is significantly faster. Even > with pipes or unix domain sockets, the I/O will probably be more expensive > than the parsing. Always passing the entire game history has the additional > advantage that an engine could also give estimates for luck and skill. I disagree for two reasons: - One could expect luck and skill, match analyses and rollouts as well, but this would increase the complexity of the API by a huge amount. Just imagine how complex the datas structure for a match analysis are. The smaller the interface the better the chance that there are implementations. IMHO just two calls are needed: — evaluation i.e. give the position and give back the cube decision or the best moves if the dice are set — optionally an initialization - different to chess (?) it might be neccessary to call the AI very frequently, e.g. the move alternatives like this ( https://bgblitz.com/images/MoveRollAnalysis_Overview.png ) needs 70 calls. A market-looser analysis needs 1296 calls( maybe twice as much) so I think it is a good idea to make the serialization fast at least for the complete replacement and an argument for being stateless. > I think that the serialisation format doesn’t have to be part of the core > protocol. It is easy to support multiple formats. Honestly, I don’t think > that the mini payloads that a backgammon protocol requires, make protocol > buffers the preferred choice. I agree that the communication channel (stdin/stdout, sockets, ..) should be configurable as well as the encoding. JSON would be an obvious choice because every language could support it. For greater speed I looked yesterday at: - Protocol Buffers - Fast Buffers - Apache Fory - Smile My opinion so far: - Protocol Buffers is battle proved, available for many languages, pretty fast. Needs copy to/from transfer objects. FastBuffers avoid this, but not too relevant here. - FastBuffers is a bit more complex and has it advantages with larger payloads - Apache Fory is fast, dead easy to use from Java (no transport objects, just register your classes) and other OO-languages but has only a C++ and no C-interface. - Smile I used Smile already to save Matches and it is very easy to switch from binary to text. Less efficient but it might be less work to to support JSON and SMile instead of JSON and one of the others. Right now I only dislike FastBuffers. due to a mistype I just stumbled over FlatBuffers which at the first glance seems attractive as well and has a C interface. I’ll look at it later. To make a plugin easy to use for IT-laymen I think unzipping it and copy&paste the configuration file out of the unzipped folder is easy enough for most people. And the host of the plugins must made aware of the existence of the plugin anyway so you could put in here some additional information as well and don’t need to do it at startup. You can see my ideas so far here: https://www.bgblitz.com/download/Doc/plugin.md Something that is different to chess as well(?): when used as a full replacement in a human-vs-bot match I use not one AI instance, but when you open a bestMoves window another instance is needed. The Tutor and the analyser rund in the background as well and need instances. For GnuBG I solved it by having a pool of instances in the background (to create a TachiAI instance is dead easy because all expensive stuff is shared; creating a process is not neglectable) but there might be better ideas (e.g. having an id in the request etc. but this adds burden on the AI developer). I thought such an API will be help only for creating new AIs but I think a slim UI with fresh ideas is doable as well and if you are good at UI-design you’ll benefit by not havinf to write an AI. ciao Frank
