Spring RTS Engine

XE8, XE9, XE10, Cell & Epic XE11

Currently I'm on version 0.33/XE7a of NTAI, and for a while now I've been eyeing a new AI project and planning the end of NTAI. So first I'll outline my plans for NTAI as well as a few ideas I have to implement for group AI.

The current situation

Firstly, I see people have been having problems with NTAI XE6+7, namely a crash bug and a nasty problem with single players. Lately I've attempted to correct the later, and succeeded, only to notice that playing nanoblobz resulted in no crashes even though argh said otherwise using XE7a. Suffice to say a test where 30 krogoths 200 Goliaths and 100 sumo's where placed in an arena surrounded by Vulcan's, buzz saws, doomsday weapons, and punishers, all where destroyed and then repeated with 2 NTAI's present and no crashes occurred.

I also changed the way buildings are placed slightly to prevent units from trying to build on their current location causing a stall sometimes, especially prevalent with commanders at game start and in nanoblobz.

XE8

Mongus has been making a lot of requests for improvements with how attack is handled in NTAI. Specifically planning ranged attacks such as ak's attacking a llt while crashers use the provided los of the AK's to destroy the llt. While ranged attacking is something that would require more extensive recoding, an easier request that comes along with much needed changes was defining attack groups rather than attack numbers, eg ak ak ak crash rather than 5 units 10 units 20 units. For that I'll be merging scouting and attacking so that attack groups can do both, and scout groups can be defined (5 finks for example). These will be defined as meta tags just like they currently are.

I'll do this by forming a pool of units, from which different sub-agents can draw units from to scout/attack etc. The good thing about this is it means I immediately have a simple TAI style tactical system with 2 basic agent types, being scouter and chaser tactical agents.

I will also consider allowing units to cloak when the energy is present based on a similar definition as the kamikaze units. And if it is needed greatly, mobile units that have no scouting/construction/offensive properties, such as mobile fusion reactors, mobile targeting facilities, or the sheep in nanoblobz that cant build, could be set to move to the lowest value on the threat matrix, meaning the matrix would have to be set initially to a high value rather than '1'.

Build trees for AA XTA FF and Nanoblobz will have to be fine tuned. Argh has already fine tuned nanoblobz for the next release he is working on, and will continue to work on it. Someone proposed to work on FF for NTAI, the same person who worked on FF for AAI, though i have yet to hear back from him. And I need someone for AA and XTA. Mongus has worked on XTA definitions but it is not official. I'll be drawing up documentation to further speed up the process and help people ready for the XE8 release, along with a simple update mechanism for learning files and mod definitions.

XE9

For this I intend on fine tuning the new systems present in XE8 and making units more intelligent. Along with that basic global wish lists free form tags that will implement AAI/OTAI style resource rules to help NTAI adapt to different circumstances that an ordinary build tree cannot anticipate.

I have planned several tactical agents to take advantage of the new implementation from XE8, as well as a shift to the task handling used in the 0.3 test builds

Aside from that I intend on integrating a building placement algorithm, to eradicate one or two minor problems (congestion of units when under nanoblobz, decent grouping of resource buildings, unit staging areas, minefields for nonblocking mines, etc).

In this version I also intend on sorting out water compatibility once and for all.

XE10

In this version I want a finalization of NTAI, attack and scouting tweaked and improved. I'll add wall building in this version, and player targeting.

I've also been doing research into travelling salesman problem to help with mex placement.

I'll also change the way the mod data for NTAI is stored for future compatibility should it be needed, and to help clear the clutter of several versions of just adding tags.

I'm also going to work with integrating the efficiency stats more into building selections, such as factories.

To make it clear, this will be the last and final version of NTAI to be released, equivalent to NTAI 1.0

Interim Group AI

I intend on creating a GUI aid group AI. Mainly an AI that adds simple data to the map showing what a unit is doing and other information. Namely the following off the top of my head:

- Construction ETA
- movement ETA
- current unit commands icons above units
- LOS borders
- Mex cache data generation & learning data generation without NTAI running, let NTAI get experience from your games and not just games you play against it
- Custom markers, such as rotating triangles or units rather than simple line markers
- Metal maker+Moho me AI integration
- Construction finished notification window
- Possibly panic clicking from sup com depending on how it works out....

There's no planned time frame for this to be complete however and could be finished anywhere between a week or half a year from now.


Epic & Cell

I've been tinkering and working on either TAI or NTAI for nearly a year now, during which I've speculated, and theorized, and thought a lot about things but I haven't implemented them, for example NTAI X, TAI tactical agents, the TAI building algorithm and transport AI etc... But I've also learn a lot in the last few months and I've stayed with a consistent design for NTAI that i feel is no longer capable of supporting the things I want, as well as the better implementations I have in mind.

To solve this problem and finalize the ideas and thoughts I've presented that permeate the AI's currently released in so many ways, I've devised a new AI project, separated as Cell and Epic. Cell being the new core I can build my AI around, and Epic being the actual high logic code driving the AI.

I'll make another post about Cell and Epic when I've finished writing something that can accurately describe it..... Along with some other stuff about future NTAI versions...

Productive as always.
Good to see you move on in time and develop more projects ^.^'
gogo Alantai!

Well here comes the part that is the more interesting of the two (maybe 3), and is most likely to have me either praised as the messiah or struck down as a buffoon with unrealistic goals that I can never achieve (Oh I can achieve them ;D).

I can only hope that I get more feedback on this than I did for my last post (hey zenka!), so speak your mind, just don't make unfounded comments that aren't useful...

:: Cell

The core workings of NTAI being as they are are simply too rigid to perform the necessary acrobatics required to manipulate the battlefield in any successful way against an expert player. The current systems simply aren't integrated enough, nor are they flexible enough. The representation of data is simplistic and lacks context. The current design can only go so far, and I'm not willing to run into a dead end where the curve of improvement starts to level off at an increasing rate.

So to remedy this I have a new design. Now I will have a single 'user space' for the AI, essentially every AI object having a basic interface handling a common data type CData* from which others would be derived, working similarly to the Handle Event() type functions of the AI Interface atm. This common data space should take the form of several containers and each object being assigned an address, being 2 integers, the first being a categorization, since AI objects from different AI instances all share the same space so they can access each other.

AI objects represent every aspect of the AI that is used. Trees, features, lines and points, units, explosions, logging classes, helpers, agents etc... Such inter connectivity and flexibility is needed, especially in such an abstract way, as I don't want a repeat of NTAI's numerous cumbersome interfaces adjoining segments of code, or a bloated global class either..

Because all AI objects have the same abstract interface, I have the option of putting in interfaces as AI objects allowing script interpreters to be used to read scripts rather than another class derived from the base AI object class, along with dlls written in other languages. This way i can make any AI built on top of cell easily moddable by making script AI objects and config objects, be they written in C python lua or a tdf parser reading from in game.

Because Cell is the foundation, I need it to be able to handle commands the engine interface would provide and all the utilities that go along with it, such as the debug streaks, the engine interface, command caching and prioritization, and basic utilities such as the logging class currently used by NTAI, simple geometric operations and a simple Mex algorithm (most probably krogothes class, but overridable).

One of the necessities for Epic in Cell will have to be the CGAL and CORE libraries, necessary because of the need to generate voronoi diagrams from maps, as well as the numerous geometric operations available from those libraries, and the skeletonization features needed to transform the blocking map into a format that CGAL can take to generate such diagrams.

I'm also considering using the boost signals library to issue events and requests.

Given time I wish to integrate a similar version of Cell into Spring as an option, and to extend the modability of unit behaviour ( sub-AI), then redistribute it out as an AI SDK. Triaxx has already agreed to use Cell to speed up development on his own AI if he doesn't come up with something better in the mean time, and he's given me feedback through email, as have one or two others.

Of all the available script interpreters I am thinking of integrating a lua based derivation, squirrel, possibly the original lua, depending on how squirrel turns out. I may add additional script interfaces in an attempt to provide certain features or interfaces form other games that use lua to further decrease the learning curve, but that would be subject to time and not immediately implemented.

I did have some stuff here but those paragraphs where deleted when my laptop shutdown after i saved and for some reason the file write was delayed and got lost.....

Imagine an AI where every aspect could be customized or overridden totally. Imagine bundling scripts with a mod that change how a specific unit behaves, implementing game play aspects, or taking the AI's high level code and replacing it with your own. Or creating an entire AI using nothing but a copy of the Cell dll and notepad.

So I guess while this is going to be very useful and flexible once implemented I guess the really interesting thoughts stay with Epic in the 3rd post (4th if I recover those paragraphs)

Sounds good, if you have the time to pull it off!

This is a longterm project but that is nothign considering what I have yet to post about Epic. Epic will combine so much and will be truly innovative comapred to the current AI's. It's the equivilant of a 24th century starship next to the stone age dwellers of OTAI/AAI/KAI/NTAI

I see you found your ego again.

I dont want poison in my thread sabbel

Nothing wrong with a little ego. You have to be pretty hubristic to think that you are capable of making something revolutionary like this. Aim for the sky, I say. If only I could be so imaginative...

hubristic ? =s


hmm people in lobby say it means proud/ambitious one of the two.

I'm a comeptitive person who thinks too much and I think for a long time adn read a lot, so naturally I have a lot of stuff to draw from. Just read a lot. But dont fall into the holes I did to get where I am or you'll surely regret them...

Ill just wait and see... I cant say youre too pretentious since im doing the same with KAI, aiming way high into the stars!

Well, if either of you can get an AI to play me a decent game at all of the weird things we're coming up with after NanoBlobs, then my hat's off to ye- we have some... interesting things in mind.

Seriously speaking... the main things I want to see from AIs in the future are:

1. Assignment of some behaviorial routines to units that are modder-configurable. For example, in NanoBlobs, Sheep should flee an area, if combat gets within, say, 1000 "pixels". If they can't flee, then they should have a "backup plan"- say, building a quick, last-ditch defensive unit, like a Wolf, instead of sitting there, patiently finishing a SpireRook and then getting murdered. This is not something you guys (AI devs) should have to play my mod to figure out, nor should you have to quiz me, etc. I (mod dev) should write it out, test it out, and then release a mod config, preferably with my mod. I am planning to do this with NTAI, for certain, and any other mods that will support NanoBlobs at release.

Alantai's suggestion of attack groups by type is great- but until (if) the ALT-MOVE function in Spring ever works worth a gosh-darn, it's not really going to matter all that much, in mixed units with different move speeds. I should probably talk to the Spring devs about that and put it into Mantis, as I've never seen it work right, ever, and I'd really like to see it work right... someday.

2. Gaia, gaia, gaia! I'm getting closer to having some kewl content we can put with a Gaia and make "virtual life" possible. But there is a lot, on the AI side, that needs doing, and some of it may require help from the Spring devs. For one thing... AIs should be able to recognize what "race" is being played by other players (I doubt if this variable is accesible by globalai, but making it available should be trivial) and attack/don't-attack other "races" based on that attribute. Then we can have "lions" (a Gaia race) that will attack "zebras" (another Gaia race), but which flee from "humans with high-powered rifles" And duplicate the cool hunting features of things like AOEII-III, among other things.

But we also need (OK, maybe not "need", but this would be REALLY USEFUL) to have a very, very specific Gaia... for building ... cities. Yup, cities. Think about it, folks- instead of having cities as Features... we could have AIs build them randomly, dynamically, and fast. NTAI's current build is almost 100% able to do this, because of the limitations Alantai put into the buildtree (you can, for example, tell a unit to quit bulding after awhile, and tell a Commander that it can't move... which is awesome). The only remaining problem is that, with NTAI, I haven't been able to get the Commander to build far enough away from himself to really get this to work as well as it should. Otherwise... it's pretty much just waiting for content, and Smoth's building Features, along with other things, are just itching to be combined with this...

3. Lastly... Alantai, I really, really like how things are going with NTAI's simple-but-elegant global controls in the buildtrees and mod.tdf file, now that I've figured most of it out. I just want some more specific logic to give parameters to units, and it'd be really nice if a unit could have more than one buildtree, and picked one at "birth", to allow for a fuzzier initial curve on what gets built- or a really rock-solid, optimized early build, followed by fuzz... or... etc.

Overall... other than the fact that NTAI is the only AI that can play Blobs at the moment (which is mainly because I haven't been sharing it out- at this point, if you're an AI developer... just ask if you want to see it as the rough cut gradually gets polished and final content is integrated- just be aware that it's Not Done Yet and please, don't share it with the public- it's still quite embarassingly primitive in places)... I really couldn't be much happier with how things are going. AAI is really pretty nice, NTAI is working pretty well, and OTAI is working great. And I'm eager to see what KAI will look like in its next release, and hope that it will continue to support NanoBlob so that I can pit Alantai's scripted-parameter approach against AAI's fuzzy math and KAI's vicious randomizer

wow , that sounds like alot of work.

I think its possible, but you need good organization and planning, as you are generating graphics... can you draw (pen and paper?) a basic organizational esqueme about .... lets say the final organization structure of NTAI? (is that even possible? heh)

One last thing could (should!) be added ntai...

Non unit centric buildtrees, but objective related... and distributed to units as they are capable to handle the task.

The unit based buildlists cant have the current game context in them...

What i mean, at some point in battle, strategy may change drastically, you need to adapt to that situation, like mount an hlt asap, or get aa asap.. (when you nottice the first brawlers).

Maybe its out of the scope of ntai, but i think its a must.

Good you are interested in the tactical groups, dont prettend to make the perfect groups handling... just dont walk long range units into defenses(/ranges) and you are one step forward. (stupid as it souds, many players do this, walk thier dominators into enemys defenses just as they were assault units).

The thing about cell and .. er... the other guy.. well, its quite interesting (and a bit complex), hope i can understand it someday! well see how it builds up :)

Heh, it sounds like you've finally found a way to touch on all the high end micromangement stuff we chatted about via PM...

Best of luck, sounds like an AI that could end up VERY worth playing.

First off, I intended on implementing random buildtrees as ARgh said, as mongus will tell you in XE5, but I found ti was easier to prot the test build algorithms and implement AAI style learning.

I've already sidelined what mongus says is needed for resources as a economic wishlist to counter emergencies....

I'm thinking I'll add random buildtrees to XE8, aswell as emergency buildtrees, aswell as give attack units buildtrees along with extra tags such as T_DGUN T_RECLAIM T_MOVE_RANDOM etc...


But i really need soemone to do for AA and XTA what Argh ahs done for nanoblobz. Of all the people here the only person whos knowledge of NTAI comes anywhere near mien is Argh because eh read the documentationa dn used it. You're all expecting me to give you an instant AI with noe ffort ony uor behalf, btu i cannot make the reuired buildtrees for XTA and AA, I can onyl make them work so that they dotn show horrific behaviour, and I'll onyl chekc XTA for horrific behaviour, so get to work on an AA buildtree because their's no chance of me makign one for you.


As for drawing out the future structure fo NTAI, I've nto done diagrams but for XE8 instead of the current system I'll have my global class with a pool of units, the agents will take them from the central pool and give them tasks todo.

I'm also thinking of changing how buildtrees are setup from just text files to the equivilant of
which would be appended to the end of mod.tdf along with meta tags..

Then the buildtrees referenced would be stored in tasktree.tdf as the following....
with more options added in later versions....

And emergency queues being executed when the unit is damaged by enemies.

As for Alt+move that's easily sorted, I just need to add the extra stuf to the move command issuing code in FindTarget() rather than simply sending them to th centre of the target sector.

As for unit groups, I'm thinking scout groups too and possibly builder groups, though builder groups would require a little more effort that might wait till XE9.. They'll end up being defined somethign like:
in mod.tdf then groups.tdf having a similair format as buildtree.tdf with task tree being the mode of attack (probably T_ATTACK only in first version and such as T_CIRCLE for freakers/zippers etc in XE9) and emergency task tree what happens when the untis are attacked and their group size is lower than or at the emergency threshold..... The task lists are executed when a target is selected, e.g. this is how we will attack a llt we've just targeted..........

I guess I'll have to then expand on T_ATTACK with T_RANGED_ATTACK and T_CLOSEUP_ATTACK.

As for the commander not beign able to build thigns far away in NTAI, thats a problem witht he engine, technically NTAI should build as far as it can untill it has to move because all it does is send a build command off, with no movement involved.....

Also reading script.tdf directly can give you the sides each player has. NTAI already uses that method to log the AI's in play and their player names to logfile........