A Report Card on Current Development (long)

[Argh]

Hi there. Yes, I'm back, for the few of you who even know my handle here. I never really left- I just lurk here when I'm not modding what I'm usually modding

I've been watching the development of AI for Spring with great interest. Ever since my first giant posts on the subject of AI (which, unfortunately, are probably gone now, due to Forum changes) where I described a simple AI structure for Spring and methods to bring it to fruition, I've been watching to see how things have been going.

Here is a report card. These are my results, on my rig, and my opinions, of course- please don't flame me if you have not had some of the problems I have been having, for example, or don't share my opinions. I am not posting here (after a nearly 6-month lurking period) to offend anybody, especially the clever programmers who've gotten things thus far. But, that said, I'm going to be straight with everybody, and honest about what I see. This is a critique.


1. Stability is a serious problem. Every AI I reviewed- JCAI, NTAI, AAI, OTAI- every one... crashed my rig, with various levels of crash, from simple client-crashes to memory leaks that crashed Windows XP

NTAI, for example (I looked at the current build) crashes any time a Commander dies. Every time. Which kind've stinks. JCAI seems to crash fairly randomly. OTAI and AAI crash on commander death, and also report various problems with issuing unit commands... that usually precedes a crash.


2. All of the AIs use their Commanders very, very poorly. I have yet to see a Commander helping a Factory build a Kbot. Commanders do not d-gun. Commanders do not run away from enemies doing significant damage. Commanders run up to metal spots, even if well-defended. Commanders do not cloak. Commanders do not support early rush tactics. Commanders do not "understand" if the game is Death = End or Death = Continue and occasionally use "comm-bomb" suicide tactics, like a real player will.

Overall, this is a big weakness. I have taken out AI Commanders with Laser Turrets. I have taken them out with Peewees, Flashes, etc., etc., etc. It just doesn't matter. Unlike OTA, where the Commander seemed to have a radius that it rarely strayed from, keeping it inside the heavily-defended central base (which was, to be admitted a serious flaw because it never varied), Commanders don't engage in any really smart behavior patterns. OTA's Commander AI was better... except in regards to the placement of buildings... where, as far as I can tell, the current AIs are about on par.

3. None of the AIs feature an easy-to-configure, well-documented scripting interface that will let modders integrate new units into them very easily. I've been trying out my Mechpack Improved in Spring, and the AIs thus far will never, ever build the units, even though they show up in the build trees. No matter how long I wait, or how fast I run the game.

This is silly. AI designers... c'mon... build a common DLL that will automatically read the available units and make them available, instead of everybody developing their own, unique (and buggy) variants. I think that this "everybody doing own thing except for things like metal classes" is not serving you well here. I understand that y'all want different behavioral approaches and that's fine... but you need to have a common unit-reading interface.

And, quite frankly, I'm a little amazed that we don't have a weighting system that's transparent to unit designers. If the AI_weight and AI_limits are in a unit's FBI... then whatever AI you're building, folks... it should OBEY THAT. That way, modders are in control over behaviors in certain predictable ways. I don't care (and, I think, most modders don't care) if you do something whacky, like say "if AI_weight = X, and AI_limit = Y, then UberKillahAI will never build that unit". That's fine. But use the FBIs. You all have designed weighting systems on your own. This has tied all of your AIs to specific mods. And this... this is a big mistake. Reverse course, or we will see very few TC mods, or the AIs will never handle them correctly...

4. None of the AIs build bases worth a gosh-darn. In my original articles about this, I described some easy, easy-to-mod concepts using textfiles that modders could use to design custom base layouts for AIs to read and then execute. Not one of the existing AIs has tools like this available.

5. Lastly, and most fundamentally... the best AIs of the bunch are already "smarter" than OTA in some respects, and rush better.. but they all attack very, very poorly. AIs need to read the FBI files of the units, weight the various speeds of units, and make attack waves that make sense... and, once again... are tied to what unit makers are doing, instead of specific mods. Right now, none of them can do anything smarter than send an occasional small dribble of units which die very quickly on anything like real defenses. None of them use air very effectively, and none of them can swim. I realize that both air and water are pretty tricky problems... but if I were y'all, I'd worry about getting AIs to properly attack on the ground first, before anything else. When i see AI keeping fast units near slow ones until within X distance of known enemy positions and THEN rushing, I will be impressed. Thus far, the AIs are more suicidally inefficient than OTA.




Overall, NTAI gets the highest grade. Alantai, I will give you props- when I started talking about all of this stuff, back before there was even a theoretical AI interface, let alone working AIs, I didn't expect to see that your work would be this successful. Quite honestly, I'm quite impressed, despite myself. In the time I've been gone, you've not only built something that's almost as smart as OTA, but you've given up the source. I really appreciate your dedication, even if your grammar is appalling

That said... what you've got falls far short of giving any decent player a good game yet. I'd rehash everything I said in my SAI posts, but basically it boils down to this: make it CHEAT. No matter how clever you make it, and how many CPU cycles you eat with these fairly-ridiculous redundant cycles checking many, many, many variables... it doesn't matter. I told everybody this back before there was an AI interface, and I'm going to tell it again- if you don't make it cheat, it will never give much of a game. OTA's AI was pretty stupid, and in many ways, the current AI is already better. But it is NEVER, EVER going to be smart enough to give a human a good game without cheating.

[Maelstrom]

To be fair, the AI's are still under development. But good points none the less.

[CrowJuice]

Well if you want your AI aponent to cheat then you can always give it a handicap boost in the lobbyclient. No need to code it in.

[AF]

These are points I've been thinking over and could ahve started on soem btu I've bene doign nothign on NTAI since I collapsed.

For water maps, I tried to have soemthign and got NTAI to build shipyards and the likes btu ti wasnt the sort fo thgin i should ahve added. I have in my mind an algorithm to give a ratio of water to land and fork the build trees to suit.

Construction: NTAI 0.3 will ahve no config files save mex position caches, and possibly learning files. NTAI wont work with your mdo unelss you give em an idea of what every single construction unit should build at the moment. In future I'm going to move from sayign AddTask("CORMEX"); to Addtask(mex); and let the AI pick the most suitable unit from the build tree then move it on untill the whole thing is totally abstract.

As for the commander thign, I'm goign to work on using a varied approach on building palcement, so that i can use multiple algorithms that all take advantage of the threat amtrix using the absic rules I set out for palcement in TAI ages and ages ago.

I'm going to include a multiple algorithm approach to scouting and attack too, using the tactical agents, my efforts so far have been aimed at getting the AI to build a abse without stallign adn havign all the basic stuff present.

The game crashing when the commander dies is not an AI bug, it is an engien bug, one that NTAI and OTAI suffer fromg reatly because they're the onyl AI's capable of using special weapons such as d-gunning.

The AI's cant cheat unless the player types ".cheat" otherwise any AICheat callbacks we get are null pointers, and making the AI say ".cheat" doesnt work either.

Making the commander cloak seems like a godo idea, I'll set it to check if storage is past a certain point then cloak as many units as possible startign with the commander, do soemthign similair to the metal maker AI.

The unti issuing commands problems however are a problem that lies at the core of the spring engine. The spring interface isnt always reliable. I cant queue up commands for example like I cna by holding shift, if I add the shift tag to the command ti should ahev the same effect, btu instead the command is ignroed compeltely and the unti stalls and UnitIdle never gets called. If I send a set fo 6 commands to a factory 3 for 2 types of untis, then not all 6 commands are recieved, soemtimes onyl 1 of those unit types gets queued. Sometimes UnitIdle is never called at all, so untis just stall after they're doen building, I have to write check routines to look for idle con units and kick them back into life. I remember JCAI had an extensive command checking system built into it before ti was even released to the community, and that complained a lot about units stalling.


All in all JCAI ahs its problems and zaphod is well aware of them, but zaphod has the spring engine to worry about and has said he's taking a lot of time away from AI development to focus on the engine. As such he's requested that JCAI not be included in AI comparisons as it isnt fair on him.

[Triaxx2]

Argh... I'm going to be as polite as possible, but there's an Anime vein bulging from my forehead.

If you are this concerned about the state of the AI, then write your own. Before telling us what we should do, try finding out what we can do.

[AF]

Quiet, he voiced an opinion and shoved everythign in a single post instead of spread across a forum.

He also hgilighted several thgins I hadnt thought of, and I'm grateful for that.

[krogothe]

Argh... I'm going to be as polite as possible, but there's an Anime vein bulging from my forehead.

If you are this concerned about the state of the AI, then write your own. Before telling us what we should do, try finding out what we can do.

QFE
Thanks for stating the obvious!

[AF]

Sometiems stating the obvious si needed. Besides he pointed out stuff that is of great use. And eh re-introduced himself. Remember thatt he forum was wiped, and the onyl copies of what eh said where at darkstars.co.uk archived, granted I was flamed for posting the backups, but he started the very first skirmish AI topic for spring, he was the first to discuss it, and I was the one who tried to carry on and discussed adaptive AI and got flamed for it. Granted those same ideas have cropped up in AAI, and A lot of what people said has since been proven wrong by NTAI.

For example commander use...

[krogothe]

well, but you gotta agree he did post 95% obvious, well known stuff
But honestly, im starting to swerve towards the buildtree side of AI, most good AIs i see in other games have a semi-fixed buildtree... Adaptative sounds fun but there are a lot of problems like nanostalling and stupid decisions that Im not entirely sure outweight the flexibility that system gives...
Time will tell!

[AF]

The problem that came with those systems was that they tried to run before they could walk. The buildtree system can be controlled fulyl by the author, and can eb migrated towards a semiadaptive system. The semi adaptive system was unable to cope by itself with base construction wihtout entering a rigid system of placement such as build layouts where a build layout would be made up of combos sucha s an HLT surrounded by dragon teeth.
The build tree system goes to the fulyl rigid part and mvoes towards the adaptive by taking the items and making them abstract and adding forks untill different parts no longer resemble a build tree at all but an adaptive algorithm.

The weights system is the nearest to the middle between adaptive and rigid build trees as it is constrained by weights but still uses an adaptive approach. It doesnt match a build tree that ahs been made totally generic and flexible though, but that would require much more work aswell as a whole set fo algorithms to classify a units build options.

[Triaxx2]

I apologize. I was a bit stressed and I over reacted, particularly to number three. It just seemed like he was pushing a little harder than could be resonably expected. How long was TA in development? And they finally figured out how to make it so easy to modify. I retyped that post three times. The first two times were much worse.

You're right, he does raise several interesting points, though I disagree with number two. I'm a big fan of TAFF, and if you forget to cover a metal deposit, even deep inside your territory, the AI commander will come after it.

As for base building, shouldn't we be happy that they're actually building bases?

As for attacking, I have to admit, this is a rather important problem.

And cheating... I guess we're thinking of two different methods of cheating. AF is thinking of engine cheats, I get the feeling Argh means OTA style AI only buildings.

[jcnossen]

Well I have to with krogothe here...

Like we don't know this...
We have enough people telling what is wrong already... and we are very capable of doing that ourself too.

[Argh]

@All:

First off, no offense was intended. This is critique- it's not personal. I think what you've been doing is far better than I really expected this early on.

I understand that it's frustrating to have an outsider point out these things, and if I had more time, I'd get down and dirty with y'all and help, instead of just opening my big mouth. I usually don't critique something I'm not prepared and willing to better. But, in this case, I can't. Sorry if it just seems like I'm a useless mouth, but that's just how things are.


Hopefully you will find some of the following points to be constructive follow-on, and perhaps more useful than my initial critique. I'm not trying to harm your efforts in any way- I'm trying to get you to think past the technical issues of getting things to work, and think more about what you want the final products to act like.

What I've seen here is a collection of AIs that try to use iterative processes to simulate intelligence, instead of a more rigid collection of rules that would allow them to build, attack and grow more effectively. For example, the AIs scan the terrain very rapidly, and then seek out metal patches for their first build decision. Almost all of the AIs can do that fairly well.

The only problem is... that it doesn't make any sense. A human player will scan the larger terrain, and then make strategic choices. Sometimes a Plant is the very best initial choice, for example, or a pair of Solars to provide enough Energy that the Commander can d-gun any attackers while rushing to the middle of the map and building a forward base. Worse yet... what a about a mod that uses Spring, but doesn't include any metal patches? What about maps that purposefully put the metal patches in very odd places, or doesn't include a single patch, forcing players to use Solars, etc., and Makers? What about a mod that doesn't include any resources aside from Buildertime and Workertime? How are any of the AIs available going to deal with these scenarios?

Based on how brittle the current ones seem to be... the answer is, "they won't". So... instead of trying to make the AIs so "smart" that they can handle every possible mod (which is, let's face it, impossible)... is to have a human being who knows a given mod's structure do it. No AI can possibly be built that will somehow figure out things like, "this is an artillery unit, that while poor as an attacking unit, will best work by staying behind a pack". That's a complex statement- and no AI is going to work that out for itself. Really- and if you want to argue that in pseudo-code, we can go (back) there. But the points I brought up the first time still stand. It is basically impossible to make an AI that can cover all possibilities. It is not impossible to make an AI that can follow instructions from modders writing scripts that will make the AI do certain, predictable things... that maximize their effectiveness.

In short... a really good AI isn't going to really out-think players. It's going to out-execute them, by using the brilliance of modders who develop successful canned strategies and techniques that the AI, with its superior ability to give orders rapidly, can execute and defeat players.


For those of who still think I'm just a pompous windbag, here's a typical example:

What's more difficult: coding a series of instructions that tells an AI that in certain situations, it should form certain units into a formation that maximizes their effectiveness, or building a scripting interface that reads and executes a script that goes something like this:

;//////////////////START FORMATION SCRIPT
If Attacking_State = True
{
SomeNumber = Random(10)
}
Else
{
Wait 30
}
This is grabbing a global, AI-wide variable- Attacking_State- which is determined by other, scriptable elements telling the AI when it should attack, and when it should be limited to defensive behaviors. If this variable = True, then this script will generate a random number from 1-10 and store it. That this number is an integer is assumed. If the global variable isn't True, then the script sleeps for 30 seconds.

;///FORMATION_SCRIPT
If Side_NameString = Core
{
Exit
{
ElseIf SomeNumber = 1
{
Start FormationBlock
Unit_NameString PeeWee = A
Unit_NameString Stumpy = B
Unit_NameString AnyOther = O
Do_Formation (block_size = 2, blank_exclude, vector_to_target)
{
.......A.A.A.A.A......
..B.B.B.A.A.B.B.B..
OOOOOOOOOOOO
}
}

Here we have a simple, user-configurable formation block that any modder can work with. SomeNumber is passed from the previous sub-script, obviously. FormationBlock is a hard-coded command, that expects users to name a variety of Unit_NameStrings, which correspond with the stored names of units from their FBI files (duh). Once the user has assigned alphanumeric characters to certain named units, including the special type "AnyOther", which is literally any mobile unit that can be used in an attack (yet another aspect of AI which should be in modders' control, not AI developers) the textfile then describes what the behavior of the block will be.

Block_size tells the AI to use a minimum spacing of 2 TA "squares" between units (to prevent units being too bunched up).

Blank_exclude tells the AI that if more Attack-capable units are available in the "pool" than can fit into the number of named slots, that they must wait and be sorted into another FormationBlock.

Vector_to_target tells the AI that the "top" line of the textfile that follows should be the "front" of the unit. There would probably be other variants of this command, to allow for formations that attempted to stay side-on to a vector but approach known enemy positions, etc., to provide modders with serious customizations and cunning weirdness.

So, the final result? This is a FormationBlock that can contain up to 7 PeeWees, with the PeeWees in the front rank, up to 6 Stumpys in the second rank, and up to 12 AnyOther units in the third rank. It's a nice, basic attack formation that actually makes some sense, not just a blob or silly dribble. Any point that gets attacked by a formation like this in OTA will probably take at least some damage. It is assumed that these formations will have to shrink if the individual units cannot path in the formation, but that's a problem that (so far as I can tell) has been mainly solved.

Once past an obstacle requiring the individuals to form a smaller line, the formation would re-form itself and continue moving- or not, depending on a script tag that would allow users to determine this sub-behavior... not the AI itself. That would make it possible, for example, for different results to happen depending on which random number was "pulled out of the hat" by this AI. Much, much more powerful than current AI designs, which try to make things "work out" with whatever random stuff the AI happens to build. Yes, it's more complicated, and modders would have to make pretty lengthy scripts for their mods, but it would beat the customization options available right now by a lot.


This is an example of what I want to see in these AIs as they grow up, guys. I want to see AIs with serious moddability, flex, and real power- the kind've power that comes from letting humans make real, creative control decisions, not just trying to have an AI that fits every possible scenerio, or can only work with one mod.

The best part? Such an AI would be easier to write than any other approach! Yes, easier. Why? Because "all" it needs to be able to do is execute scripts and then pass them on to the interface. Modders would provide the brain- the AI would, essentially, just be a virtual machine that executed the instructions. Sure, certain instructions would be fairly difficult, and yes... there's a limit to what behaviors could be non hard-coded... you can't possibly cover every base. But if you give scripts a certain level of flexibility, then modders could get things to work, through "perverting" the way that your script interpreter worked and "tricking" it into doing what they really need... just like we used to with OTA's feeble-minded AI...

Anyhow... I hope that the above feels more productive to y'all. Really, I'm not out to offend you... sorry if that was how it came across. I just think that the current efforts are really not going in the right directions yet.

As for the issue of cheating... I don't care if it's hard-coded into Spring or units that only the AI can build, like my old killer-uber-version of the Siege AI (which, if anybody here has TA:M, experience installing multipart TA:M mods, and wants to try out to see what I think is proper degree of difficulty, feel free to email me).

[AF]

AAARRGGGHHHHHHHHHH

no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no no NO!!!!!!

Have you read any fo the stuff gabba posted? Any of the NTAI X thread? I knwo exactly what I'm thinkign and how I want to progress. NTAI will learn, it will adapt by tiself, it may make mistakes a human would make and do silyl things but those will have consequences that will affect the next game along.

Your proposals would kill of fhwatever individualness NTAI had and whatever unpredictability it had. Are you aware of how learnign systems work at all? The general principle behind hwo AAI learns about tis mods? AAI is onyl told what the commanders untinames are for each mod and it has figured out all the rest by itself. And even then what it uses in one game afefcts the next, albeit it isnt perfect and needs a lot of finetuning but ti works when ti doesnt balls up.

You seem mroe itnerested in creatign an AI that simply works and fullfills a niche of being adaptive as in mdoders ahve full control. I disagree greatly, I want my AI to adapt an i foresee the workigns of hwo ti will work. I want an AI that will surprise the user, use suntzu tactics, be devious and express itself, I dont want a cold ruthless machine that follows a set fo rules. I dont want a basic state machine AI.

Our priorities in AI dev are to fix bugs and problems, increase stability and make the AI more robust, while adding minor improovements.

Submarine is workign on makign cosntruction better and building better bases.
Krogothe wants a better resourcing system, he's already posted shots of his code getting quit far in resources qucikly without using any metal extractors at all.
I'm working to make NTAI more robust.

If a map has no mex spots the following will happen.
OTAI will build metal makers
AAI will stall somewhat and eventually builds a metal maker.
NTAI lags and builds metal makers and ignores any calls for a mex to be built in the buildtrees, then booms as it switches to the metal maker based economy I outlined in its buildtree at lvl 2.
JCAI build metal makers.

I think zaphod and krogothe are wrong for saying you're stating the obvious as you've stated other things that arent obvious, which outweighs the rest but this last post has totalyl shifted.

What you are sayign is somethign I ahve already experimented. Anyone remember when I tried bidnign a lua intepreter to the GlobalAI itnerface so people coul code AI stuff in plaintext? And JCAI's config loader which zaphod attempted to add basic programmign stuff to liek if statements etc? Or my failed attempt to bind the TOOL to NTAI?

Remember what Zaphod rcently said about it? He said it became too complex and mdoders didnt udnerstand it because of new features? Seen GroundZero complainign about nto wanting to touch code when we suggest replacing fbi tags with an interpeter style system?

Would you be happy fiddling with AI profiles for mods, diffrent AI profiles even or modifying config files? I dont liek that idea and neither would the user. The user wants ease of use and a good game as quickly as possible.

Also I dotn like parsing text files, I'd rather automate building selection or hardcode it than write a complex parser to get it from files.

And do you remember veylon saying he was makign OTAI attack liek OTA's AI did? he deliberaty made his AI attack that way to emulate the OTA AI. And untill recently NTAI didnt attack at all, I didnt se eit as too high a priority adn whatever code I had wasnt working so I focused on building and cosntruction.
And did you see submarine saying he's constrained his AI to build small abses for debugging purposes?
And hwo i forced NTAI to scout mex positions because it was a quickfix at the tiem and I didnt wanna think about it?

[AF]

btw I have thigns such as HLT's surroundd by DT's sorted, I have an algorithm in mind that'd automate the process and work for a variety fo possible units. more on that later. I also ahev a set of dieas on a new building sytem that'd amalgamate all the different methods used and at the same time keep them seperate and take itno account the situation and location.

[jcnossen]

JCAI can be changed a lot through configuration files, not everything you say can currently be done with it but that's not the point. These make an AI very flexible, but need a lot of documentation to get other people contributing, and generally make the developer/modder have to balance a lot and spend a lot of time testing his scripts.

However, I've stopped working on JCAI now, and never will continue in this way because it is simply not the most effective method. It is very well possible to have AI's with learning behaviors and automatic selection of units and generally do all the balancing through storing experiences. Submarine has made a good start with this already with his AAI.

On the other hand, configuration scripts and cheating is a recipe for a fun AI, so maybe I should extend it just so it cheats. Then you can do things less efficient and code it in a more "fun-oriented" way

[Dragon45]

It would be somewhat trivial to create a cheating AI that follows a rigid, repetitive, base strucutre and attacking pattern and puts up a much better fight than any of the other AIs already made. But, it wouldn't be very fun.

[AF]

It would be easy to defeat once you figure dout tis weakpoint, highly predictable etc...

[jcnossen]

The idea would be to make it cheat more if it's too easy... besides it could be fun to change it to a cheating peewee-only AI or some other weird way of fighting :)

[Argh]

Why are you all so afraid of something that bloody well works?


I have a lot of actual experience writing scripting for state-based AI systems. I rebuilt, from the ground up, the entire AI schema used for Freelancer in the development codebase I built for that game engine- a task more complicated, in many respects, than writing a script for a halfway-decent TA mod's AI. I rebuilt Siege, because the original unit wasn't TA:M friendly, and it wasn't hard enough for me. It ain't scary, it's just time-consuming and requires a lot of playtesting.

So no, I'm not afraid of complex scripting hierarchies, setting up different variables to fine-tune behaviors, etc. If you'd like to see some of that work, please let me know, I will be happy to post practical scripts from a working game. Again, I'm not full of hot air- I've done this stuff as a game designer- and, as a designer, I want control.

I do not want some AI that doesn't know what to do with my units. I want an AI that does what I tell it to do. That way, I can build the mod and the AI as one piece. I know that this may not be sexy, but it's what I, as a designer, would want to work with. Not something that tries, and fails, to "figure things out". I want to be able to do something completely weird with the game design- something that is totally un-TA-like... and have it work, because I can control it.

With state-driven AI, this is at least theoretically possible. With "learning machines", it just won't work, period. Even if it's some weird combination, it's not very likely to work- I won't be able to predict the outcome of a given set of states.



I think that AIs that "learn" are just going to make the same mistakes over and over again, or just do random stuff that's never efficient. Based on what I've seen thus far, it's a lot of both. Sure, some of the worst of it can be taken out with (gasp) some hard-coded state-driven AI... like, say, making the Commander run away from my LLTs, instead of trudging forward and dying.

But there's a practical, fundamental limitation to learning systems- they're going to hit database limits very quickly and run out've memory on any practical level of implementation. Y'all have seen this happen- I've been reading enough of your posts to get that much through my (admittedly thick) skull. Not only that, but these things are surely the cause of some of the nasty crashes and relative lack of stability that I've seen in current AIs. I saw one post that referred to millions of iterations... just to scan for metal and make decisions about planting mexes. If that's just one map scan, how many millions more database entries, how much contextual detail will have to be assembled for an AI to "learn" anything that really matters? And what it "learns" will be so contextual that it won't be terribly useful, or so broad-based... that, once again, a simpler, scripted and state-based model would actually play a better game.

Let's take a simple case.

AI sends three units up a hill. My HLT kills them. What has the AI "learned"?

1. "I shouldn't send my units up hills". That's bloody stupid. That hill is mine, for all time.

2. "I should send more units up there next time". Pretty stupid, but it might work, with a reinforcement loop, it'll send a huge wave and take the HLT down, eventually. OTA more-or-less worked like that.

3. "I should send different units that way next time". Really, really stupid. Whatever it draws out've the "hat" is unlikely to be better in any fundamental way, unless used right.

And how does it figure out what "right" is? Same problems, only even more slippery logic-chopping. Maybe it'll get lucky, and send aircraft. But what does it "learn" from that? "Send aircraft against HLTs"? "Send aircraft against things on hills"? "Send aircraft any time ground units die attacking somewhere"? How many possible cases like this can you code for? And how long until, ultimately, you just end up with another state-driven machine?

...and that's it. No, you are not going to get it to be smart enough to say, "hey, that's a HLT, I should send planes". It might do it at random, but not on purpose. That's something a state-driven, case-driven AI might do, right off the bat, but a "learning machine"? Nope. Maybe after a few hundred cases are examined... and it may still not do it, because the code may reinforce the wrong "lessons". It's not going to go, "hey, I should build a plasma turret and out-range it", either- that requires a great big leap of intuitive logic- think about all of the choices involved there- where to build it, why to build it, whether it makes economic sense, etc.

Humans can do this sort've stuff- we can hold a very large, semi-abstract gestalt in our minds. Robots can't. They have to arrive at choices, ultimately, through randomness and rules. Which is why they aren't going to make this kind've leap.

Yes, yes... I'll go ahead and give all of you folks a freebie- if we let a "learning machine" play a very specific mod against itself for billions of games, maybe, just maybe, it'll figure out everything. The database will be hundreds of gigs, it won't run on anything but a refrigerator with multiple RAIDs, but it'll work. But that will take forever- and, in the end... it'll STILL BE A STATE-DRIVEN MACHINE. It just didn't have a human write the states!

And it'll be broken if you change anything about the game's rules, because that effectively makes it into a new game. New units? Broken. New resource rules? Broken. Changes to existing units? Broken. I should know- one of the first things I did with Spring was unzip XTA and boost the Commanders on both sides, for testing purposes. That made all of the existing AIs crash.

And the AIs that are getting built now, with the exception of AAI, are all at least partially working around this obvious, fatal flaw to some degree. Why bother with the half-in-half-out nature of things, when you can just skip all the bother, specialization, mod-dependency... and get right down to something that actually works?

I said all of this when Alantai first proposed what became NTAI, I'm still saying it now. I've built AIs driven purely by states that will kick player's butts. It's not hard. It's just a matter of thinking out the role of the player, the player's limitations, and adding enough randomness that the AI may have certain predictable actions, but it has so many that players cannot accurately predict its next move. You can't do it, though, with an AI that will not obey orders. You can't do it with an AI that tries to "get creative". Creativity is totally over-rated!

In the case of a good AI for a typical OTA-based game design, that means that the AI builds good bases, strikes with large, multi-type strike forces of proven usefulness, and attacks from random angles, so that players have a more difficult time porcing. And it needs to get a resource boost and Buildertime boost, so that it will produce units at roughly the speed of a decent human player, to make up for the fact that it will never attack efficiently. That's pretty much all that I expect. If it's clever enough to find high spots and put big guns there, great. If it's clever enough to use things like jammers, cloaking, comm-bombing, and other tactical widgets... superb. If it can do all of these things, and let modders completely configure it with scripts so that new mods come with nicely-tuned AI scripts... it's perfect. I don't care if it's "smart", and I sure don't care if it "learns".

The objective here should be to build something that will give players a good game. If you've lost sight of that, then you're probably never going to end up with something that's more than a curiosity- a fancy widget, not a working system for a practical game design... made by somebody else.

I want AIs to do something intelligent- which, by definition, is a human thing- not a robot thing, because of the practical (and very real) limitations described above. I want a randomizer that moves units around in a way a human decided was smart- because humans are the only thinking beings we have that can actually make these decisions. Robots can't. And I don't expect the current experiments to ever prove me wrong, either. I explained, in detail, why learning systems will never, ever be able to handle the complexities of a RTS with the capabilities of current home PCs behind them.

An RTS is a lot more complicated than chess, and even Deep Blue was... you betcha... a state-driven AI- not a "learning machine".

Sun-Tzu-like? Are you joking? What you've got isn't remotely acting on Sun Tzu's advice. Sun Tzu would not say, "hey, the Art of War is to attack with random things, make notes on where they die, and then attack with different things and see if that changes". Sun Tzu says the following:

Warfare is a great matter to a nation;

it is the ground of death and of life;

it is the way of survival and of destruction, and must be examined.

Therefore, go through it by means of five factors;

compare them by means of calculation, and determine their statuses:

One, Way, two, Heaven, three, Ground, four, General, five, Law.

The Way is what causes the people to have the same thinking as their superiors;

they may be given death, or they may be given life, but there is no fear of danger and betrayal.

Heaven is dark and light, cold and hot, and the seasonal constraints.

Ground is high and low, far and near, obstructed and easy, wide and narrow, and dangerous and safe.

General is wisdom, credibility, benevolence, courage, and discipline.

Law is organization, the chain of command, logistics, and the control of expenses.

All these five no general has not heard;

one who knows them is victorious, one who does not know them is not victorious.

Therefore, compare them by means of calculation, and determine their statuses.

The shorter, American version would be, "To win, know your forces, know your enemy's forces, and plan accordingly".

And no AI is ever going to do that anything as well as a human being. Period. At best, we can have AIs that have had human-designed plans designed into their stupid, state-driven little "minds". That cheat, and sometimes even win.

Any really decent AI is state-driven. HL2? State-driven. Heck, it even has pathing built in. Coders and mappers worked together to create the illusion of intelligence. Because, in the end, that's what we're going to get- an illusion.

Kohan II? A great RTS AI, by any standard. State-driven- oh, and it cheats, too. AOE? State-driven. And it cheats. Freelancer? State-driven. And it actually is dumbed down- if you make it perform as well as a human theoretically can, then humans lose- we're never as perfect as a machine, even a very stupid one.

There's a pattern here... how many big, successful and generally good AIs from commercial games do I need to cite? Why are all of these guys, who've made millions of dollars for their companies and thrilled players everywhere... wrong?