Why is there a new AI interface for the Spring Engine? Lets clear up some misunderstandings and explain things nice and clearly!I’ll start by explaining the problems with the old interface and how things are changing, but first lets lay some myths to rest.
What Interface Would This be?
The spring engine (RTS Strategy game engine), has an interface with which AI modules can be loaded into. These modules are then given control of a player, and play the game; when you play against the computer it is these AIs you are playing against. Many different people have built and are still building AIs for the spring engine, and this is how they do it. The spring developers themselves however do not maintain an ‘official’ AI, rather they bundle the most popular and active AIs in the community. An example of this would be my own AI project NTai.
Myths?
Its a common conception that AI developers have abandoned the content, and are embarking upon an orgy of development by reinventing the wheel and cavorting with new and exotic programming languages nobody needs. This is nonsense, ignorant speculation by people who didn’t read the forum threads and made wild assumptions without any effort to understand the problem.
Its also seen by many that lua has made native AIs obsolete. This is nonsense, since lua AIs lack the vast amounts of code available to native AIs, such as geometric processing libraries, and networking, etc. Lua AIs are also much slower, something that is very important in an AI. There’s also a vast amount of pre-existing algorithms that native AI code can make use of.
What Is The AI Interface?
When you play against the computer, the computer has an AI in it that tells the computer controlled units what to do, how to behave, where to build etc etc. These are called skirmish AIs, and they’re built by AI developers who contribute to the community. Their code sits in a dll/so library which the spring engine uses via the ‘interface’
What Was Wrong With The Existing Interface?
The interface was initially satisfactory for the most part. It worked! But as time went on, it got messier. Guidelines where introduced to keep it tidy and they were flouted and it became a great big spaghetti monster of code, making it harder to learn the API and build new AIs.
After all this de-motivational code bloat, the engine moved to Linux support. One of the main requirements being the use of a specific compiler, mingw32. Most active AI developers however used Visual Studio, and the change to mingw32 was not welcomed. With Visual studio, all one had to do was load up the project and press build, and hey presto, out popped a dll! Debugging AIs was also much easier.
Mingw32 however changed everything. There were issues with setting up the build environment, IDEs that didn’t quite work, command line tools, new libraries, slower execution speeds, larger dll file sizes, etc, etc. Annoying quirks such as needing to put the AI on the same hard drive as the compiler, and fixes for Vista due to bugs in mingw made the whole system a tedious nightmare. What’s more, because it was a C++ AI interface, AI developers couldn’t just go back to visual studio without dragging the rest of spring with them and loosing Linux support.
As a result most AI developers lost their momentum, the number of new AI projects appearing nose dived, and AI development ground to a halt for the most part.
How Is the New Interface Going to Fix This?
The new interface is a C interface, not a C++ interface. This means that AI developers are no longer bound to the mingw32 compiler, and can now use Visual Studio once again if they wish. This makes the build process infinitely easier, and should be a huge boost to AI development.
Because the interface has also been redesigned, it has been envisaged that a more generic message based approach be taken to safeguard the interface against compatibility issues and future changes, as well as encourage a more modular approach to AI design. This means it should be easier for new AI developers to pick up and learn. A compatibility layer has been written to allow the existing AI code base to carry on, on top of the new interface.
Since the new system is modular, a system of wrappers and implementation libraries has been introduced, allowing new languages to be added, such as C#, Java, or even D. Since not all programmers know C++ , this expands the range of potential developers, as well as giving new tools to AI developers.
A shift in how lobby clients declare AIs has also taken place, presenting a unified mechanism for specifying AIs rather than one for lua AIs and one for c++ AIs. AI options are now possible too. The group AI interface has also been removed.
9 replies on “Why The New Interface?”
So there will be no more groupAI at all? What of all the existing groupAIs, such as MexUpgrader? Will they be trashed?
Will the functionality of assigning an AI to a group of units still exist in some form? If so, could you refer me to some documentation? I could not find references to this in the wiki.
regards,
Gregory
nope, all this functionality was for the most part obsoleted by lua widgets which can assign functionality to unit groups and much more.
The axe has fallen officially as group AI support was removed from the engine in the last 2 weeks in the git repository. The current spring version is the very last that will support group AIs in their current incarnation.
Sounds awesome 🙂
So what would it take to get a setup which lets me write Java UI in windows (XP) ? 🙂
Everytime I even consider doing any code or anything spring related (or c/c++ projects in general on windows, especially the cross platform kind 🙂 ) the amount of effort just to get a stable build has always put me way off 🙂
Compare to linux where c(++) is pretty ok, all the tools and bits tend to be already there, as long as the build system/make stuff hasn’t gone too much overboard 🙂
Guess someone still needs to write a JNI wrapper or so, I guess I should be able to do that XD
Actually, under the current version fo the spring engine, you can use any compiler you want udner windows and you don’t have to build spring either. so you can build an AI in visual studio and debug it using the spring engine on the website!
Also there’s a working Java API running on top of the C API, and there are already Java AIs out there being developed!
As for a Java UI, that would be problematic under windwos XP due to the way open GL works, you’d need vista or to force java to use non directx/opengl rendering pipelines, because it would require 2 graphics contexts, something only really possible within vista or later.
You can however communicate with lua and use a widget as a go between for ingame GUI
That’s pretty neat!
I did find the ‘Null Object Oriented Java AI’, which I’m trying to mess with now.
I assume that’s what you mean with the java api 🙂
Hmm, I’ll have to look harder for those java ui’s then, some example code would be usefull 🙂
Oh! I wouldn’t want a java UI. Not sure where you read that from my message, JNI is just one of the ways to bind C to Java 🙂
For now I’m happy if I can make a Commander like move XD
Cheers!
GAh, gah, gah XD
AI! I mean AI! 🙂
Work’s been to heavy on me 🙂
Shame you can’t edit posts 😀
heh but I can ;p
There are a few java AIs in development though not publicly, and there was a demonstration involving a java port of RAI iirc
I tried to port a tiny little bit of kaik just for fun (and dear squeek it got late XD ), just the unit categorization, seems to work pretty well tho 🙂
I also noticed that kaik unit categorization has some major flaws with CA XD (I think so atleast, its not classing things like fusion reactors 🙂 ).
Java port of RAI, now that’d be a neat base 🙂
I wish they’d not have used Spring as a name, searching for java stuff always gives me the Spring Java framework XD
Btw, just so I understand properly, the ‘new interface’ this post talks about is indeed the C interface which NullOOJavaAI builds upon, correct ? 🙂
You would be best talking to hoijui etc on the sprign forums since he built most of the API single handedly.
But yes its the new C API this post talks about.