Tactical Combat AI Mod

[harpy eagle]

So it considers potential damage to HP of higher value then to armor...

In a sense it treats damage to armour and shields negatively, since the amount of armour and shields a craft has reduces it's priority as a target.

That makes sense of course but why not move right in front of the target and shoot from there to avoid missile travel time taking more then one turn?
They have range, space to move to and no reserved batteries to shoot them while moving

In all other occasions, the ships seem to move first and ask - I mean - shoot questions later (this was the issue with the bomber/carrier/fire-arc case) so why not here as well? That is why I was thinking this might be a bombardment standoff scenario of sorts

In previous versions of the mod, ships just move into attack range of their target and then stop. This is what allows missile ships to hang back in the case of fleet battles where other ships can tank for them.

The attack range function is one of the oldest functions in the mod and it has a bunch of hardcoded multipliers. Now that the AI can estimate the level of hostile PD though, I've updated it to make missile ships get closer when there is a lot of hostile PD present.

The missile cruisers in that test case you seem to benefit quite a bit, and actually kill most of the gremak fleet. They still lose, but given that the gremak fleet has a pretty high level of PD and they are armed with only missiles that seems pretty reasonable.

[harpy eagle]

Also, the latest version introduces a pretty significant change to how range affects the priority of launchers and hangars. The priority of a target for a missile launcher or a hangar is now multiplied by an exponential drop-off based on it's estimated missile/craft survival rate.

So for missiles, if the estimated survival rate is 0.5, then each turn of distance away beyond the first reduces the priority by half and targets within launch range do not get this multiplier.

For fightercraft, the fact that a round trip is required is also taken into account, so the range is doubled, and so targets within 1/2 the strike distance do not get this multiplier (since that is the longest single-turn round-trip distance).

This means that if the opponent has no PD, the multiplier is independent of distance.

Fightercraft also retain the pre-existing priority multiplier that reflects the fact that attacking craft far away prevents them from making more attacks while in-flight, and the lowest of the two multipliers are applied. They are not stacked on top of each other to prevent the algorithm from becoming excessively greedy with respect to target distance. Plus they are also kind of separate concerns.

Fightercraft are no longer prevented from attacking targets that are too far away, however if there is a lot of PD present the exponential drop off does encourage them to take distance into account much more strongly than in previous versions of this mod.

Since this is also applied when deciding to reserve interceptors, the AI is much less willing to reserve them for bombers in far away carriers when there is hostile PD present. However, it does take into account the fact that said bombers are likely to travel closer once they've launched.

[harpy eagle]

A small change that seems to have a significant impact on how effective the AI is at PD: ships with interception warnings are now moved by the AI last (402490c).

[harpy eagle]

Implemented retreating logic (49d9637):

• The AI now decides when to retreat ships based on an estimate of the total combat power of all allied ships vs the combat power of all hostile ships
• Unarmed (or disarmed) ships that are not severely damaged now only retreat if the AI thinks it is outnumbered 2:1 1.5:1. This means that the AI can now attack defended planets without all the transports running away at the beginning of combat. Unarmed/disarmed ships that are severely damaged always attempt to retreat.
• Armed ships that are severely damaged may retreat only if the AI thinks it is stronger than it's opponent and if removing those ships will not swing the balance of power.
• When the AI orders a general retreat (such as when either the player or strategic AI chooses autoretreat), the AI will attempt to retreat all ships at the same time. This means that if there are any ship types that take multiple turns to retreat, other ships will continue to move forwards and fight to cover them.
• The AI may also decide to order a general retreat if it thinks it is outmatched between 3:1 to 5:1, depending on a couple of factors: the presence of a friendly planet, and the proportion of its combat power that comes from immobilized ships and starbases.
• When retreating, ships that can cloak attempt to do so.

I think this mod is nearing completion. I've hit all the items on my TODO list and aside from bugfixing and any small improvements that might cross my mind in the near future, I do not have any more additions planned.

EDIT: well, other than allowing ships to chose tracking objects as their move target, but that requires C++ support.

[zolobolo]

Wow, you have really crushed this topic
I hope you and the DEVs will have a chat about releasing the content as a patch as is - everyone should experience the AI like this

You have probably noticed that I have started a new test game with all the factions this time around not just the imperials and colonials.
Will report if I find anything major

Do you think you will try your hand at the strategic AI as well?
With you skills, you could make even normal difficulty a survival story

Let me just say this again: the AI now auto-plays a lot of balanced engagements better then when I am manually controlling them! Your change to the retreat behaviour makes rocket heavy ships retreat from battle when they are out of munition, and since their combat effectiveness increases dramatically at the next turn this in by itself would be a game changer - and there are like a dozen such improvements! Having a force with superior numbers or tech is now a must if you do not wish to gamble

Thank you for all the effort you have poured into this mod!

[harpy eagle]

Thanks, I did put a lot of thought into many aspects of the AI's decision making and I'm really happy with how it turned out as well.

That said, this mod definitely improved a lot thanks to your feedback, especially regarding handling of interceptors.

Now, strategic AI is a completely different beast. I'm very lucky that tactical combat in this game has certain properties that make it possible for the kinds of decision making algorithms that I used to perform well, while also having enough depth to be interesting and fun to play (so kudos to the game design).

Basically I decided on a single goal for the AI: reduce the enemy's ability to deal damage as fast as possible, and did everything I could to make the AI pursue that goal as aggressively as possible. It uses a very greedy algorithm that doesn't think very far ahead, for example (well, I am limited in the variables that I can have persist between turns).

I don't know for sure how well that approach would transfer to something as open-ended as strategic gameplay, where making plans and sticking to them is rewarded more.

[zolobolo]

That is a good point - tactical engagements are by nature a limited affair that lend themselves very well for modelling

Guess on the strategic level there are multiple scripts controlling the behaviour of the AI that would need to communicate with each other...
Thus the topic can and probably should be segregated into various sub-topics like: research, resource, fleet and planet MGMT. Optimizing any one of the smaller topics increases the overall performance by its nature

That being said, in my opinion you have already addressed one of the weak spots of the strategic AI with the retreat logic: ship and thereof force preservation.
The AI tends to throw away a lot of its ships on unwinnable engagements and end up in between 0-15 ships at mid game independently from difficulty and faction played. In my new game with mixed races, it can already be observed that the AI tends to have more ships to command around due to retreating from unwinnable institution: this might seem like a tedious mechanic at first as the AI now frequently plays brave sir robin: but it is no problem in my opinion as it does not hinder progression of an invasion and the enemy force needs to automatically leave the system if they run out of planets

Another surprising side effect of the retreat logic are retreating pirates and Harpies - which I found hilarious when I first saw as I invaded a pirate effected system and half of their fleet just went up and "retreated" into a nearby colonized system of mine

[harpy eagle]

I agree, and some basic build order optimization would probably go a long way to help the strategic AI.

It kind of sucks that the AI has so few ships left by the mid game. I find after a while my games start to become stale since once all of the AI empires run out of ships, basically nothing interesting is happening in the galaxy anymore.

Having the AI not throw ships away needlessly helps I'm sure, but I've also noticed that the AI tends to be always short on minerals, and by the mid-game it's ship production falls off a cliff. It doesn't take too long afterwards for the AI to run out of ships. Meanwhile I'm the only one left with a navy

Changing the difficulty level just makes it harder to get to that point, but once you get there, the game just grinds to a halt and there's nothing interesting left to do. I don't know if that's happened to anyone else. I haven't really been good at sticking with my games so I've only played a handful of them that far.

Another surprising side effect of the retreat logic are retreating pirates and Harpies - which I found hilarious when I first saw as I invaded a pirate effected system and half of their fleet just went up and "retreated" into a nearby colonized system of mine

Heh, I kind of like that behaviour, for pirates. Harpies probably shouldn't retreat though.

[harpy eagle]

Looking at a game I'm in right now, I think a big part of the strategic AI's mineral problems is that it tries to build too much at once. Like an AI that has no minerals and barely any navy left compared to it's nearest enemy... is trying to build four fleet bases at four different planets *facepalm*

Anyways, that is probably a topic for another thread.

[zolobolo]

Looking at a game I'm in right now, I think a big part of the strategic AI's mineral problems is that it tries to build too much at once. Like an AI that has no minerals and barely any navy left compared to it's nearest enemy... is trying to build four fleet bases at four different planets *facepalm*.

Your are spot on

And I can help you out if you want to know what happens in late game in any difficulty level: if you wait long enough fleet carriers and super dreadnought will phase out all other ships as only these are produced. Thanks to your mod, the life-cycle of earlier designs has expanded into the mid-game, but it is only a matter of time for the old ships to be eventually replaced

The main problem as you have mentioned is the high priority of building fleet bases
It depends on the difficulty (resource bonus ) when this hits, but when it does that is the mid-game wasteland you have described.
Most factions have lost most of their ships until that point and were going for 50-100 turns practically without any ships
Even if priority of fleet bases is reduced, though the tendency to build the biggest baddest ship available will also deplete resources (this is the endgame slug)

I have made a couple of suggestions to prevent the above from happening, such as limiting all type of star-bases to a single unit/per planet (for most of them, it also doesn't make sense to have more) - this would not require an AI change and as a bonus, considerably reduce the appeal of turtling altogether

Also suggested to considerably decrease the priority of capital ships but this is tricky with the shield OP active (that is why I use your mod here as well). One would of course think that the AI producing solely capital ships in the late-game would make for interesting battles or at least challenging difficulty, but it is not too hard to design a more cost-effective counter fleet tailored against the specific capital ship used by a faction with all the toys and ship types at our disposal (PD destroyers without armor, mobile base as carrier, cloaked transports with Assault Shuttles etc). With the numerical disadvantage, the AI is also less capable of defending its assets while taking offensive actions, so you can simply circle around their fleet of capital ships with numerous cheap invasion forces tailored for planet sieging

[harpy eagle]

Well, if I were the AI, firstly the value of static defenses should be tied to the value of what they are defending. 2 of the 4 fleet bases I mentioned in my post above were being constructed around 1 population inferno worlds... that each only had mines on them and their mineral output was less than 5% of that empires mineral income (due to low population). These worlds were costing that AI 70 minerals per turn. 2400 minerals for a planet that produces 9 minerals a turn?

Then a sizable penalty that accounts for the fact that static defenses are the epitome of strategic inflexibly.

I think the issues with AI building only capital ships could be solved with better prioritization (lol though problems of prioritization have been the sole focus of my attention on this game for the past few weeks, so maybe I'm seeing everything as a nail).

Lets say the AI could build ship A in 10 turns and ship B in 2 turns. In the time it takes to build ship A the AI could have 5 of ship B. So obviously whatever combat value the ship has should be adjusted for that.

Then you need to account for the fact that getting a ship sooner means you can start doing stuff with the ship sooner, in addition to having more ships in the same amount of time. You could handle that same way that economists handle interest rates. I mean, building a ship really is the same kind of situation as a return on an investment. So for example, if i=0.97:

The the value of building 1 of ship A = A*i^10
And the value of building 5 of ship B = B*i^2 + B*i^4 + B*i^6 + B*i^8 + B*i^10

As you can see, the relative value of building A and B change dramatically depending on how fast we can build each of them relative to the value of the ships themselves.

Then naturally, the AI's high production worlds will prioritize building capital ships, while lower production worlds will build smaller ships. If the AI only has super high production worlds that can build capital ships in a few turns? Then why not pump out battleships? Otherwise it may make more sense to build something cheaper.

Anyways, back on topic:

If you're on the in-development branch, the next version of this mod will allow the AI to move towards missiles/bombers that it wants to attack. With this change, the AI is now really good at wiping out hostile bombers. I also made the AI more careful with how it uses fighters and bombers, which was necessary now because of the first change.

EDIT: found a bug that was causing carriers to not launch fighters except at point blank range.

[zolobolo]

If you're on the in-development branch, the next version of this mod will allow the AI to move towards missiles/bombers that it wants to attack. With this change, the AI is now really good at wiping out hostile bombers. I also made the AI more careful with how it uses fighters and bombers, which was necessary now because of the first change.

I am on the DEV branch - but is your mod though?

Is the change log in the game menu listing an experimental AI changes referring to your mod being integrated into the base game?

[harpy eagle]

Huh. Sven did contact me awhile back about possibly integrating the mod into the game. This was way back around one of the first versions of the mod.

The mod has changed dramatically since then and I'd say the AI is many, many times better now, but I haven't really had any contact with sven since then. So I don't really know what's been going on.

If he does have any plans to integrate the latest version, it would be nice to discuss that with him. Like for example, in my mod the CloseAndAttack.lua file is massive (due to my not knowing how to get the mod loader to load new files). But it largely breaks down into a few logical sections so it may be worth splitting up since once integrated into the game that becomes possible. Probably something like a file each for targeting and priority calculations, ship movement, boarding logic, retreat logic, and then for helpers and the main inside_do_turn() function.

Also there's some magic numbers that I'd like to move into file-level variables and a few debug functions that really spam the log with lots of numbers that I'd like to comment out.

[sven]

Is the change log in the game menu listing an experimental AI changes referring to your mod being integrated into the base game?

No -- sorry for the misleading patch notes; I have not done anything to move this mod into the vanilla game. The changes referenced in the patch notes are just some very minor low-level things I added in response to some of harpy eagle's questions in another thread.

[sven]

Like for example, in my mod the CloseAndAttack.lua file is massive (due to my not knowing how to get the mod loader to load new files).

The trick you're probably looking for is the depends function. Basically, on game startup, the game will automatically walk through all lua files in Lua State\, using a traversal order that's alphabetical and depth-first (with a couple important caveats). (See the comment at the top of standard_frames.lua for a discussion.) Then it applies the same traversal to any files inside Mods/.

While the game is running, editing any .lua or .cg file will cause that file to be reloaded. In the case of lua files, we re-execute the file chunk when it's reloaded. However, we also reload any of that files 'dependencies'. You can mark one file as a dependency of another by including a line like:

Code: Select all

  depends 'AttackPriorities'

Which will cause the file that *executes* that line to be marked as a dependency of 'AttackPriorities', and, thus, edits to 'AttackPriorities.lua' will always cause it to be reloaded.

For the project of breaking up CloseAndAttack.lua, you probably want to create a couple new lua files, and then mark all of those files as dependencies of CloseAndAttack.lua by including the appropriate depends calls in CloseAndAttack.lua.

The other thing worth knowing is that you'll want to start any such split files with

Code: Select all

_ENV = AIContext

Because that ops them into the (perhaps overly clever) scoped environment trick that underlies most AI files. (See also: @AIContext.lua.)