Text originally written by David Sellick (Switeck@hotmail.com).
AI stands for artificial intelligence. It refers to the computer-controlled players in skimish games AND multiplayer games with computer players added.
"From time to time, people complain about the weather. But no one ever does a darned thing about it." -- Mark Twain
The ai in Total Annihilation was quite dismal in versions 1.0 and 1.1, and only slightly better in v1.2b1. With the v2.0b1 patch, the ai was improved but still not much of a threat in a 1 vs 1 ai game against a good player. Cavedog has considered improving the ai to be a low-priority goal in patches, and it's looking like the v2.0b1 patch may be the best ai that cavedog makes.
In the earlier ai's (before v2.0b1), what made the ai dismal was that it was limited to only 5 factories and 6 construction units. It poorly managed its resources and was often unable to constantly run even that pathetic amount of production. It would try to attack with ground units on a sea/island map. Or it'd build metal makers on all-metal maps. Or fill its base up with crawling bombs that never moved.
In later versions the ai was not quite so bad, but still shared many of the same problems. With v2.0b1, it looked like Cavedog *almost* knew what they was doing. Finally they'd made an ai that could build a huge base in a reasonable amount of time AND build a large attacking force. No longer did it build many of the absolutely useless units like lots of radars and crawling bombs. I even lost a game to it on Metal Heck while playing with 2 people vs 3 ai's over the internet.
Despite its many improvements, the v2.0b1 patch added NEW problems to the ai. Since that patch allowed cavedog's add-on units (and even 3rd party units) to be used by the ai, the ai would build many of the new units without limit. Although this was ok with units such as the Core Sumo, this was worthless with the Arm Marky - causing the area around the advanced k-bot labs to become so crowded that the labs could no longer make any more units. With the fixed base units, this was even worse: The ai didn't know when to quit building naval metal makers, naval missile towers, and naval laser towers.
Cavedog's built-in AI is simply shameful in v3.0 and v3.1 of TA:CC. One would expect that with each patch to the game that the ai would slowly get better. But the ai went from decent in v2.0 to terrible in v3.0 and almost as awful in v3.1. The v3.0 patch was the first patch to use Core Contingency which introduced many new units into the game that were specialty units that were almost all unuseable by the ai.
A major complaint of the ai in v3.0 and v3.1 is that it builds a base and lots of construction units but very few attackers. It's like the ai wants to play a game of sim-city instead of a wargame. With the addition of TA:CC, all the new units that CAN be built tend to "water down" the ai. A BIG problem is the unit count, with 70+ new units it is impossible for the ai to build a reasonable number of any particular unit.
All the ai versions would (on very rare occassion) build a nuke silo or an antinuke silo. But never would a nuke be fired nor would the antinukes shoot down nukes shot in its direction. A hacked unit that acts SIMILAR to the real unit is required for the ai to actually shoot nukes and possibly antinukes.
The AI plays the map, not the other player. Metal spots (mostly) determine where it builds metal extractors and thermal vents are where it sometimes gets sane and builds a geothermal plant. Its base ends up being built around whatever features are on the map, with no consideration for where its enemy/s are. It doesn't consider what the player is doing to decide what to build next. It looks for the nearest enemy unit to its attack force, that's almost all it knows to do about the enemy player. If you do something unexpected, it falls apart. (The "Solitaire" bug or "Sim-City" bug)
All the ai versions also have their attacking ground units "sleep" after destroying all nearby targets. The ground units quit moving for a couple of seconds, making them easy pickings for things like guardians. In my opinion, this is probably the ai's BIGGEST weakness - but it is one that is unchangeable by ai profiles. (The "Coffee Break" bug. Maybe it's a union thing...)
All the ai versions would have their ground forces concentrate their firepower on 1 unit. Often, the ai ends up shooting at resources (like a closed solar, which takes quite a lot of damage to kill) while nearby base defenses pound away on them. (The "Tunnel-vision" bug)
Sometimes, because of the terrain or DT, the unit the ai is trying to destroy cannot be hit - but the ai doesn't quit trying to kill it. A good example of that is when peepers are landed in the middle of the square columns on Metal Heck before the ai's ground force arrives. Until a Merl or similar unit that can shoot over hills arrives, the peeper is reasonably safe. Another good example is a sub close to the shore of the enemy base - ground units will wade into the shallow water trying to get to the sub, but that only makes them vulnerable to torpedoes. (The "Why won't it die?" bug)
If the unit the ai is trying to destroy runs away, the ai's ground forces will chase that 1 unit around the map until it either gets destroyed or it gets about 2 screen lengths away from the ground force. Note: flash tanks are really good for doing this. (The "Pied-Piper" bug)
Any of the ai's units that are not already shooting at something sometimes fire on whatever enemy unit gets into their range. (The "Free Will" bug) Whoops! Maybe that's not a bug. Probably good the game has that bug! ;)
If a friendly unit is near where another friendly's weapon hits, they often take spash damage. Although this is not a bug in itself, the ai doesn't try to stay out of the line-of-fire. Construction units are especially bad about this - maybe they're suicidal... (The "Friendly Fire" bug)
If the ai's commander is damaged, it stops where it is for up to 15 seconds. This makes it very likely to be hit again, since it's not trying to get away. Worse still, if the ai's commander is being hit very quickly over and over again by multiple units, it doesn't even shoot its wimpy laser at the target it just twitches until it's no longer being fired at or (more likely) it dies. 3 flash tanks shooting the ai's commander at one time are good at making it wiggle helplessly till it dies. (This is just a "Gone Stupid" bug.)
After many attacks and retreats, the ai's ground force gets smaller and smaller. Makes you wonder if the ai is becomming pacifistic. This ussually happens after the ai's base has been left alone and it's had hours to build up without its base getting bombed. This is because the ai is at or near the unit max. The lower the unit max, the worse this problem gets and the quicker it occurs. The ai doesn't avoid building a base containing so many base buildings that it cannot build any ground forces - this is because the ai doesn't know what the unit max is! It could be only 100 units max, and the ai will still try to build a large base. ("Make peace not war" bug.)
Massed aircraft are considered by many to be the most powerful attacking force in the game, yet rarely does the ai have even 3 aircraft working together. The ai's aircraft wander alone randomly around the map. Only if the aircraft stumble accross an undefended unit are they likely to successfully destroy it and survive. Never is more than a modest air defense needed to prevent the ai's airforce from destroying a base.
The ai doesn't build ENOUGH resources quickly enough to keep up with its rate of consumption - often it has few solars and metal extractors to run 3 or more factories and 8 construction units.
A key AI problem is that some units aren't useful to the ai. The ai will build multiple radars right next to each other, or build metal makers when out of both metal AND energy. This compounds the ai's weakness in resource-gathering ability - already LOW on resources, the ai generally wastes what it does have on units that it doesn't know how to use.
Without modifying Total Annihilation (other than OFFICIAL game patches), if you wanted the ai to give you a good fight in a skirmish game, you either have to take on 3 ai's vs you (or worse odds) or restrict yourself to give the ai a chance (no nukes, berthas, dragons teeth, aircraft, etc, etc).
Now, there's an alternative: because Cavedog made TA easy to be changed and added to, the ai can be changed as well! In the absence of an offical Cavedog fix to the Ai problems, we can design our own AI profiles which influences many things that the computer does. Just by eliminating the useless units (to the ai only!) the ai can be improved over what cavedog has made. And by balancing the useful but expensive units, the ai can be made even better.
I've discovered that almost every time I eliminate units so the ai no longer builds them, the ai generally gets better. Or, if I add in whole groups of units the ai tends to become slower in attacking and base-building.
My ai profiles attempt to fix the problem by changing what the ai can build and how often it can build it. This doesn't permanently modify the game but it does fix some of ai problems in the game. The patch is totally compatible with TA, and can be used in multiplayer games. What's more, if you put an ai into the multiplayer game it is controlled by YOUR ai profiles, not the host computer's! What this means is your ai may be better than anyone else's in the game.
My ai patch tries to fix the problems not caused by the underlying ai engine hard-coded into the EXE. There are still problems in the game that prevent the ai from playing a good game EVERY time it plays, like when it builds its vehicle plants with the exits blocked by walls - because the ai engine controls WHERE it builds, my ai profiles only control WHAT it builds. I do not claim my ai is unbeatable, but players will find skirmish games against the ai more of a challenge.
The ai's are simple text files that can be viewed and edited with almost any word processor, including Wordpad and Notpad. All the ai's go in the AI directory under TOTALA. If the standard install for TA was done, all the ai files are in the C:\Cavedog\Totala\Ai directory. Cavedog DOES NOT create this directory for you nor will there be any ai files in it unless you place them there, this is the directory you have to create to change the ai.
In the (unlikely) event you wanted to remove the ai profiles so the game uses the original built-in ai profiles, either delete the files in the \Ai directory *or* rename them or move them to another directory.
The map files themselves determine which ai profile that the computer will use on each
map. This is a single line in the OTA file of the map:
aiprofile=default;
Note: if the maps are stored in UFO file format (or even HPI or CCX), they *still* contain OTA files. The only difference is that the OTA files are compressed inside the UFO file.
In TA:CC there are many standard ai profiles that a map author can use for their maps: Acid, AirBattle, Default, Hover, Krogoth, Metal, Missions, SeaBattle, Urban, and Waterwrld. All are ordinary text files that contain what the ai is allowed to build for those map settings. Most maps will work ok with one of the above ai profiles, but putting in the wrong one can be worse than none at all.
There's nothing worse for the ai than being told that the map is a green land map (DEFAULT.TXT) in the OTA file when there's water on it and it should probably use AirBattle or SeaBattle ai file instead. Trying to flash-rush from one island to another just doesn't work too good. ;)
*ANY* map can benifit from an ai profile designed specifically for it or for its type (water/land/metal/wind). A few maps need something more for the ai to attack before the 30 minute mark - that's where a modified ai is really needed!
The ai text files use simple commands to tell the ai what it can and cannot build. Most such commands only affect 1 specific unit, but there are a few universal values that can be used to affect groups of similar units or units all on one side. Sadly, the universal values aren't as useful as they might seem - because they often affect TOO much.
Units are refered to by abbreviations made by Cavedog or 3rd party unitmakers. A table of all the units and abbreviations is a good thing to have to figure out what an abbreviation is for a certain unit or vice versa. The abbreviation's first 3 letters almost always (except in the case of a few 3rd party units) tell which side the unit is made by - either ARM or COR. And the total length of the unit abbrieviation is 8 letters. Ussually, the name of the unit becomes the abbreviation for the unit - such as ARMFLASH or CORCAN. Other times, the abbreviation comes from the unit's function such as ARMHLT (the Sentinel laser turret). The rest of the time, you just have to wonder what the people at Cavedog were smoking: ARMCROC (I thought Crocs were Core units!), ARMTHOVR (a throw-over?), CORAPE (Core can build apes?), CORGATOR (sounds amphibious?), CORSEAL (I assume this is a naval unit?), CORSS (nazis?), CORTHOVR (whatever it is, Core's got one too!), CORUWMEX (underwear mexico?), CORVROC (well, roc is a mythological flying bird so this is some kind of flying unit?), CORWIN (but not CORLOSE?).
Limit tells how many of a particular unit to build and always has the form:
LIMIT unitname # (with a number from 0 to at least 99)
- example:
Limit ARMMAKR 0
means the ai is not allowed to make any Arm metal makers.
(Note this isn't the same as the Arm Moho Metal Maker or Core metal maker!)
The effects weight has is a little harder to understand. If the weight command isn't
used then I presume the game uses a default weight of 1. (I'm *REALLY* not sure on the
default weight, so I try to weight everything!) The Weight command increases or decreases
the probability that a certain unit will be built NEXT and always has the form:
WEIGHT unitname # (the smallest usable number is 0.05, the largest is probably 255)
-example:
Weight ARMFLASH 9
means Flash tanks would make the vehicle plants seem like flash tank only plants.
(this might be part of a flash-rush ai.)
Another "command" seen in many ai text files is 2 divided-by signs together
"//" on the start of a line. It tells the ai to not do whatever's on this line
and is just info to read if you're trying to understand what the ai does.
example:
// Nuke by the 10 minute mark!
(doesn't do anything, but sure looks good. :)
There's even divider commands to separate different parts of the ai text file for easy setting, medium setting, and hard setting. These are the "PLAN diff" commands. If you want to include parts of an ai file that are common to all difficulty settings, that can be done by putting the commands BEFORE the plan sections. example:
weight ARMFLASH 9
plan easy
// total pushover, doesn't build anything it might accidentally hurt you with.
limit ARMFLASH 0
plan medium
// it might try to attack you...
limit ARMFLASH 10
plan hard
// Plan to lose!
limit ARMFLASH 99
(So, for the above example, all difficulties weight flashes to 9. But the different skill levels only allow the ai to build so many flash tanks at one time: 0 for easy, 10 for medium, and 99 for hard.)
If for any reason a similar command is repeated twice in an ai profile, like:
limit ARMFLASH 0
limit ARMFLASH 99
the TOP command would be the command the ai uses (UNLESS they're under differnt SKILL
settings) - and no flashes would be built. Although you'd be a little crazy to have that
kind of repeated lines in your ai, universal commands such as:
limit plant 10
(Limits TOTAL number of factorys/plants the ai can make to 10.)
could override later commands like:
limit ARMAAP 12
(Limits Arm's advanced aircraft plants to 12.)
That's all the commands I have. There's nothing there about not building something until the ai has enough energy/metal. There's also nothing there about NOT building something if the ai's under attack. The original Cavedog-made ai profiles do not use reasonable weights OR limits on units. This is why I say the ai can be improved over Cavedog's but only so much. Because the ai will always be a little random in what, when, and where it builds. And it'll almost never build something right when it needs it most.
However, if something is weighted VERY low (I.E. Weight ARMGUARD 0.05) then that item will most likely only get built if the construction units/buildings have nothing else they are allowed to build. So when all the resources are finished, THEN my ai is allowed to build guardians which are very expensive metal-wise.
Weights seem to work better when placed at the top of the ai profile. Since the ai profile is read from top to bottom, if 2 commands change the same thing then the TOP command would be the one the game uses.
All this is not enough information to make a good ai, however. That is best done by trial and error, as mine has over the last 6 months.
I ask myself that question a lot:
Is it an ai that attacks early?
Or a early bertha-builder?
Or an ai that builds a well-defended base?
Are its ground forces mostly tanks, kbots, or both?
Does it build lots of aircraft?
What about an ai that will regularly commander-rush you?
These things can all make an ai BETTER, but NONE of those are what makes a good ai!!!
A good ai is one that can get resources quickly and uses all its resources to further increase its growth AND attack the enemy. The way it attacks the enemy is just the details! If you don't have the resources to run your war machine, your war machine doesn't run.
An ai can be made to take almost all of its starting resources and make flash tanks out of them. This could make for an ai that flash rushes quite well, but its later attacks would dwindle in strength or at least not grow very quickly. After finding out how to defeat it once (hint: try building some HLT's or LLT's with DT around them...), it'll quickly become less and less of a challenge - meaning that it's not a good ai.
That's what the ai in Cavedog's v3.1 patch seems to do... ;)
But that doesn't work either, because it's very hard to attack the enemy with solar panels, metal extractors, and construction units. The ai must slow down its rate of growth to build defensive and offensive units as well. A good ai must use its resources wisely!
If an ai is wasting metal, that's part of a potential attack unit that *COULD* have been made to attack the enemy. If an ai is wasting lots of energy (like +200 energy a second or more), that *COULD* have been turned into metal makers that *COULD* make the metal to make a potential attack unit that *COULD* have been made to attack the enemy. Even having a construction unit or factory not doing anything is wasteful - because if they weren't needed, more attack units *COULD* have been made instead of those worthless units.
Yes, and that's the problem. If the ai could build a huge super-defended base while launching massive ground attacks, large air attacks, and firing berthas and nukes - all in 20 minutes - it'd definitely be a kick-ass, uh... I meant good, ai. So, unless we make an ai that cheats, (well more than it *ALREADY* does...) we have to settle for less. Maybe it can do all that by the 1 hour mark instead of the 20 minute mark. But if it builds a tiny airforce instead, the massive ground attack, berthas, and nukes might be ready by the 40 minute mark. If nukes are left out, that time might drop to 30 minutes. And if all that is wanted is a massive ground attack, the ai can pull that off in 25 minutes. If you settle for a smaller ground attack made up of just tanks and no kbots, that just might occur in under 20 minutes. This doesn't mean that the ai won't do all those other good things, just that they won't happen until later.
You'd think so, but that sort of balancing act is both impossible (as long as the ai is still alive anyway) and unhealthy. If the ai needs its production to run constantly at peak output, all you'd have to do to drastically slow it down is kill a single solar panel. The ai would then require more energy than it was producing. Since it had no energy stored away for a rainy day, metal extractors would quit making metal and factories and construction units would be slow to complete their build tasks for lack of metal AND energy. The resulting imbalances that these cause are extremely erratic - going from 0 energy often up to max energy, and metal increasing and decreasing rapidly as factories finish units. Such complex behavior can be described as chaos theory based on the butterfly effect, and is best left for calculations on a Cray supercomputer. In short, it's too difficult to do *AND* it's not useful.
(This is starting to sound like the difficulty of riding a unicycle on a tightwire in an earthquake WHILE someone's shooting at you...)
There are no magic numbers here. But hitting 0 metal isn't good and hitting 0 energy is MUCH worse.
Early on, the ai's metal should rapidly decrease to just above 0. After that, it's personal preferance and what you want the ai to do - so long as stored metal stays just above 0 and just below maximum.
If the ai does hit 0 metal, it should not stay there very long. A example of staying at 0 metal too long is what happens when the ai tries to build multiple guardians at once - that can keep the ai from building anything else for a long, LONG time (30+ minutes even). If it were working on only 1 guardian at a time, the 1st guardian could be finished and be useable before the other guardians are built. A base with 1 finished guardian is much better than a base with 4 unfinished guardians when enemy ground units come knocking. (An unhatched egg is no chicken!)
For the same reason, energy should be used at a rate so as not to use up all the energy in storage. Later on, some energy surplus should be made to cover possible energy "spikes" caused by d-gunning, laser weapons firing (including bertha-like weapons), and metal makers turning on.
If your ai's strategy relies heavily on lasers, MUCH more excess energy is needed than if your ai is almost laser-free. Since Core leans towards lots of units with lasers that need energy, Core should produce more energy than an equivalent Arm.
In the LONG term, the ai should use about as much metal as it's making and use LESS energy than it's making.
Cavedog installed some fail-safe ai routines in their executable so that if (more like
WHEN...) the ai runs out of metal or energy then it builds whatever metal or energy
producers that it can. This is actually quite bad for us ai profilers, because while the
fail-safe routines are in use the ai is ignoring the ai profile weights on units. So a low
energy fail-safe tells the ai to go build some solars, windmills, or tidal generators. A
low metal fail-safe tells the ai to build metal extractors or metal makers. If the ai has
already reached its max limits on energy providers or metal providers, it pretty much just
gets stupid if the fail-safe modes kick in.
And if the ai is out of energy, having 10+ construction units all trying to build 10+
solars at once won't help. Another problem is that 0 energy causes the metal extractors
and metal makers to quit making metal but NOT quit draining energy. Once the metal reaches
0, the ai often mistakes the energy crisis for a metal crisis and builds more metal
extractors (or worse yet, metal makers) to "fix" the problem, when it really
needs a couple solars.
Another problem is the fail-safe routines don't always shut down when no longer needed, the ai may make solar after solar after solar even though it has max energy and much higher energy production than it is using. This could also mean you've weighted solars too high in your ai profile! A similar problem can happen with the metal extractors.
I believe there is a routine in the executable that checks to see if the ai has the metal and energy to build a particular unit - if not, it often doesn't build the unit -- even if it is the unit that it desperately needs. My offering of proof that such a routine exists is that the ai is "reluctant" to build high-cost items like a fusion reactor, geothermal plant, or advanced factories when it is low on resources. I haven't determined exactly how the ai decides that it doesn't have enough resources, but think it's resources it has stored plus the resources its making. Whatever calculation it uses, it doesn't seem to do a good job because it almost always ends up running out of resources. Perhaps that's because the ai doesn't consider what the other resource-consumers are doing (or WILL do!) and instead assumes that the one resource-consumer can have ALL the resources.
Despite this looking like a minor problem that can be corrected with a good ai profile, this is can cause the most frustration.
The ai doesn't count a unit towards its LIMIT maximum unless that unit is completed. So, if 2 advanced aircraft plants are complete, many more advanced aircraft plants may be started up to the limit of the ai's current basic construction aircraft. If the ai has 4 basic construction aircraft at the time, the probable maxumim of advanced aircraft plants is 6.
I call this the "OVERBUILD BUG", but you'd never know about it unless you're messing with the ai profiles in the first place - that's why I didn't mention this problem earlier. I personally don't see this as much of a problem, EXCEPT with the moho metal makers on nonmetal maps - 1 of them is PLENTY enough, 2 or more is disaster (that's why I weight them VERY low...).
Otherwise, having the ai overbuild its base - exceeding the normal limits is probably ok. The ai would most likely only do that if it already had a good resource base and probably would be able to support the extra resource strain. If the ai wasn't doing well, the chances of this happening are unlikely at best - so it won't hurt the ai much then.
Now, you can plug numbers into your ai profile for weeks on end and not know why you don't get the desired results. Although the numbers the ai uses are only "suggestions" to it, over very long periods of time calculations can be done to determine the results. Even if you don't know the exact value, it's helpful to have an idea what the chances of a particular unit being made is. To do this, I introduce the term build or production probability - a percentage calculated by weights on each unit produced by a factory.
For instance, the Arm Vehicle plant has:
Construction Vehicles (weight=3 limit=4),
Flashes
(weight=9 limit=no limit!),
Jeffys
(weight=1 limit=0),
Samsons
(weight=1.5 limit=no limit!),
and Stumpys (weight=0.5
limit=no limit!).
The total weights add up to 15, BUT since Jeffys are never made (limit=0), the actual weight total is 14. Build probability will be calculated by taking the weight of each unit and dividing it by the ACTUAL WEIGHT TOTAL.
The Construction Vehicle will have a 21.4% build probability.
The Flash will have a 64.3% build probability.
The Jeffy will have a 0% build probability, since the limit is 0 on them!
The Samson will have a 10.7% build probability.
The Stumpy will have a 3.6% build probability.
If you add up 21.4% + 64.3% + 10.7% + 3.6%, the total is 100% as it should be.
After the limit is reached on Construction Vehicles, the production probability
changes. Total weight is now only 11 since Construction Vehicles are no longer a
consideration.
The Flash will have a 81.8% build probability.
The Samson will have a 13.6% build probability.
The Stumpy will have a 4.5% build probability.
Adding 81.8% + 13.6% + 4.5% = 99.9% (with a rounding error to account for the missing
0.1%)
So, this also adds up to 100%.
What these numbers mean is that until the construction vehicles max out, the vehicle plant should make 6 Flashes, 2 Construction Vehicles, 1 Samson, and maybe a Stumpy - or another flash for every 10 units the vehicle plant makes.
It's very hard to tell if an ai will make more bulldogs than stumpies, because those come out of different plant types. It also gets complicated if there's 4 of one plant type but only 1 of another and 2 of a third type - to predict what the unit percent composition made by all the factories will be. However, the unit build probability for each factory type can be quite helpful in creating a more balanced attack force.
This same build probability can be applied to ALL types of construction units, even the commander. The reason to check construction unit build probabilities is an ai profile usually sucks because its RESOURCES and FACTORIES are not weighted at balanced levels. The basic construction units need the MOST careful build probability balancing. They are responsible for building much of a base.
UNFORTUNATELY, the ai fail-safe routines prevent the weights you put on the construction units from being anywhere close to accurate. This is where you have to use rediculous numbers to get semi-acceptable results: like weight 9 (or more!) on geothermals.
Firstly, I tell you that the ai's build pattern is random. Now, I'm telling you it's actually clockwork. When, where, and what the ai builds is based on the map, what the ai has already built, and what the ai's current resources are. Even extreme weights on units, both very low (like 0.05) and very high (like 9) are ignored by the game if any overriding condition occurs (like fail-safe ai routines). If the ai is ALLOWED to build it AND the executable tells the ai that it NEEDS to build it NOW, that's what the ai will build regardless of how seldom it's SUPPOSED to be building it.
Anyway, this is the basic pattern that the build units follow:
Commander:
Basic Construction units:
Advanced Construction units:
OR, how come my CORE ai smokes my ARM ai really bad?
ARM's units, as a whole, move quicker than similar (if there are any!) CORE units. This applies to construction units as well. One possible reason why the ARM ai seems to have an advantage over a CORE ai is CORE takes just a little longer between each building project - therefore, after 10 minutes of being a little slower each time - CORE ends up behind in production. Note: That's only my theory. :P
A simpler reason is that you assumed ARM and CORE could be told to build alike with the same results. CORE's units are often more expensive, so CORE may end up out of both energy and metal while ARM has plenty of both - despite almost identical metal/energy incomes.
If you spend more time "tweaking" one side than another, you *SHOULD* expect this result. If you play ARM more, you'd probably know what a good attack force for ARM is but might not for CORE -- so although the CORE builds lots of attacking units, because it doesn't build a good MIX of attacking units, it seems to lose more battles than it should. If you really like one side over the other, you may unknowingly "stack the deck" in its favor.
Another reason for the imbalance is what I call the "Coffee-Break" bug, where units stop moving after killing all immediate enemy units. If the attack force is under attack by a guardian or punisher, it's likely to take heavier losses if ARM than CORE because CORE's units *generally* have more armor.
There's something subtle going on with the ai profiles, despite their apparent simplicity. It's not so simple that you can weight flashes and vehicle plants really high and end up with a (good) flash-rushing ai. Almost every change affects something else! If vehicle plants are weighted to 9, that will mean that the construction units will build these in greater preferance over resource providers. So the ai might end up with low resources meaning it'll have very few vehicle plants built (since it had little resources to build with) - even by the 20 minute mark.
The computer isn't slowed down much by a LONG ai profile - like one over 20kb long. But it probably doesn't hurt to keep the ai profile as short as possible, leaving comments about how the ai works out of the ai profile itself. You could make an ai template laying out all the unit limits, and copy and paste from it into your ai profile. That way you don't have to memorize unit abbreviations.
Weights seem to be more effective if they're put near the top of an ai profile. Even Cavedog's ai profiles seem to follow this logic. Perhaps the ai is more likely to act on the first thing it reads in the ai profile!
You cannot know if an ai will be any good unless you test it. Playing against it over and over again may seem like a decent testing method, but it's almost impossible to play the same way twice. If your testing is to determine if minute changes result in an improvement for the ai, that will most likely be too well hidden in random variables introduced by such a testing method. On the other hand, the ai may play BETTER against another ai than a player - who won't do what it's expecting. So even if an ai is good versis other ai's, it may suck against people! Get the ai good versis another ai before testing against people, or they may just laugh at you.
Once the ai gets good versis the ai, then test on live victims - uh, I mean people... ;) Don't be surprised if a good player sends you back to the drawing board when your ai proves less successful than you hoped, and don't be afraid to ask people what the ai should've done to be even better -- even if they lost to it! BTW, treat people kindly for helping you test your ai and always try to thank them for their time. (Otherwise, it may get harder and harder to find lab rats. ;)
Generally, I test on big maps that can handle a lot of players on it at once. For my default.txt ai profile I use Greenhaven most because it is both big and loads fast.
I have quite a few ways to test the ai - and most are unbiased:
Running a lot of tests may help you improve an ai profile, but if you don't know what you're looking for (or AT, as the case may be) the tests are probably a waste of time. Heavy useage of the +view # cheat is a MUST - otherwise you can only guess what the energy and metal state of an ai is. Factories quit producing mobile units when less than 100 metal is in storage. If metal makers are blinking it ussually means metal consumption is above metal production. An attack force that runs around in circles seems to be the result of metal/energy shortages for that ai. An ai that does great because it always starts with 10k resources might be really wimpy with 1k resources - ai's ussualy have a resource range that is "optimal" for them, normally this is near the 10k mark. Large increases in energy consumption often means the ai either fired a bertha, turned on a moho metal maker, or started building energy-intensive unit/s. Likewise, large metal consumption increases often means something like a guardian or advanced plant is just being started. Temporary increases in metal or energy production almost always means the ai is reclaiming trees, rocks, or debris on the map. Large, sudden permenent increases in energy means a geothermal or fusion reactor was just completed. It's notable that the ai can turn on and off a few units that has an on/off switch even WHILE the unit is being built. So the moho metal maker can start providing extra metal (and tremendous energy drain) the VERY moment it is started - long before it is finished. It's one of the ways the ai cheats, but ai profiles alone won't stop that.
If you're in a skirmish game with 9 ai's (all ARM, for instance) and NONE of them build a advanced vehicle plant before the 20 minute mark - and you WANT them to, you'll probably need to increase the weight on the advanced vehicle plant. The case may be that it's because all 9 ai's stayed out of (or very low on) metal and/or energy and could have nothing to do with the weights on the advanced vehicle plant.
For the default.txt ai profile, whenever the ai builds too many solars and metal extractors before its first factory it ussually loses to one that didn't. Also, if its first factory is an aircraft plant it ussually loses as well.
Important ai information to record:
It's hard to tell if an ai profile is improving just by testing it against itself. So, test one side at a time against the other side WITHOUT changing the other side. This can be done by copying and pasting all ARM entries from 1 ai and all CORE entries from another ai into a single ai file. It really pads the ego to watch your CORE ai totally mow through Cavedog's original (v3.1 patch even) ARM ai. Whoever said CORE can't rush effectively probably hasn't seen a Storm and/or Instigator rush! If your 4 CORE ai's can kill 5 original ARM ai's in under 20 minutes on Greenhaven with only 1k resources, consider your ai at least decent! (Mine can *sometimes* do that.) BTW, It's wise to team up with the (probable) winning side.
Most maps fall under the standard general categories of Default, SeaBattle, AirBattle, and Metal - but some need specific ai profiles made just for them. An extreme example is an all-water map with very little land. Seabattle assumes that there is land to build a good sized land base, particularly solars, metal extractors, hovercraft and aircraft plants. Lacking that, the ai will build very slowly - if at all - and will be easily beaten. The basic ai profiles categories are too vague to cover many types of maps. So things to consider when making an ai profile are:
My ai has no balance of base defense vs attacking force - it is almost pure attacking force. It builds a token base defense consisting of a couple berthas, a very few guardians, some flakkers, and quite a few defenders. Only the defenders are built early on - they are a holdover from the long-ago popular strat of c-napping the commander before he could build much. I figure defenders are cheap enough that they won't slow production down to a crawl while still providing some defense. It might seem that the base is very vulnerable to an early rush, but that's probably when it's the most densely defended by mobile units. Later on, when the ai's forces are attacking elsewhere the ai's base can be pretty easily stormed with ground forces.
Getting a well-defended base early on is of low priority for an ai. To do so will slow or even stop its exponential growth for many minutes. Let the mobile units defend the base early on, and let the construction units build good base defenses only if they have nothing better to do.
My ai's weights go from 0.05 to 9, where a weight of 1 is assumed to be average. A weight of 9 is used to almost force the ai to build that unit instead of anything else and build it quick. A weight of 0.05 is for stuff I don't want the ai to build until AFTER other things are built. When the unit LIMITS are reached for high-weight (1-9) items, then and only then should the very low-weight (0.05-0.2) items be built. I tried a weight of 0.01 for units, but they won't get built at all - the ai rounds weights that low down to 0. The same weight and limit tricks can be used on attacking units to assure that you get frontline units quickly but not too many - and that you later get supporting units in decent quantity once the ai's attack force is large enough to defend them. An example of this is Flashes for frontline units and Merls for supporting units. Flashes are good, but too many just get in the way of one another. Merls are also good, but putting them on the frontline will make them seem useless.
Putting an upper limit on every base building is a must, otherwise once the ai reaches unit max and after each attack the ai will replace some or even all of its attacking units that got killed with base buildings. This results in the ai's attacking force growing smaller and smaller. At that point, nuking some of the ai's base literally pisses it off because it is freed up to make more attacking units! For the same reason, even the attacking units themselves need an upper limit to prevent overpopulation. More than 30 flash tanks just get in each other's way being unable to fire on targets. For my ai, I presume that the game's unit max is somewhere in the 150 to 300 range. If the unit max is lower, the ai will become pacifistic (not attacking with ground forces) much earlier. On the other hand, if the unit max was 500, the ai would never really utilize the extra unit slots to make its attack force OR base huge.
My rule of thumb for the ai is simple - for ordinary nonmetal maps, the default.txt ai will suffice. But if there's anything unusual in the map, the ai needs to be modifed to take advantage of it - be it high winds, narrow passes, lots of water, scarcity of metal, even a change in unit max. Any map can benifit from using a modified ai profile instead of the original ai profiles in TA:CC, but some maps almost demand a special ai profile for the ai to be effective at all!
My ai should work fine with the v3.1 patch. With unit pathfinding improved, this should allow the ai to get its attack force to your base even faster.
David Sellick (Switeck@hotmail.com)