Help choosing a "game"

[PauloMorfeo]

Sometime ago (early this year?) I delved lightly into creating a toy AI for Spring. I did it for Kernel Panic and it was load of fun. Now, I want to go deeper into it an really build a proper AI agent - a fully functional and proper player - and I'd like help with choosing a "mod" (game) to focus on.

• Functionally stable - I want to choose a mod that is working well with Spring and has no issues with Linux (I'm only using Linux, nowadays)

I seem to believe that KP is no longer working well due to "code-rot" in Spring, which is a shame. What about Zero-K, EvoRTS, BA, XTA, others?

• Competition or lack of - I'm unsure about this one

On one side, I'd like to have lots of competition. For example, already existing good AIs that I can aim to beat. Maybe even a tournament of AIs could be held. If there' not much in terms of competition, once you have something really simple working it's already "the best there is" and the motivation to make it even better is not so great. The same goes for user base - creating something that can be used by more people is more rewarding.

On the other hand, a mod which is already well served in terms of AI doesn't really need a Yet-Another-AI into the list.

I know that if the user-base is pretty much non-existent nor does it have good competition in terms of rival AIs then that's not appealing to me. But apart from that, I'm kind of unsure which I prefer. Maybe put more simply: is there any mod that has a good user base but is pretty lacking in terms of AIs?

• Simple - I'd prefer the mod/game to be more to the simple side

One of the problems with AI for Spring games is having to deal with a *TON* of different conditions, special scenarios, corner-cases, etc. Ex: even dealing with mines is a very tricky problem that not even human players appear to do well.

KP is pretty cool and would probably qualify as the most simple and easy to catch on but it fails the very first condition and possibly the second one too.

---

Reading this thread in the AI forum:
"Graduate project"
viewtopic.php?f=15&t=33534
Gajop wrote: "ZK side being more popular for AI development recently", not to mention it appears to have a good amount of videos I can learn from (instead of spending tons of hours learning tactics and strategies by trial & failure). Is this true?

What about Evolution RTS, BA and XTA?

Is XTA still played at all? From the lobby it appears to have lost completely its critical mass and faded away.

Why was there almost no mentions of EvoRTS? Is there something "wrong" with it in terms of AI development?

[gajop]

I'd still go for ZK and BA simply because they have the largest player base and most AIs.
This is not to say any of the games you mentioned are bad options, they are just less popular.

[8611z]

Current thread about zero-K AIs http://zero-k.info/Forum/Thread/20484
For deciding between zK and BA maybe also look with which lobby/infrastructure works better for you, especially if you only want Linux.
(since spring and zK are now seperated)
zero-K lobby on Linux is mixed: For some seems to work but also lots of postings about bugs/crashes.
Maybe also look where it is easier to host your AI, by other players too, if that is a goal...then cross-check with goals of zK lobby.

XTA: uses old engine (does not matter for playing but would not use for dev)
was basically one group of players, which does not seem to be so active/online anymore or currently.

Evo: uses even older engine, AIs are automatically given cheats like free resources & other help

Kernel Panic:
Gets mentioned every time in AI discussion despite broken outdated, so maybe worth fixing updating.

bonus round - Conflict Terra:
had one faction that played like a slightly more complex Kernel Panic, which in theory made it good AI game, if it was not dead too.

[Jools]

XTA: uses old engine (does not matter for playing but would not use for dev)
was basically one group of players, which does not seem to be so active/online anymore or currently.

XTA uses 98.0 for now and probably this will be the last supported version for the foreseeable future. While 100+ has some nice improvements, at least I feel I don't have the energy to be pedantic with the code just to fix issues such as these:

[f=0000000] Warning: WeaponDefs: Unknown tag "smokedelay" in "wraith_advmissile"
[f=0000000] Warning: WeaponDefs: Unknown tag "startsmoke" in "wraith_advmissile"

But 98.0 works just as fine as 100.0 does, at least for playing.

[raaar]

you can try to beat metal faction's built-in lua MFAI.

[abma]

you are talking about games! why do you think these are mods? (adjusted the topic)


imo BA should be most stable / is maintained best. afaik also most AIs for BA exist. ZK often sucks on linux, also zk game devs usally don't care much about log warning messages / validation test results, especially spring-headless (which is very important for ai-development imo).

[Forboding Angel]

What about Evolution RTS, BA and XTA?

Why was there almost no mentions of EvoRTS? Is there something "wrong" with it in terms of AI development?

I haven't done a lot with evo lately but that doesn't mean it's dead or anything.

Evo uses 96.0, for a few reasons, one of which is the fact that 96.0 has a wonderful lack of bugs that affect the game. Another large reason is that in 96.+ lua was changed so that all the old stuff has to be updated. Despite by requests for help, no one has bothered to lend me a hand to update the lua to work.

Evo gives ais cheats in order to make them competitive. It currently uses shard which is basically a unit spawner. It's slightly more than that, but yes, follows queues and sends everything it makes in a fight order to your base.

It would be nice to have something slightly more interesting to play against. Also, needs a lua ai. Shard is C++ which causes a lot of distribution issues.

[PauloMorfeo]

Hey guys, thanks for all the replies.

Sooo unfortunate that the content packs just keep getting broken by new versions of the engine. On the other hand, with an overview knowledge of Software Engineering, I do understand that development of changes on a system can end up getting road-blocked and never-evolving to avoid breaking existing stuff.

Current thread about zero-K AIs http://zero-k.info/Forum/Thread/20484 ...

That one was really interesting - nothing like a bit of healthy competition. As I said, it's very appealing to have goals of improvement you can aim at (ex: beat all of those other AIs). 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.

you can try to beat metal faction's built-in lua MFAI.

Wow, new stuff! Had never heard of it. The website says it runs on SpringRTS - why is it not listed on the list of "Games"? Is it because you're still not deeming it as "ready for the masses", still under development?

What versions of Spring is it compatible with?

...
Evo gives ais cheats in order to make them competitive. It currently uses shard which is basically a unit spawner. It's slightly more than that, but yes, follows queues and sends everything it makes in a fight order to your base.

It would be nice to have something slightly more interesting to play against. Also, needs a lua ai. Shard is C++ which causes a lot of distribution issues.

Hei, first congratulation of Evo - it's really cool. When I first toyed around with AI, Evo was on my shortlist to use. However, Evo didn't work at the time (know I know why - it only works with Spring 96 and I had .. 98?).

The polishment and overall nice style of it really appeals to me and the fact that you're stating that that relatively high profile game doesn't have an AI on-par with it is appealing. The eco system appeared interesting: very focused on energy requirements for actually using the units.

However, I'm unsure about some things - the play style is very different from what I know so I'd have to learn all the tips&tricks of playing it. Also, I would never see anyone playing it (I seem to remember it was because Evo was operating in a separate Lobby server - properly populated but separate - with its own lobby client). And I'm not even sure how I'd work with it (both engine and/or lobby) on Linux.

What's the distribution problem of a C++ AI? It's because of the need to compile it to each of the multitude of target system, right?

But why does it need to be Lua? I'm planning on working with Java, since it runs fast, is easy to develop in and is totally cross-platform unless you mess it up. I'm not very keen on having to learn another language, which probably doesn't have a top-notch IDE and doesn't perform nearly as well as Java...

[PauloMorfeo]

What's the current status of NOTA? Do people still play it? Is it still maintained? Does it work in the current version of Spring?

I remember NOTA had a pretty niche community that, although small, was always very faithful, always with a few games every day and appeared to never decay.

And I remember that the gameplay was very different (considering the similarities between the majority) with much more of a feel of real warfare.

[raaar]

you can try to beat metal faction's built-in lua MFAI.

Wow, new stuff! Had never heard of it. The website says it runs on SpringRTS - why is it not listed on the list of "Games"? Is it because you're still not deeming it as "ready for the masses", still under development?

What versions of Spring is it compatible with?

it requires the current engine version : 100.0. There's a "nebula" autohost for it on the spring server.

It's almost ready, but I haven't asked for it to be included in the "games" page yet. It's been under active development and Its AI is apparently unusual in the sense that it tries to maintain a cohesive army, keep units alive and avoids enemy clusters that are too tough for it to engage until it has enough to overpower them (currently for land maps only). Technically an AI that can play BA or XTA can be easily modified to play MF, just need to be aware of respawnable commanders and their respawn pads (i.e., not be happy thinking it already has a factory after making a pad and then delay building an actual factory that can build units for too long).

[Forboding Angel]

Hei, first congratulation of Evo - it's really cool. When I first toyed around with AI, Evo was on my shortlist to use. However, Evo didn't work at the time (know I know why - it only works with Spring 96 and I had .. 98?).

The polishment and overall nice style of it really appeals to me and the fact that you're stating that that relatively high profile game doesn't have an AI on-par with it is appealing. The eco system appeared interesting: very focused on energy requirements for actually using the units.

However, I'm unsure about some things - the play style is very different from what I know so I'd have to learn all the tips&tricks of playing it. Also, I would never see anyone playing it (I seem to remember it was because Evo was operating in a separate Lobby server - properly populated but separate - with its own lobby client). And I'm not even sure how I'd work with it (both engine and/or lobby) on Linux.

What's the distribution problem of a C++ AI? It's because of the need to compile it to each of the multitude of target system, right?

But why does it need to be Lua? I'm planning on working with Java, since it runs fast, is easy to develop in and is totally cross-platform unless you mess it up. I'm not very keen on having to learn another language, which probably doesn't have a top-notch IDE and doesn't perform nearly as well as Java...

Thanks

Yeah, energy is used to basically power everything, units firing, shields, building nukes, etc. It makes for a pretty fun game. It's not perfect... There are a lot of things I wanted to implement that I simply don't have the knowledge to accomplish, which is a bit of a shame.

Evo uses the spring lobby server. ZK is the game that split off onto a different server. Evo has always been on the spring server.

A non-lua ai must be compiled every time something in the ai interface changes (which is literally always). This means that the ai must be compiled for every single engine version. Lua ais will still work. They are a lot easier to maintain, and they are all around better considering that you have direct access to pretty much all of the game internals. Frankly, not trying to be a debbie downer, but if you do a compiled ai I can't really see it gaining much traction. Distribution is the biggest hurdle, cause if the user joins the game in the lobby and it gets autodownloaded, how do they get the AI? They would have to find it online, download it and then figure out which engine folder to put it in, and what ai folder to put it in.

How do you make updates?

How do you distribute those updates?

Etcetcetc

Distribution for compiled ai's is kind of a non-starter really.

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.


The play style is a lot more micro oriented, but sort of focused on group micro. For example, unit positioning is super important, as is unit composition. Since the units fire through each other, positioning is key to winning or losing an even fight.

You get a lot of single unit micro too which is a lot of fun It's built to be easier for a casual player to pick up, however a casual player has to kinda get used to the game first ofc.

[FLOZi]

I'd suggest MCL but unless it is a luaAI it won't be easy even to order your first unit.

[Silentwings]

Yep, I'm afraid the future's orange probably lua. On the plus side, Lua is a dead easy language to learn and the Lua interface is cleaner than the (other) AI interfaces.

[Anarchid]

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!

[gajop]

This seems relevant: http://zero-k.info/Forum/Thread/20484
Guess Java/C++ AIs are more than competitive even for heavy-Lua games like ZK.
EDIT: Seems knorke already beat me to it. I blame it on the timezone difference I guess!

[8611z]

is there a precedent of a LuaAI existing in spring which is not a part of the game itself?

Yes, the MetalHecklerNoobAI:
viewtopic.php?p=559172#p559172
And of course BA-ChickenDefense which is a mutator of the BA-mod, too.
viewtopic.php?f=44&t=33752
Obvious drawbacks are obvious but BA-ChickenDefense does it that way and is one of the most popular 'AIs' ever.

[Forboding Angel]

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.

Releasing a new "version" with an updated dependency is a 1kb version number bump in rapid. It takes everyone involved less than 5 seconds to do.

A non-lua ai must be compiled every time something in the ai interface changes (which is literally always).

It changes upon every release spring version.

[PauloMorfeo]

... the user joins the game in the lobby and it gets autodownloaded, how do they get the AI? They would have to find it online, download it and then figure out which engine folder to put it in, and what ai folder to put it in.
...

- When a lobby auto-downloads a content-pack, whatever it is (map, etc), it gets dumped into one of those folders where spring looks for content, right?
- Those content packs are just gzip (or whatever) archives with their own internal folders containing content that will be recognized just as if we had put those files in Spring's main structure (/maps/*; etc), right?


Don't the "games" content packs have / can-have their own internal folders containing AIs?
I seem to remember having downloaded the Kernel Panic content pack and after the Lobby read(red) it, the KP AI appeared and I could use it.
^ Doesn't this mean that the AI gets automatically distributed with the content pack, basically inheriting whatever distributability that the "game" has?

I'm assuming a non-native code AI.

I'm assuming that the AI for KP becoming available was just part of the standard process I've described above. Am I wrong - was it by chance some kind of work around to allow it to be "part" of the content pack - is that something not achievable with a Java AI?

So, basically, are there any distribution issues with a Java AI?



I'd really prefer to stick with Java for developing an AI. Even though I'd like to not have to mess with compilations of every little attempt, Lua is weakly-typed (I hate that - it always causes problems), very poor(!) performance, no top-notch IDE (can I even debug it?) and I'd have to learn it:

... Lua is a dead easy language to learn ...

May be but it can never surpass my learning speed of Java: already know it. Not to mention that performance concerns me, since I might want to do some heavy computations (*).

* I'd plan on doing those in a background thread, sure, but not only would Lua be orders of magnitude slower, I don't think it even supports multi-threading.
* An example of a potentially infinitely heavy computation is to calculate a Minemax tree of predicted future states.

[PauloMorfeo]

...
(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)
...

Does that mean that the "game" engine (not Spring but, ex, Zero-K's engine) can exchange «proper» messages with a non-Lua AI? Do you know how to best achieve that? All i'm seeing in the Java interface is:
- Send/receive text message from/to player(s)
- luaMessage() //unsure what this does / how it works

...
Now, game recommendations. ZK lobby server is supported by two lobbies except ZKL itself, that is SWL and flobby. Both run on linux flawlessly.
...

Where the heck can I download the Zero-K content pack!? I can't find it anywhere - all I seem to find is the lobby... I care not about the lobby. (and while at it, all I can find is one lobby - couldn't find those "SWL" and "flobby" you wrote about even though I don't want a lobby)

[zwzsg]

Lua AI are part of a game. They are merely gadgets. They have as much control and communication as other gadgets, which means pretty much the most control you'll ever get beside changing the engine source code.

C and Java AI are external. You are right to think that distributing them would be troublesome. C and Java AI have usually more or less well maintained ways to communicate with the engine, but communication between an C/Java AI and the Lua gadgetery of the game can be troublesome, from what I've read.