AI Config files?

AI Config files?

Here is where ideas can be collected for the skirmish AI in development

Moderators: hoijui, Moderators

Post Reply
User avatar
hughperkins
AI Developer
Posts: 836
Joined: 17 Oct 2006, 04:14

AI Config files?

Post by hughperkins »

Question

If you wanted to tell an AI how to behave using config files, how would you design the config file?

Background

Realistic Spring AIs are primarily rule-based, to minimize resource utilization.

Rule-based AIs are fast, untiring, and can be everywhere at once. The downside is that they must be taught everything, via a set of rules somewhere.

Rule-based AIs can learn, but humans have some advantages for learning, such as communication with others via bulletin boards, chat etc. AIs can carry out statistical analysis more accurately than us, run simulations overnight whilst we're not watching, but ultimately the win or lose of an AI is down to human tweaking.

By making AIs easily configurable by humans, it's possible that they could become more powerful.

Clearly the design of the config file will drive the design of the underlying AI engine.

Note that we could build AI training facilities to generate the config file automatically, eg for different mods, and/or test them.

Some thoughts

An AI should have multiple opening gambits. Ideally, the config file(s) should be able to handle this.

An AI should be flexible to be able to react to what the enemy is doing. Ideally, the config file(s) should be able to handle this.

It's ok to specify specific unit names within the config file. This is precisely the type of information that humans are good at determining and communicating. We could provide self-training methods to the AI. Such methods would provide as a result specific unit types under specific conditions, and record these in the config file.

An example of a config file could be:

Code: Select all

<config>

<unitcategories>

<unitcategory name="groundmelee" comment="these are used for assaults along the ground">
<unittype name="armstump" />
<unittype name="armsam" />
<unittype name="armmav" />
<unittype name="armbulldog" />
<unittype name="armyork" coment="phalanx" />
</unitcategory>

<unitcategory name="level1mobileconstructors" comment="this allows us to use the variable level1mobileconstructors.count in the production rules>
<unittype name="armcom" />
<unittype name="armcv" />
</unitcategory>

</unitcategories>

<buildinggroups comment="this is to group things like laser towers and guardians together">
<group name="defensivestrongpoint" intergroupspacing="1000" comment="we want th>
<unit name="armguardian" quantity="2"
</group>
</buildinggroups>

<productionrules name="basicrules" comment="things to keep us alive">
<when variable="energystorage" type="lessthan" value="1000" comment="if commander dies">
<build priority="10.0" unit="armmstor"/>
</when>

<when variable="metalstorage" type="lessthan" value="1000" comment="if commander dies">
<build priority="10.0" unit="armestor"/>
</when>

<when variable="level1mobileconstructors.count" type="lessthan" value="1">
<build priority="10.0" unit="armcv"/>
</when>
</productionrules>

<productionrules name="level1tankrush">

<build priority="2.2" unit="armstump" quantity="10"/>
<build priority="2.2" unit="armsam" quantity="10"/>
<build priority="2.0" unit="armcv" quantity="1"/>

</productionrules>

<productionrules name="level2tankrush">
... some stuff here to build mobile fusion reactors, bulldogs, farks etc
</productionrules>

<productionrules name="groundtoair">
<build priority="2.2" unit="armsam" quantity="10"/>
<build priority="2.2" unit="armyork" quantity="10"/>
...
</productionrules>

<overallcontrol>

<when type="always">
<useproductionrules name="basicrules"/>
</when>

<when type="equals" variable="currentframecount" value="0">

<probabilitychoice>
<possibility probability="0.7">
<useproductionrules name="level1tankrush"/>
</possibility>
<possibility probability="0.3">
<useproductionrules name="level2tankrush"/>
</possibility>
</probabilitychoice>

<when player="enemy" variable="airgroundattack.percentage" type="morethan" value="30">
<useproductionrules name="groundtoair" />
</when>

</overallcontrol>

</config>
Clearly this config file is not self-consistent and incomplete, and actually trying to design a config file that is flexible and reactive is really tough

It would be useful to be able to configure attacks:
*squad creations: 2 squads of tanks? 1 giant squad? 1 squad of light tanks, 1 squad of heavy tanks and artillery, and 1 squad of bombers?
*squad tactics and formations. Just bunch everything together? Use an arrowhead formation of tanks with a line of lugers behind?
*tower attack / creeping artillery. It can be very effective to bring up some groundmelee really close to the enemy base, and build a guardian or two just behind them.

Code: Select all


<positions comment="we're going to describe a decent tower attack position here">
<position name="nearenemybase" comment="we specify what we mean by near enemy base">
<conditions>
<distance fromtype="area" from="enemybase" type="lessthan" value="500" comment="areas are defined from mapping"/>
<distance fromtype="unitcategory from="enemydefense" type="morethan" value="300"/>
</conditions>
</position>
</positions>

<attack name="towerattack">
<squads>

<squad name="constructors">
<unitcategory name="constructors" quantity="3"/>
</squad>

<squad name="groundmelee">
<unitcategory name="groundmelee" quantity="10"/>
</squad>

</squads>

<attackformation>
<squadformation distancefrompoint="0" type="line" spacing="30">
<squad name="groundmelee"/>
</squadformation>

<squadformation distancefrompoint="200" type="line" spacing="30">
<squad name="constructors"/>
</squadformation>

</attackformation>

<execution>
<order sequence="1">
<moveto target="nearenemybase" />
</order>
<order sequence="2">
<build unittype="armguardian" quantity="2" />
</order>
</execution>
</attack>
As I wrote this message, it became clear that writing such a config file is non-trivial. It's perhaps too ambitious to think that one can abstract this out into the config files whilst keeping flexibility. To some extent the design of the config files itself predefines the behavior of the AI.
User avatar
jcnossen
Former Engine Dev
Posts: 2440
Joined: 05 Jun 2005, 19:13

Post by jcnossen »

As I wrote this message, it became clear that writing such a config file is non-trivial. It's perhaps too ambitious to think that one can abstract this out into the config files whilst keeping flexibility. To some extent the design of the config files itself predefines the behavior of the AI.
I agree. I did a similar thing for JCAI: https://taspring.clan-sy.com/svn/spring ... ta_arm.cfg for an example, but indeed it is very hard to make it both flexible and powerful. The only part that I think worked pretty well for JCAI was the attack group code and specification, I never really got the resource management working right.

Making it very flexible basically results in some kind of programming language, and at that point it might be better to pick a language suited for AI programming and use that...
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Post by AF »

I'm sorry but I felt like I was going to choke seeing that xml example. Its fine wanting xml as a format to load and save data via a program but to the vast majority of users it's as intelligeble as set of unlinked Asm x86 assemblies.

So if you todo this you're going to need a GUI based editor. People just wont take the time and effort todo it.

NTai has a simple system with a single file full of tags and then just textfiles of comma seperated keywords for buildtrees, yet most people dont bother with it, they cba learning it, so I'm considering a GUI editor to simplify the process.

And I would suggest that anything devised would be AI independant as in discussed with other AI devs then output and generated in a form all AIs can read.

And btw, NTai outperformed the rule based AIs for 9 months untill it was beaten by the second KAI rewrite, which beleive it or not used hardcoded buildtrees rather than construction rules, hence why you can see 5 or 6 KAI blobz on FU, and why KAI was only able to support arbitrary mods after the 3rd rewrite. OTAI also changed from rule based and started adding features to support non rule based build plans...
User avatar
hughperkins
AI Developer
Posts: 836
Joined: 17 Oct 2006, 04:14

Post by hughperkins »

jcnossen wrote:Making it very flexible basically results in some kind of programming language, and at that point it might be better to pick a language suited for AI programming and use that...
Yes.

Do you have a particular programming language, or type of language, in mind?
And I would suggest that anything devised would be AI independant as in discussed with other AI devs then output and generated in a form all AIs can read.
Agree.

How would you create an AI-independent config file?
And btw, NTai outperformed the rule based AIs for 9 months untill it was beaten by the second KAI rewrite, which beleive it or not used hardcoded buildtrees rather than construction rules
What do you mean by hardcoded buildtrees?

What does the KAI third rewrite use?
OTAI also changed from rule based
What does OTAI use now?
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Post by AF »

The 3rd KAI uses basic rules for universal mod support combined with an economy manager.

Basic rules are a necessity for universal build routines in order to identify generic types of units and to construct freeform mod independant buildtrees.

As for AI independant, as in all AIs use some type of data so they all agree how its to be formatted and generated then they all load and save from the same place and format. I and veylon had such an agreement with metalmap data, and we planned further format sharing but veylon stopped work on OTAI.....
User avatar
jcnossen
Former Engine Dev
Posts: 2440
Joined: 05 Jun 2005, 19:13

Post by jcnossen »

Problem is that further conventions for AI data probably will also require similar implementations (because they implementation and script is very much linked together, that's why hugh is discussing the format).

If at least one AI would be able to actually solve this problem, then a universal format can be discussed but it's pretty useless before that.
User avatar
hughperkins
AI Developer
Posts: 836
Joined: 17 Oct 2006, 04:14

Post by hughperkins »

Ok. just so you know, when I say rule-based, I mean in contrast to an AI that has feelings and emotions, intuition. Kindof a nebulous concept admittedly.

An AI with intuition just "feels" that building a metal extractor right now is "right". It gets that feeling of "something's wrong I know it" when the enemy starts attacking, even though the enemy is not on the radar yet.
User avatar
hughperkins
AI Developer
Posts: 836
Joined: 17 Oct 2006, 04:14

Post by hughperkins »

jcnossen wrote:If at least one AI would be able to actually solve this problem, then a universal format can be discussed but it's pretty useless before that.
The question comes down to essentially: how does one represent knowledge? Clearly a rather hard problem ;-)
User avatar
hughperkins
AI Developer
Posts: 836
Joined: 17 Oct 2006, 04:14

Post by hughperkins »

Let's assume we represent the knowledge as C++/C#/Java, any thoughts on this?

Things that would be good:
*transparent
*concise
*obvious parallel between the code and our own way of thinking about knowledge

Here's an attempt:

Code: Select all

workflow.AddBuildPriority( 1.4, new ConstructionVehicle(), 1 );
workflow.AddBuildPriority( 1.2, new Radar(), new SpacedBuildingPlacement( 300 ) );
workflow.AddBuildPriority( 1.2, new MobileGroundAttack(), 20 );
workflow.AddBuildPriority( 1.2, new MobileGroundToAir(), 20 );
First parameter is priority, second is unitname, third is quantity or filter. Filter returns yes or no. The third parameter could arguably be a power measure instead of quantity, ie if one specifies 1000, the AI might build 6 rockos or 4 stumpies.

This is supposed to say:
*first thing you need to do is build a vehicle plant
*then, if this is a good place, build a radar
*at the same time, start building ground attack and ground to air vehicles.

This assumes the AI knows how to build mexes and solarcells, which clearly either it doesnt, or it's hardcoded somewhere. The decision making process for mexes and energy should be exposed here because it's crucial to success, and because there's no obvious answer, it all depends on your strategy of the day.

Trying to implement mexes and solarcells within this current framework shows straightaway the weakness of this implementation: prioritization is not a fixed list, but needs to itself change according to the situation and what the enemy is doing.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Post by AF »

Firstly, C++ would require a JIT compiler be integrated into the AI binary.

Java would require JNI bindings plus a way of calling Java from C++ which isnt very nice from what I've seen nevermind JNI bindings.

And our C# bindings arent portable.

And your representation of knowledge is more accuratly knowledge within a context, so it would be more accurate to call it data.

And I doubt such a setup as your last example and the third parameter, would proove popular with people spending there free time. Heck people find AAI config files and simple lists of unitnames seperated by commas confusing.
User avatar
hughperkins
AI Developer
Posts: 836
Joined: 17 Oct 2006, 04:14

Post by hughperkins »

Storing knowledge as C++ or C# is what is done currently. "Storing knowledge as C++ or C#", is typically referred to as "writing a program". Why not just call it writing a program? Well, it's another way of looking at the same problem. Sometimes that can help generate new ideas.
User avatar
AF
AI Developer
Posts: 20687
Joined: 14 Sep 2004, 11:32

Post by AF »

I thought you meant dynamic storage and not hardcoded storage.
Post Reply

Return to “AI”