Could littlego merge a stronger GTP bot, e.g. KataGo?

[HackYardo]

After AlphaGo & Lee Sedol event 2016, many free, open-source and strong bots, e.g. KataGo, LeelaZero, SAI, etc, were created and can be used on desktops. But they can't be used on mobile devices until BadukAI, one free Android app. Until now, there is no free IOS app to play with strong bots.

[herzbube]

In theory it is possible. Exchanging the Go engine that provides the computer player was a design goal from the beginning, so the code is structured in a way that decouples the main application from the Go engine. The two things communicate with each other via GTP protocol over in-memory pipes.

In practice it would still mean substantial work, notably

• Verify that the new Go engine has a license that lets it be distributed via Apple‘s App Store. GPL is out, for instance. LGPL is borderline and needs permission to use from the authors (Fuego uses the LGPL). Apache 2.0 and BSD licenses should be ok.
• Verify that the new Go engine can run inside a host process. iOS apps cannot launch operating system processes, so the new engine must be able to run as a set of threads within the Little Go app process.
• Verify that the new Go engine can be compiled into a static library. iOS apps cannot dynamically load libraries, so it must be possible to statically link the new engine’s code into the Little Go executable.
• Find a way how to communicate with the new Go engine via GTP. Even Fuego had to be patched to allow this, so I doubt that another Go engine would support the same mechanism out of the box.
• Find substitutes in the new Go engine for a number of Fuego-specific GTP commands that Little Go uses to achieve its functionality.
• Extensive research has gone into how Fuego performs on iOS devices, specifically how much memory it consumes. This research woukd need to be repeated to some extent for a new Go engine.
• Configuration of the computer player is geared towards Fuego and the configuration options it provides. The corresponding parts of the UI and the in-game manual would need to be rewritten.

These are just the things that pop into my head immediately. There may be other stuff to do as well, which I can’t think of right now.

[herzbube]

After the previous technically oriented comment, let me also say something about the bigger picture I see.

While it might be cool, technically, to have one of these nice and shiny new Go engines integrated into Little Go, I currently don‘t see the value for the average user who just wants to play a game of Go. Fuego is already strong enough to beat most people - which by the way has drawn quite a few negative App Store reviews - so increased playing strength in my opinion is not a good argument for integrating a new Go engine. A good argument for me would be if it uses less memory and/or CPU than Fuego.

Apart from the basic decision whether or not to integrate a new Go engine, there is also the question of priorities. There are already so many good ideas how to improve Little Go in other areas that a new Go engine has a very low priority in my mind.

Having said all this, I leave this issue open for further discussion.

[HackYardo]

Thanks for open & further.

• Actually, strong bots after 2016 supply not only strength but also analytic features, e.g. suggesting moves series instead of single moves.
• On the other hand, the strength can be adjusted widely by changing "models" or "visits".
• And from my experience, there is a "painted egg" if you play with a weak model of a strong bot: players could fairly understand the bots' aims through their moves.
• For developers, one could write less codes with strong bots, e.g. ready-made rulesets from engines' GTP extend commands instead of writing rulesets from zero.

[herzbube]

Thanks for this information. I'm currently busy adding features to display/edit more SGF data, so a new Go engine certainly won't be on the menu for the next release. Maybe I'll spend some time on research after the next release, but no promise :-).

Meanwhile here's a bit of information about the engines you mentioned. This is just from a quick research, if you have more information feel free to add further comments.

• KataGo: Website link, GitHub link, written in C++ (requires C++14), the license (document link) for the main code seems to be MIT. Excellent :-)
• LeelaZero: Website link, GitHub link, written in C++ (requires C++14), the license according to the GitHub README is GPLv3, so this engine unfortunately has to be ruled out.
• SAI (forked from LeelaZero): Website link, GitHub link, written in C++, the license according to the GitHub README is GPLv3, so this engine unfortunately has to be ruled out.

[herzbube]

KataGo notes, after installing it via Homebrew on my macOS machine:

• Command line to start after installing v1.10.0: katago gtp -config /usr/local/Cellar/katago/1.10.0/share/katago/configs/gtp_example.cfg -model /usr/local/Cellar/katago/1.10.0/share/katago/g170-b30c320x2-s4824661760-d1229536699.bin.gz
• Launching the program for the first time takes substantial time during which some tuning is done to match the local graphics hardware. The result is saved to a file in the user's home directory (~/.katago/opencltuning/tune8_gpuAMDRadeonPro560ComputeEngine_x19_y19_c320_mv8.txt). When the program is started the next time it automatically finds the saved tuning parameters.
  • In iOS, saving tuning parameters to the user's home directory is not allowed because this is outside the app sandbox. A way must be found to specify to KataGo a custom location where to save/load the tuning file.
  • The app needs to encapsulate the tuning process into a nice UI.

[HackYardo]

It looks like you are not familiar with "the Go in the post-AlphaGo era". Roughly for short: bot	milestone	year
AlphaGo	defeat human	2016
LeelaZero	make "AlphaGo" available	2018
KataGo	make "LeelaZero" adjustable	2020

These advances not only make sense in science and Go itself but also in every Go player's daily games. In my view, an app is a set of features. If one wants to develop a new GUI or undate an old GUI, he or she will choose KataGo for more adjustable features for sure.

[herzbube]

It looks like you are not familiar with "the Go in the post-AlphaGo era".

You are 100% right there 😀. I freely admit that I do not even have any specialist know-how about the algorithms that drive a computer Go engine. My main function as the author of Little Go is to package a Go engine into an iOS app and write a (hopefully) nice user interface for it.

[HackYardo]

For someone, who has experience in developing GoTextProtocol and SmartGameFormat, wants to develop KataGo, here are required documents:

• Run KataGo GTP Mode: path/to/katago.exe gtp -model path/to/<NEURALNET>.bin.gz -config path/to/gtp_custom.cfg
• KataGo GTP Mode Configuration
• KataGo GTP Commands Extension

[herzbube]

Issue #401 is an incentive to switch from Fuego to KataGo (assuming that KataGo supports the SGF feature of board setup on a non-empty board).