Spring RTS Engine

Hi all

I recently did my honours research in AI for spring, unfortunately the learning curve and lack of coherent documentation resulted in the final product being a half-baked proof of concept that was just enough to provide me with sufficient statistics to write up the thesis.

Despite the challenge of learning the ins and outs of the spring engine, the features such as:
-a range of AI interfaces that is common over many RTS games
-the fact that it is so easy to setup and observe AI v AI battles
-and the ability to use Lua widgets/gadgets to collect game statistics independently of AI code
Are so unbelievably marvelous and no other open source RTS engine comes close to being as good

I am currently 6 months into my PhD expanding on the work I started in honours and my single biggest frustration is that all the RTS AI work I find is implemented on about 20 different RTS games. This is making comparison impossible, and expanding on existing work difficult (so I’m not going to). So in my opinion it is in the best interests of the RTS AI field for Spring to become a dominant research tool once more.

I have a good handle on widgets, but I only have foundation knowledge in gadgets and the AI interfaces and am currently struggling to try and work out how luaGaia operates and weather I can use it to set up specific scenarios that define what units, building and resources players start with.

So my initial suggestions are:
-People with more knowledge about AI in spring should update the Wikipedia page to include something about AI dev
-some basic tutorials on AI dev that can be distributed to/found by uni students may entice a new generation of AI developers
-finally, an annual competition for AIs. I’m not sure of the mechanics of such a competition, only that people are generally motivated by a bit of friendly competition

I'm doing some work on improving this as I'm working on an AI using the new Lua interface. To help others build AI's quickly I'm doing some extra work to:

a.) Document the LuaAI interface better.

b.) Create a tiered AI framework with 3 levels:
i) A framework based on Tobi's code to run a LuaAI unsynced and wrapped in a class that deals with one team at a time.
ii.) A framework on top of that which provides generalised functions for many AI related tasks like grouping, pathfinding, transporting, debugging, filtering, resource management and threat calculations.
iii.) A game-specific layer above that where AI's can deal with gameplay related concerns.

The idea is that layers i and ii are shared by AI code at layer iii so AI authors can jump into development quickly without dealing with more low-level concerns. I also have future plans to make the same interface available to widgets (for creating advanced Support AIs)

Of course all of this only applies to AIs written in Lua and using the LuaAI interface. I'm not sure how applicable Lua is to academia but I'm not planning to port any of it to C or Java interfaces. The code is all GPL 2.0, same as the engine and can be found at http://www.warriorhut.org/spring/ai/ (though the version there is a bit out of date and will soon be replaced with a more functional version that works on 84.0).

sounds good, other than speed there is no reason why Lua is not useful to AI research. the flexibility and ease of edit,test,edit,test style development and the modularity of widgets and gadgets makes lua quite useful.

I am focusing on C++ because I am working on AI for micromanaging groups of units. the system will intelligently assign tasks to individual units in groups based on situation data, group's objectives and individual's abilities and attributes to the scale of 1000's of tasks distributed across many groups of as many as 100 units. with all this and the desire for frequent reassignment based on the rapidly changing environment and the problem of trying to find the optimal group wide task distribution requires a staggering amount of calculations. I need the most efficient programming language to have any chance of not decimating the frame rate of the game.

as a result i will probably make some C++ tutorials when i know a bit more about what is going on.

but for all those working on higher level reasoning Lua is far more appealing. I only wish it was easier to debug.

I feel that many performance issues relating to AI can be solved by good design. For example the code I wrote is designed to build intelligence overlays that are cached and then reused by all team units. In other words I check if a map region has certain properties because unit X wants to know then unit Y does not need to recalculate those properties. I also take advantage of the hashing inherent to tables and the Lua bit operations in Spring to do fast lookups and comparisons.

On the other hand my code is not so concerned with fine unit micromanagement. It's a "big picture" AI that's more concerned with battlefield objectives. I feel that AI micromanagement runs the risk of fighting the engine over pathing issues and is more likely to expose bugs and appear to be cheating (as in human players do not have the same ability to micro thousands of mostly offscreen units simultaneously).

Also I wouldn't say Lua is hard to debug. It supports all the usual sorts of logging (Spring.Echo), Pretty-Printing, Tracebacks, Profiling etc. If you wanted to you could basically track every assignment made to a table through a custom metatable. In Spring it also has access to GL so you can debug visually as well (ie, show map markers, draw color threat maps, etc). I think what confuses people most is that some of these things aren't core language and you'd need your own debug functions. Fortunately these are already written and available through the lua-users site, spring wiki and forums, and other sources.

Lua also has the advantage that you can modify and test code without compiling. In some cases without even restarting Spring. I find this advantage significant as I tend to write code in sloppy generalisations then debug my code on-the-fly by running it and seeing what broke. In C++ I get frustrated because if I made a mistake somewhere I generally don't know about it until I recompile, re-install and run Spring.

As far as academia goes I was basically implying that few CompSci courses teach Lua, very few professors know it, and therefore it may not always be acceptable for AI coursework.

0bliter8or wrote:I need the most efficient programming language to have any chance of not decimating the frame rate of the game.

From the sounds of it you may be in more danger of decimating the framerate by flooding the network with micro-orders. If units are reacting too fast to threats and opportunities then you'll get what we call "order spam" or "flooding" because the creation of any new order requires network synchronisation with other players.

There are intelligent ways to deal with that of course but my point is your unit reaction times are quite probably more limited by network resources rather than CPU time unless you stagger your orders across frames (in which event you could stagger your processing across frames for the same net effect).

Ironically a good solution to order spam is to use a synced Lua AI. Since it runs simultaneously on the computer of every player an order given in synced code does not require synchronisation (at least that's my understanding). You could potentially issue thousands of orders per frame until you max the CPU of the player with the slowest PC.

hey, welcome!
nice to hear from you!

nearly all of the documentation that is available for non-Lua AI stuff was done people that never wrote an IA themselfs, and that know the engine quite well. This naturally means, that lots of things are clear for them, which are not so for AI devs, and that they can simply not know what would need to be documented, and how (and where there are bugs).
the remaining stuff has to be done by users of the AI stuff. there were about two or three AI devs that actually contributed back documentation, which is a very easy thing to do, both on the wiki or in source code.

in practice, what happens is this:
1. AI devs does not know what functionX() does, or about the side effects, or about the range of the params or return value, or ...
2.s. what he should be doing
figure it out (by doing at least one of these):
* ask on the AI dev channel in the lobby: #ai (can also be reached through IRC)
* ask on the forum
* try to figure it out by looking at code of other AIs or the engine source
2.r. what happens most of the time:
he gives up, either on the project, or at least of the part of the project involving that function
3. document your findings, at best in a doxygen comment for functionX()

the third point happens way too seldomly!

you are now 6 months into your project, and this is the first time i hear about you, if i am not mistaken. and even if i were, there has not been a single AI doc change proposal in the last 6 months.
now wat i meen!?

interface devs can not improve the docu, only you can, so please do it. all proposed doc changes have been adopted instantly so far. the tutorial pdf for starting a Java AI was also done by an AI dev, btw (though it is a very unpractical format of course). also tutorials can only be made by AI devs, and it should be done by them right when they learn how to do it themselfs, when they still know about usual pitfalls.

the annual AI battles thing is also a good idea, and that would probably be better done by the people you are addressing here. technically most stuff required for it is already done, it just had to be setup and maintained by someone.

I am focusing on C++ because I am working on AI for micromanaging groups of units.

how does that goal require or even suggest C++? Use Java instead. C++ is slower then Java in pretty much everything that matters. do not use C++. i can not imagine any circumstances under which you should use it for a new AI project. People talking about Java being slower are referring to UI refresh problems that existed 10 years ago, which... well i guess it is obvious this does not matter for you, as you need no native UI, and are 10 years in the future!
The Java AI Interface is also more feature rich, allows for better modularity, faster and more flexible development, is better maintained and documented, will receive more cool futures, does not crash the engine when the AI does something stupid, ...
Using C++ instead of Java is like buying a car that costs 999$ instead of the 1000$ one, which is superior in every other way, and uses 1/4 of the amount of gasoline of the cheaper car.

Performance wise

Of all the AIs we have here, the AIs themselves are fast, and have a tiny overhead, but, the majority of any slowdown comes from one or two components.

KAIK: The pathfinder
NTai: The building placement algorithm
etc

This is why at the moment the likes of Shard and CRAIG run super fast, because they're not doing anything that really pushes the data around like a full pathfinder, or a grid by grid search.

Competition

Competition is desirable, and a good motivator, and we used to have it here. Unfortunately 2 pressures/trends have moved against this, firstly the original AI debacle got rid of the original competition, and then when things got back in business, everyone was developing for different games. Zwzsg ran tests like we used to to see who was best at kernel panic AI gameplay, but otherwise not much else has happened.

hoijui, I see java lacks of stable deployment. How can you explain that Spring installer does not include nice BAI? In its thread many people could not just RUN it. It requires external component - java machine. And this will always be a problem on Windows platform until java is bundled and updated via MS update server. So, if smb is going to create AI to let people actually play it (abd not to study smth) C++ is almost the only choice. Or use Lua specially for Spring AI. As for me I had no moitvation to learn another scripting language after learning VBScript, JS, Python, Perl and PHP.

java vm with every spring.. OMG all my arguments going to the baskett


..condensed remains.. Its my favourite motha-tongue, dontt take itt away from me.

SpliFF wrote:b.) Create a tiered AI framework with 3 levels:

I think just having the first level would already help massively:
i) A framework based on Tobi's code to run a LuaAI unsynced and wrapped in a class that deals with one team at a time.
I think an AI should not have to watch out as not to accidently controll enemy units. There is probally more like that...
Also in my game I have "drones" that are not controllable by players (selectable=false) but the AI orders them around just like normal units.
So having a class/framework wrap thing that throws errors on "illegal things" would be nice.
Say a AI.GiveOrderToUnit(...) that checks if the order is valid and then passes it to Spring.GiveOrderToUnit.

I like the LuaAI framework idea to give people a reasonably simple way to start. Personally I'll stick to gadget AI as I think once you get your head around gadgets they give you more flexibility.

More competition in AI would be great but as far as I know we have a lot of old AIs that play BA, a few LuaAIs that play specific games and Shard which noone seems to know how to write configs for. Would we choose a game (say, KP for simplicity) and encourage people to write AI for it?

hey, this sounds pretty cool! Good luck to you!

Google_Frog wrote:Would we choose a game (say, KP for simplicity) and encourage people to write AI for it?

At one point there were three working for KP!
(KDR_11k's Lua, AF's NTai/Shard, imbaczek's "Baczek's KP AI")

Speaking of which, has there been any recent advancement toward having the last two work in Spring 83?
(If you need a version of KP that's 83 compatible, look around there.)

i did have an eye on baczeks AI, but now it fails to compile cause it uses some boost.python library that is no longer available in recent boost libs (or at least it seems so to me).

Some progress was made to get Shard compiling with help from Hoijui and Abma, but further work is needed.