Spring RTS Engine

Agon wrote: I see a big need for Lua<->AI in the feature of Spring. Nearly all new mods and releases of mods are using Lua and some really depend on Lua like Fibre and THIS.

If we're going to talk Fibre and THIS, we need to start thinking about a restricted list of AIs that are defined by the mod or map, or some other tag-based relationship or something to keep the wrong AI from being used on a mod it was never intended for.

And have my brand new hypothetical AI that supports Fibre borked until the next Fibre update? I don't think so.

Maybe a contest for AI developer could increase the popularity.
Trying to get a place on google summer of code next year.
Increasing the community through radio, blogs, forum posts and TV.
We could need a pr-manager :D .

The AI dev problem is not popularity or a community that is too small, spring has enough attention as an AI research item. It is about making AI creation accessible to windows users. AF is scaringly right about no new AI developers entering spring since we are using mingw, and the AI's that we have are bitrotting because of interface problems.

The current C++ interface is only there because no one wants to rewrite it, but it sucks from a design POV, and it is killing the spring AI scene.
The spring engine developers need to make up a plan about how to support AI, because the current situation of just hoping that someone will fix things doesn't work.

The engine developers have to decide on the AI interface, i hate to talk about responsibilities in spare time, but it applies here, if the AI scene has to stay alive.

Make it C again with either a shitload of get/set functions, use a message system, or use OpenGL style functions aiGetUnitVector3(UNIT_Position, &pos).
Then ditch the C++ interface. Yes it will kill off AI's even more for a moment, but it will come back with more support because of a decent design.

Right now, its weird that a lot of work is going into staying compatible with old mods (When you really should throw out a lot of compatibility code and implement it in lua), while the AI's break every release. This seems out of balance.

Also to maintain it from the spring engine side, there either need to be rules about having to add stuff to the interface whenever you add something to the engine.
It doesn't even have to take that much development time, if you just expose all the unit state through creg class members. Then it will be low maintainance.

There has to be a standard way to access game state, by lua and AI, maybe with named properties that can be queried by ID. Like

positionPropID = aiGetUnitPropertyID("position");
aiSetPropertyf3(positionPropID, &positionVector);

If the interface is replaced with such a minimal set of functions, then the added bonus is that creating AI bindings to other languages is probably a lot easier too.

if i can, i would like to help with this. i could at least give input what might be good to have or do for supporting other languages then C, C++ or LUA; to easy that work.
this thing with a new AI interface... maybe we could have the old and the new one in parallel, till the new one is good, and a lot of AIs got converted or new ones are available.
i personally dont really know if a new one is needed, as i never had anythign to do with LUA, nor did my own AI -> don't know how usefull that is. but i have to say that the current interface is bad, in that its so unclear.
i found out about this when i had to figure out what to include in JAI and what not. in UnitDef for example, ther are lots of references to thigns like structs that contain sound or icons or graphic references, and they agian have otehr thigns referenced...
what i would have liked is a kind of IUnitDef used in the AI interface, that only cotians the things of UnitDef that are usefull for an AI, and this not just for UnitDef, but for all classes (and structs).

ahh.. something else:
the interface had to be better documented.. at least the unobvious things. a lot of functions return int or bool, and to me it is often unclear what these values mean.
second:
functions what take an array of some sort, that then will be filled...
one has to initialize them to some size, and this is also usually unclear, and even when its clear, its not user friendly (in my eyes). its ok on functions that always return fixed size data, like GetMetalMap() or GetLosMap(), but on others like GetFriendlyUnits() or GetSelectedUnits(), i would prefer to get a std::vector or something liek that.

As I said if we kept the current itnerface and shifted it so when we're finished it is more a wrapper class than a direct API, that way we maintain compatibility and we can gradually port the existing AIs over to the new interface. Thus we have a single C API with a C++ Compatibility Wrapper layer built on top.

Once we've ported all the AIs we can nuke the wrapper layer. We can also start work on a proper SDK with a more OO wrapper class using C++ classes for units and tieing up things like commands and stuff.

If anything such an SDK would need to be consistent and similar if not as close as the Java and C# equivalents, so that what documentation is generated can be applied as far wide as possible.

I agree with jelmer regarding implementation of the C interface. A set of GetValue() SetValue() and HandleEvent(), SendEvent() using overloads when necessary to avoid void* type stuff would be best. I'm not sure whether we should work lua into that though or keep trepans lua methods as individual C functions with the necessary extra parameters, then work them into the other functions at a later date.


As it is, work on this can be done directly in spring, as long as the classes that implement the AI interface are separated into a wrapper class and an implementation class then we can slowly shift functionality out of the implementation and into the new API while keeping compatibility using the wrapper class.

Once the wrapper class is using Pure C API we can shift that entire section of the interface out of the engine and into the AIs, where the AI developers can then start to port their AIs bit by bit from old to new.

maybe we should open a new thread for this "new AI interface" or something

hoijui wrote:maybe we should open a new thread for this "new AI interface" or something

Yeah, we should. And some UML or diagrams for showing it visual would be helpful, too.

Besides the problem with a new AI interface, we should also discuss how we solve the problem with Lua<->AI. Not that the AI Interface is rewritten and it needs to be rewritten again because of a impossible or hard to do integration of a Lua<->AI interface.

The big question is who will do this work?

You can use Vs.net for ai development, at least I do. Sometimes the vs.net project file of spring has not been updated when linux devs added/removed files etc., but usually I can build spring without any problems. However you need someone to build mingw compatible binaries for public releases (thx to yuri :) )

Concerning the lack of new AIs: I think the main problem is the ammount of time you have to spend on coding before you come up with an even poorly working AI. Starting to mod units is much easier, ppl can experiment with existant mods and change some stats of units, etc. - doing the same thing with an existing AI is rather impossible, it will take days - weeks to get familiar with the code of an AI that has been written by someone else.

Personally I doubt the AI drought can be blamed on the interface alone,
IMHO it's simply because any new AI developer starting from scratch has
to compete (in a sense) against at least four existing AI libs which 1) are
already crystallized due to having been around for so much longer, 2) all
cover very different approaches so many ideas have been tried before so
there's not much apparent room left for innovation, and 3) don't get a lot
of attention anymore from mod devs so the motivation to write one is not
very high (for the few people that would even consider it.)

Also, apart from the somewhat common attitude that AI's suck anyway
and catering to them is pointless, there's the valid point that obviously
no devs really want to hold back their project in terms of Lua mechanics
just to allow an AI to play it, and that in turn raises the motivational bar
that people have to cross even higher. There do seem to be more than
plenty academic Spring AI projects going on so I wouldn't call "the scene"
dead though.

Of course then there are more peripheral causes like the fact that AI
is no longer as glamorous an area as it may have been in the earlier
days of Spring (when the interface was certainly even more lacking )
and there are opportunities to do clever & rewarding stuff in Lua now,
which is at the same time a far more accessible language than C++ or
C# or Java. Plus the scope of the task of building a full-fledged skirmish
AI just differs by several orders of magnitude and not many people are
willing or able to put as much time into it as back in 2005. In any case I
would point to the compiler toolchain and unfriendly interface obstacles
as one of the last reasons why there haven't been any new kids in town
since RAI rather than the first.

May it also be pointed out that Sander bakkes who hasn't posted much here lately, used NTai as an assignment as well as various other AIs as part of his degree course. One comment that was made was that future usage was unlikely due to the issues in building a working spring in Visual studio and then the stability of the compiled binary when used in long batch runs in order for training purposes.

Building spring in MSVC is actually pretty easy, especially if you compare it with typical commercial projects. It's just one project file, one solution file and even the dependencies are nicely packaged (ok, not 100% perfect atm, but still way better then having to collect/build them all manually).

Stability with testing always remains an issue; however in practice I found that in the majority of cases long running tests failed because of crashes in the AIs and not in Spring itself. (Back when I was testing sync stuff etc., often did that with AI games too.)

(Note that those results may be skewed a bit because I usually fixed engine crash bugs immediately whenever they occurred )

You know, we could always form a breakaway renegade group that does everything in msvc.

I dont mean we use a different source tree, simply: whenever there's a new spring release, or whenever we feel like it, we make a new msvc build and release/use that.

What's the sync status with msvc vs gcc? Will the msvc build sync ok with the gcc version?

hughperkins wrote:You know, we could always form a breakaway renegade group that does everything in msvc.

I dont mean we use a different source tree, simply: whenever there's a new spring release, or whenever we feel like it, we make a new msvc build and release/use that.

What's the sync status with msvc vs gcc? Will the msvc build sync ok with the gcc version?

Nope won't sync. Unless it's magically fixed itself of course, didn't try it for a long time

Question: why wont it sync? I dont mean the details, I wont understand them, but conceptually, why will x86 code running on an x86 give different floating-point results when compiled with one compiler than another?

Kloot wrote:Personally I doubt the AI drought can be blamed on the interface alone

+1

There have only been very few occasions where the interface limited AAI development. From a practical point of view it has all necessary (except detecting resurrected unit, since health of a unit is set after UnitCreated has been called) functions to support non lua mods like BA, AA etc.

Apart from that I doubt it's possible to write an AI that deals well with OTA like mods and all these fancy lua stuff at the same time - If game mechanics of different mods become more and more diverse it will be necessary to write mod specific AIs