[3.1+] NullBot: an adaptive skirmish AI

[NoQ]

Thanks (:

Uploaded v0.5.

Changes:

• The AI now has two personalities: MG/Cannons Rush AI added, that also follows the rushy FRCFF build order and uses howitzers as long-range artillery and HEAP bomb VTOLs.
• The AI is now able to choose randomly from several uncomparable weapons of one damage class, (for example HMG and MRA, or assault cannon and HPV cannon supercyborgs), also applies to bodies (Python and Scorpion).
• The AI now uses super cyborgs.
• NullBot now uses free trucks to finish unfinished structures and help build things.
• More changes in micromanagement; more often regroups; now VTOLs try to destroy anything that attacks them as well.
• Since #3050 is now fixed, workaround for it was removed. The AI no longer has any troubles with building modules.

[zany]

I tested this and it was working for about 25 mins then the AI stopped making things since it ran out of power then it was easily overrun.

[aubergine]

The regrouping feature is cool ... until they try regrouping near a choke point and you end up with some units travelling half way round the map. On a game I just played against 3 nullbots (I was cheating to survive LOL) several groups got caught at the same choke point and suddenly there was a huge pile of them there all trying to regroup. The game crashed shortly after that

[NoQ]

I tested this and it was working for about 25 mins then the AI stopped making things since it ran out of power then it was easily overrun.

Hmm, if it were a bug, the AI would have stopped much earlier. It is some usual battle report?
Also, how exactly did it manage to run out of power?

until they try regrouping near a choke point and you end up with some units travelling half way round the map

Chokepoint isn't really necessary, i just switched to a bad regrouping algorithm, will switch back the old one soon

The game crashed shortly after that

Where Is My Crash Report???
Well, not that i can actually analyze it ...

[NoQ]

Uploaded v0.6.
Changes:

• A lot of bugfixes. Fixed irrational group behavior noticed by aubergine (it's still far from perfect, of course), and hopefully fixed the trouble reported by Per (added necessary checks to this place).
• New "Flame" personality: a flamer spam AI. Not very refined yet, especially in its research path. Uses RFRC->cyborgs build order.

[Iluvalar]

The true flamer path isn't RRFRC or RRFFRC ? Droping the mg and taking a little risk to be rushed in order to make a near perfect research for the rest ? I'm just asking...

[NoQ]

The true flamer path isn't RRFRC or RRFFRC ? Droping the mg and taking a little risk to be rushed in order to make a near perfect research for the rest ? I'm just asking...

Hmm, i don't really understand what exact strategies you are referring to You want the AI to go straight to research module with the second lab

Anyway, v0.7 uploaded.

Changes:

• Quite a lot of bugfixes, including a fix in the new faster adaptation algorithm.
• No longer rely on safeDest(), because it doesn't report dangers the player doesn't see (and the AI is supposed to know this sort of things by design).

[Iluvalar]

I guess the flamers are OP since so long that rushing in the middle of the enemy hardpoint with outranged and weak vs stucture units look like the way to go ? . The real path for the flamers is quite techy. The idea is to force the enemy to attack you before you research too much. Seems like even the legendary NoQ dont not that path .

No, you stop after the sensor, because you then have the flamer and the power module to rush. That's why you push your luck by building a 3rd lab asap. To resume the already started lab line and take the maximum advantage of it. I guess that in pure duel, that one is less efficient... So after all, you might not want that path...

[aubergine]

It might be worth limiting the max group size (if not done already). In a game I just had against nullbot there were like 60 VTOLs sat at one of the nullbot bases, seemingly waiting for the remaining VTOLs to be produced to reach the group size required to start attacking.

Also, land units seem to do a "death dance" when they are under artillery fire - they keep retreating, then changing their mind and start attacking again, etc. The result is that they never get to attack anything and the artillery just mows them down as they run back and fourth not knowing what to do.

And build priorities after your base is attacked might need revising - eg. there's lots of rebuilding of research labs when that's probably the last thing you need building after your base gets attacked.

If all the tank factories get destroyed, but there's some cyborg factories left, they never make engineers = one dead nullbot. If the AI decides trucks are needed, it should check whether there are any tank factories left and, if not, start recruiting engineers at a cyborg factory - they can then build a tank factory and things go back to normal.

Maybe building some air defences *before* the enemy attacks with VTOLs would be a good idea?

Overall though, it's coming along very nicely!

The flamer nullbot is very good at taking out other AIs (like you say, the other AIs have no micromanagement yet so flamer wins).

[aubergine]

In your adapt() function, why are you checking number of enemy repair/construct droids?

And your becomeHarder() function definitely needs some upper limit set.

[NoQ]

there were like 60 VTOLs sat at one of the nullbot bases, seemingly waiting for the remaining VTOLs to be produced to reach the group size required to start attacking.

Agreed, i already planned splitting VTOLs into groups, but didn't come to make it yet.

Also, land units seem to do a "death dance" when they are under artillery fire

Not sure how exactly can i fix it, but i'll have a look. The main problem is we don't really know if it's artillery that is firing. Also, the group needs to be packed before attacking a well-defended arty site, so regrouping can't be thrown away at this situation.

And build priorities after your base is attacked might need revising - eg. there's lots of rebuilding of research labs when that's probably the last thing you need building after your base gets attacked.

Probably. They are currently just repeating their initial build-up.

If all the tank factories get destroyed, but there's some cyborg factories left, they never make engineers = one dead nullbot.

Agreed, i'll fix it.

why are you checking number of enemy repair/construct droids?

Because engineer and repair cyborgs can be used as meat shields against pure rockets or cannons, even if the enemy doesn't use any other cyborgs. This also happens a lot when playing with the classic Nexus AI, who mixes repair cyborgs into attack, even though he acquires more cyborgs for defense a bit later. Anyway, a bit more machineguns is almost never bad.

And your becomeHarder() function definitely needs some upper limit set.

Probably. In an 1-hour game the group sizes change from 6..10 to 16..30, so in ~6 hours every group will be as big as a unit limit. Ok, right. Agreed.

Maybe building some air defences *before* the enemy attacks with VTOLs would be a good idea?

Agreed. Even better, it can be done as an adaptation procedure, cause we see if our enemies are making VTOLs.

[aubergine]

Not sure how exactly can i fix it, but i'll have a look. The main problem is we don't really know if it's artillery that is firing. Also, the group needs to be packed before attacking a well-defended arty site, so regrouping can't be thrown away at this situation.

Try something like:

Code: Select all

var foo = 123; // some attk distance threshold above which we assume artillery / missiles
eventAttacked(victim,attacker) {
  if (distBetweenTwoObjects(victim.x,victim.y,attacker.x,attacker.y) > foo) {
    // artillery fire
  } else {
    // run away
  }
}

Probably. In an 1-hour game the group sizes change from 6..10 to 16..30, so in ~6 hours every group will be as big as a unit limit. Ok, right. Agreed.

It was a 2 hour game IIRC. The flamer and MC nullbots were amassing VTOLs (flamer more than MC).

becomeHarder() gets called every 6 mins, so that's 10 times per hour. MAX_WARRIORS = 42.

Also, looking at the code, there doesn't seem to be anything that limits droid production, particularly not VTOLs. So MAX_WARRIORS has no effect on droid production.

[aubergine]

Easier way to detect artillery fire:

Code: Select all

eventAttacked(victim,attacker) {
  if (attacker.type==STRUCTURE) {
    // assume artillery fire? obviously full of fail if the structure is a flamer bunker...
  } else {
    // run away
  }
}

[NoQ]

Yeah, good point with arty; this doesn't solve the second issue though. What exactly are you going to do when you are under artillery fire? Attack and probably just sacrifice some tanks or retreat and regroup? And where exactly should you retreat? And if the arty is hitting your base instead? Any of those outcomes are better than the current behaviour though. Well, i'll make something as soon as i come up with something.

One thing you're probably missing in your VTOL mass discussion is that VTOLs are not affected by group management at all; they all belong to a single VTOL group. I'm already working on it.

[aubergine]

If under arty fire then prolly best thing to do is meat shield some cheap droids ahead of your main group - ie. get arty to fire at useless stuff and while it recharges the main group can get closer. I guess sending VTOLs in to attack arty would make sense, but easily thwarted by AAs around arty sites.