Skirmish AI: E323AI 3.22.4

[Gota]

The most important part is that the AI is configurable...
I am sure it is impossible to ask of an AI to play in every mod and determine on its own what units to use for what and how to counter each unit type...
An AI either needs to be made for one specific mod or needs to be configurable.

[hoijui]

it would be even better if we had a simple description fetchable by aIs, which comes wiht each mod.
eg:
unit A coutnered by unit B, ...

these things can theoretically be extracted from all hte unit specs and the rest of the data the AI alreyad has available, but it is hard to have a good formula to abstract that all, i guess.

... maybe?

[Error323]

Since previous three posts are related, let me share my thoughts on reconfigurability of A.I. I've been thinking about it quite a lot and came to the following conclusions. Note that these are not necessarily final and can be disputed =).

• An A.I. for every mod available in spring through a configuration file is virtually impossible. That is, the configuration system would need to be so sophisticated that you are basically designing a new programming language. Which would only create restrictions on an A.I.
• An A.I. for a certain subset of mods sharing the same goal can be achieved I think, this is what I strive for. The subset being BA and XTA for now.
• E323AI will (in the nearby future) use two configuration files: 1. Unit categorizations: (ARTILLERY, SCOUT, ANTI-AIR, etc) 2. Unit relations:(ARTILLERY > ANTIAIR, SCOUT > ROCKO). If no custom config is found it will create a basic config. This will be based on dps and unit features as defined by the mod.

In my opinion, the most general scripted A.I. should just be a solid framework. But for this I'd first need to know the ins and outs of the system. Using the knowledge that I have accumulated so far is spawning ideas from time to time :). Massively refactoring E323AI in a new branch.

[Masure]

Since previous three posts are related, let me share my thoughts on reconfigurability of A.I. I've been thinking about it quite a lot and came to the following conclusions. Note that these are not necessarily final and can be disputed =).

• An A.I. for every mod available in spring through a configuration file is virtually impossible. That is, the configuration system would need to be so sophisticated that you are basically designing a new programming language. Which would only create restrictions on an A.I.
• An A.I. for a certain subset of mods sharing the same goal can be achieved I think, this is what I strive for. The subset being BA and XTA for now.

Agree

[thesleepless]

how about the AI keeps statistics per mod of which units win against other units and uses that for planning?

eg.

UNIT 1, UNIT 2, 1KILLED2, 2KILLED1
FLASH, PEEWEE, 10, 2
JELLYFISH, SHARK, 10, 0
JELLYFISH, FLASH, 0, 5

so if the AI scouts and sees that the enemy has lots peewees, it knows that flash are good against them so it'll build some of them to counter.
and if the AI has peewees it'll try to keep them away from enemy flash
of course this doesn't help for non combat units like radars

or just use statistics like that for generating configuration files rather than having to generate them manually, they could then be tweaked, it should be the responsibility of the mod to have their own AI configs up to date IMO, of course the config files shouldn't be required, but allow for optimizing of the AI.

[hoijui]

the thing with statistics is impossible in practice, because of multiple reasons:

1. mods change, some more some less, but statistics from odler versions can not be trusted

2. for this to work well, you need A LOT of test games. it is not as simpe as: "unit A is good against unit X Y Z"
its rather:

Code: Select all

float isGoodAgainst(Unit mine, Unit his) {
   float res
}

3. not enough statistics gathered:
for this to wort, we would need hundreds of players playing the same version of the a mod for many hours/games, and gather the statistics over the net. everythign suboptimal rises the number of hours needed, like uneven player strengths, uneven terrain advantages, different terrain type distributions of the maps (flat, hills, mountains, sea), ...

in short, maybe microsoft or EA could do that.
best chance is running spring AI<->AI fights, if available with headless client, on huge server farms. though we would train the AI to win agaisnt AIs then.

[AF]

Hoijui what your saying is impossible has been seen done, in this very community, and at one point it was implemented in every major AI. NTai, OTAI, AAI all had statistics systems of the type your saying would never work, in fact its the major premise behinds AAIs construction tables.

The basic crude premise that if unit A kills unit B, then A is more efficient than B, and then the implications drives a lot of behaviours int he exisitng AIs. AAI for example can see that anti air killing an aircraft means that unit has a higher efficiency at killing aircraft and so that efficiency value rises.

NTai and AAI both learn through mechanisms like this, more so AAI.

[aegis]

almost nothing is a blind counter - every aspect of the unit's stats should be taken into account.

[Error323]

almost nothing is a blind counter - every aspect of the unit's stats should be taken into account.

Agree, not just who killed whom, but also visual information (the context) would need to be processed. And that is quite difficult, but not necessarily impossible. Although I'll stick with configuration files. The highlevel relations will be fairly effective I think.

[Error323]

Firstly great to see another AI in the making!

I think your raiding strategy is excellent and will work well against AI's and humans. In terms of AI vs humans can it use many different raiding parties? This could be particularly effective as micro management is one of the few advantages AI's can have over humans.

Can't wait to see it in action.

Thank you. What do you mean by different raiding parties?

[aegis]

microing multiple separate groups of units - humans can only be one place at a time, while an AI can micro many places simultaneously

[YokoZar]

microing multiple separate groups of units - humans can only be one place at a time, while an AI can micro many places simultaneously

Except in coop

[Error323]

Ah then yes, it definitly does that. You guys should see it in action :], its pretty fun to watch on e.g. Comet Catcher.

[hoijui]

yeah, i am sorry, saying it is impossible in practise was incorect. though, i am sure that nobody really though i meant impossible in practise, but impractical. It is impractical, cause i have never seen a test where AAI performs equally good or better then KAIK or RAI in the suported mods. AAI could possibly get better if it gets enough statistics, and if it does it in enough details. in practise, it never gets better, because one or several of the reasons i mentioned (and possibly others).

[AF]

The problem there is that AAI is more than a statistics engine, and how it uses those statistics also plays a factor.

For example, in the early days, when NTai used to be the top AI before KAI came on the scene and I left for lobby development, the reason NTai had such a huge advantage when it came on the scene, was more an ideological reason rather than how good it was at doing what it did. AAI and JCAI had base mentality. This as a result severely crippled those 2 AIs in the early days because all NTai had to do was expand until its economy outgrew the enemy, or it was simply too large.

I believe that this problem still exists in AAI, however submarine has managed to counteract this fatal flaw by improving other areas of his AI.

[grumpy_Bastard]

base mentality

Do they have statues on their ships?

[jcnossen]

JCAI had base mentality

Not by design actually, in fact the first version was a cell-based approach. It made small blocks of individual factories+solar and filled the map with it, but this was obviously very inefficient in terms of resource use. So I rewrote it to optimise more for resources, which in practice results in base mentality.

The problem with base mentality is that while a real player can optimise a base with extra nano stuff to push out lots of spam units, an AI would create a suboptimal base, and would have been better off spreading less optimal build locations accross the map.

The original idea of JCAI version 2 was that it would build multiple optimized bases, but I never got to that because the planning system was too complex for me at that time.

If I would write one now it would be totally different obviously, I would probably not even bother making defences. Error323 has a very good point about harrassing being very effective for an AI.

[AF]

Well the nearest to it would have been when my AI scouted mexes with zippers, blowing them up in the process, this is something worth looking into.

I agree with you, AAI was different in that were yours was a symptom of the initial building setup, AAIs base mentality made it so far in that even classes were named around it to an extent. Though submarine was the first really to tackle the issue of defence placement.

I remember reading strategy articles from OTA and reading that the whole map is your base and you should behave as if your eradicating someone in your own territory rather than extending your control out, hence why NTai expanded a lot better, and why I focused on optimizing this.

Jelmer, what would you do differently if you picked up JCAI again?

[Error323]

There's a looooooot of potential for aggressive expansion - The Joker

[Error323]

Hey Hippies,

Lately I've been wondering about proper data-structure management. As most A.I. developers of you know when e.g. a unit is destroyed a lot of tables need to be updated. So I've been thinking about that and wanted a structure where I could just perform this:

Code: Select all

unit->remove();

At which point all my internal data-structures would be properly updated. I've added the prototyping code as an attachment. Let me know what you guys think. I tried to keep it as simple as possible while still being able to see the real power of it.

-- Error323