I'd suggest MCL but unless it is a luaAI it won't be easy even to order your first unit.
It's fairly trivial for game developers to give standalone AI access to all and any interesting game rules commands they want. As a proof of concept, before i started on ZKGBAI, i was able to teach Shard to use ZK's retreat haven functionality.
(sending SkirmishAIMessages from Java was a bit harder back then, so i ended up reimplementing it later anyway; the situation has changed since then though)
Now, game recommendations. ZK lobby server is supported by two lobbies except ZKL itself, that is SWL and flobby. Both run on linux flawlessly.
I'm very interested in having another AI to play ZK for selfish reasons (enemies! we need enemies!), so i'm going to let the bias overtake me and suggest ZK.
A piece of funfact/trivia: the #ai channel is bridged between ZKLS and spring's Uberserver. If you want any help with peculiarities of the interface or the game you pick, that's the place.
An "arms race" of AIs, each trying to become better than the others - it's certainly been working in evolution - microbes vs microbes; cheetas vs antilopes; axis vs allies; usa vs soviet union; etc.
More trivia: that's basically the story of zkgbai/freundAI/CSI. At some point the first two were developed at the same time, with incremental tests each friday. This kind of 'adversarial collaborative developement' really works.
What you could do is package your lua ai as a separate archive that games can call as a dependency. That way you can hook the repo up with rapid and make ai changes on the fly, independent of anything.
This is not accurate. Spring modules depend on
specific versions of other modules, so, say, if ZK makes "forbAI" its dependency, that will still tie forbAI's release schedule to that of ZK. Since LuaAI's are synchronous, that also means no distribution is possible without releasing a new game version
for anyone - you won't even be able to host your AI to play against others, unless they all download the game which depends on the new version of the AI.
A non-lua ai must be compiled every time something in the ai interface changes (which is literally always).
Wrong on both counts. A naked C or C++ ai will likely have to be recompiled if the interface changes, but 1) it actually does not always change "always" 2) sufficiently mature AI's are usually added as submodules of Spring itself and are compiled by robots. Java AI's use the interface wrapper which exposes java classes. The interface wrapper is recompiled with each build and shipped with spring itself. The classes, though, don't change, so you don't have to care.
Here's a quick sanity check wrt LuaAI's: is there a precedent of a LuaAI existing in spring which is not a part of the game itself? Yes, that's a tautology. No, Shard is not such an AI, since it uses the C interface. No, CRAIG is not such an AI either: it cannot be distributed separately, and the games which use it don't even bother keeping it in a submodule!