Tactical Combat AI Mod

[harpy eagle]

While the vanilla tactical AI does a decent enough job, I've noticed though that sometimes it takes really disproportionate losses, so I wanted to see if I could improve it at all.

This mod focuses mainly on target prioritization for the AI, nothing terribly fancy, but I think it does help out the tactical AI in a few areas, especially when using missiles.

EDIT: this post is starting to get out of date, I will eventually get around to updating it but please see the posts later on in this thread for information on more recent updates. please see the changelog at the bottom of this post.

• Ship movement is mostly unchanged; ships pretty much just move towards the closest enemy. However, they now calculate a desired engagement range and stop once they are within that range. This means that ships armed with longer ranged weapons such as missiles or fighters will tend to hang back a bit instead of rushing into close range. Ships attacking with lasers will try to get closer than in vanilla.
• The AI will now assign priority to potential targets in range based on how dangerous they are versus the amount of shields and armour they have. This especially helps the AI when assigning missile targets, since I found it used to be pretty exploitable by throwing some expendable craft ahead of your fleet.
• PD weapons preferentially attack missiles and fightercraft. Most PD weapons just go for the nearest enemy missile, but anti-missiles make an attempt to prioritize.
• Interceptors choose whether to attack missile/bombers or ships by comparing the priority of friendly ships vs the priority of other potential targets. They also take into account how much damage they would deal to an enemy ship vs the damage dealt by the incoming missiles.
• In most cases the priority of a ship is calculated using the amount of damage it can dish out vs the amount of "useless" damage that needs to be chewed through before damaging systems (and thus affecting the combat power of the target). Adjustments are made for a variety of factors, such as hit chance (handles cloaked ships nicely), beam attentuation, etc. Currently the AI doesn't understand shield piercing or armour piercing, so it doesn't take those into account yet. Weapon mods that affect range or fire rate are accounted for by the AI.
• Priorities are dynamic so the AI does a decent job at ignoring crippled ships when there's bigger fish to fry, while concentrating fire on already damaged ships. It's only updated once each turn right now, but I'd like to improve that - just need to figure out a way to do it so that only relevant priorities are updated outside of the once-per-turn recalculation. done.

Also:

• Fixed a bug where if stand_off_and_bombard got tripped to true for one side, it would affect both sides and never untrip. I can't be sure if this did affect vanilla since I'm working with modded code, but even in the vanilla lua files I couldn't figure out where stand_off_and_bombard is supposed to be reset.
• Modified stand_off_and_bombard slightly to encourage picket ships to move forwards, providing a bit more of a PD screen.

While I've tested it with a bunch of different fleets, I haven't gotten around to fighting battles with every type of weapon yet (e.g. haven't tested assault shuttles) so it's quite possible that you will run into bugs. But I'm making it available here in case anyone is interested in trying it out or perusing the code.

Obviously this mod adds additional AI calculations to tactical combat. I've tried my best to avoid any egregious performance hits and haven't noticed any slowdowns in my own games, but feedback on this front is appreciated.


More changes since OP (collected from later posts):

Update:

• AI now considers bombers that have not yet launched when deciding what to do with interceptors
• stand off behaviour is limited to the first 30 turns and the AI attempts a cease-fire after 50 turns.

Update:

• Carriers now try to move in closer, and targets that are within 1 turn range are treated with much higher priority for fighters/bombers.
• Missiles that are already targeted by interceptors have reduced priority when choosing targets for the next weapon or interceptor
• Interceptors/strike fighters treat missiles/bombers that are farther away with lower priority.
• Major tweaks to the priority calculation used when targeting fightercraft with weapons. Fightercraft now have an inherent priority that reflects the fact that unlike missiles, destroying a fightercraft is like destroying a weapon system, it reduces the offensive capability of the opposing fleet. This priority is calculated much like that of ships, in order to ensure they are mutually comparable. It's based on the damage dealt by the fighter/bomber group vs it's health.
• Shield regeneration now matters more when considering how vulnerable a potential target is.
• Now any non-PD weapon that can target missiles/bombers may choose to do so.

Update (3db6ecd):

• The AI now considers reserving direct-fire PD for missiles/craft not yet launched if the PD weapon's own ship is within strike range of the missile launcher/craft carrier. Should help the AI deal with energy torpedoes aka plasma launchers.
• AI now considers hit chance when deciding to attack missiles/craft with direct fire weapons.
• Reduced "stand off and bombard" turn limit to 20, cease fire turn limit to 40.
• Interceptors now consider the distance to hostile carriers/launchers when deciding to reserve, while also considering that the hostile missiles/bombers will likely be closer once launched.
• Interceptors now check if they can reach their target in time before it reaches it's target, when considering to intercept in-flight craft.
• Prevents interceptors and PD from all reserving for the same target. They are now aware if other weapons are reserving for the same launcher, and will consider other options.
• Fixed a vanilla bug that was preventing the AI from using assault shuttles/transporters against non-immobilized ships.
• Added threat assessment for ships equipped with boarding modules/shuttles/transporters. Might need tweaking, though it rightly considers military transports very high priority, given their ability to take ships out of combat in a single turn.

Update (7755b5f):

• AI now considers reserving PD for enemy assault shuttles. Though I haven't seen PD be particularly effective at destroying them yet.
• Improved the boarder threat assesment. Now based on an estimation of crew damage that would be dealt by a capture attempt. Boarders still tend to be high priority, but it's not as extreme as before.
• The decision to capture vs raid is now based on the estimated crew damage vs the remaining crew of the target ship.

Update (27c2b17):

• AI attempts to account for enemy ship movement when determining if it is at risk from assault shuttles or missiles/crafts when reserving PD.
• Removed the simplified algorithm for PD allocation. It's been around since the very first version of the mod, and now that the AI is better able to weigh hostile missiles/crafts against ships I don't think it's needed anymore. Removing it does seem to improve the AI's handling of ships that are equipped entirely with PD weapons, or missile fleets that have run out of missiles.
• Fixed a stalemate bug that occurred when all crafts and all non-PD weapons on all ships have been destroyed.

Update (6f23070):

• Direct fire weapons now also consider the amount of missiles currently launched at a ship when deciding to target it
• Defence value calculation now includes the amount of useless system health (bulkheads, etc) that might soak up system damage
• Combat boarders now use boarding priority to pick the ship they move towards (note that all ships still only ever pick the best of the closest 3 when deciding what to move to).
• Planets are now always considered lowest priority when deciding what to move towards, unless if they are already in weapons range.
• When deciding to attack missiles/craft or reserve PD for unlaunched missiles/craft, the amount of damage the weapon does vs the amount of damage the missile/craft group does has more weight (It's now calculated as missile damage/weapon damage squared).

Update (bbae9ca):

• For the last item above, now only the individual missile/craft/weapon damage is squared, since the count of missiles/craft can be unreliable. For example if there are multiple craft groups near each other, or multiple launchers on the same ship, the AI only sees each one individually. So now the multiplier is = [ (# of missiles/craft)*(individual missile/craft damage)^2 ]/[ (# of weapons)*(individual weapon damage)^2 ]

Update (6674025):

• The AI now always moves ships with boarding modules/assault shuttles/transporters last.
• The AI attempts to estimate the survival rate of it's missiles vs PD and overcommits missiles to targets accordingly, instead of using a hardcoded overcommit multiplier.
• The AI will not enter "stand off and bombard" mode if it's estimated missile/bomber survival rate is less than 25%.

Update:

• Overhaul of how missiles and fightercraft adjust their targeting priorities based on the distance to potential targets, now takes advantage of the AI's ability to assess the amount of hostile PD.
• Ships armed with missile weapons now adjust their desired engagement range based on the AI's hostile PD assessment.

Update (402490c):

• A small change that seems to significantly improve how effective the AI is at using PD: Ships that have interception warnings are moved by the AI last, after boarding ships.

Update v1.0 (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 now 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.

Update v1.2 (6d750b1)

• The AI can now make ships move or face towards missiles/fightercraft that it wants to shoot at with fixed weapons.
• Made carriers even more cautious about launching fighters when heavy PD is present. Now they will not launch fighters at targets that are outside of point blank range in the most extreme case.
• Fixed an oversight that was causing the AI to overestimate the combat power of carriers.
• The AI now factors in the speed of missiles/torpedoes/fightercraft when evaluating weapons, since it does affect how easily those objects are shot down.
• Improved the damage assessment calculation used to decide when a ship retreats.
• Made sure space harpies and ancient super-dreadnoughts don't retreat.
• Fixed fightercraft and missile launchers underestimating the distance to their targets.
• The AI can now move ships and attack with them later after other ships have moved and attacked. It tries to move its tougher ships first, while attacking with its more powerful ships.
• Many tweaks and fixes.

Update v1.2 (d08aec4)

• Bugfixes.

Update v1.3 (1ecb39f)

• The AI now factors in armour and shield piercing effects when calculating the priority of potential targets.

Update (e0c857f):

• Bugfixes

Special thanks to zolobolo for feedback and testing. This mod has been massively improved because of your feedback.

Note the hash in the filename below is the latest revision. If you downloaded an older version please see the download link below, it may contain bugfixes.

LAST UPDATED: 2018/04/27

Git repository: dropbox link

[harpy eagle]

A small update: inspired by zolobolo's post here, I modified the boarding AI code so that if the target has any weapons left and much larger crew than the boarding ship, it performs a raid instead of a capture.

It turns out this is enough to make the difference between defeat and victory in an autoresolved battle against two starbases

[harpy eagle]

Last update for now. Instead of always moving towards the closest enemy, ships will look at the closest 3 and pick the best one to close in with. I think it's a good compromise between giving the AI some flexibility with how ships close in on the enemy while also avoiding having ships charge right into the middle of the opposing fleet (which tends to get them killed really fast) because a high value target happens to be at the back.

Plus a few tweaks related to fightercraft and a hack to ensure that turn_counter gets reset at the end of combat. I'm guessing there's a way to add values to the environment that close_and_attack_turn executes in, but I wasn't able to figure it out.

[sven]

Plus a few tweaks related to fightercraft and a hack to ensure that turn_counter gets reset at the end of combat. I'm guessing there's a way to add values to the environment that close_and_attack_turn executes in, but I wasn't able to figure it out.

It looks like your turn_counter is basically just replicating functionality that can already be accessed through the (obscure and entirely undocumented) global helper function current_side_nturns()

Re: inserting variables into the tactical combat execution environment; AI execution environments are a bit overly fancy, read the comment at the top of @AIContext.lua for a rundown. But, for all the fanciness, there's not currently a clean way to do what I think you're asking about: namely, creating and updating additional per-side state that would persist over the lifetime of the battle.

The reason for that, more or less, is that battles can be loaded and saved, so any permanent state would need to be put somewhere that gets loaded and saved as well. The logical place for tactical ai persistent variables is probably "all_attacks", more specifically, fetching the current attack.battle via local attack = all_attacks[get_attack_id()], and then sticking per-side ai data somewhere inside attack.battle. (Hacks like this are already used to power the 'retreat_all' ai hint.)

That said, using attack.battle is also really something of a kludge; as that data supports game io, but not attack action rollbacks. The *best* solution here would probably be to expose a custom battle-state variable that could act as a sortof AI notepad. That's a change that would require a little fiddling with the C++ side of the engine, but it wouldn't really be that big a deal to setup. Um, basically, if you think tactical ai state is a thing you want to really experiment seriously with, you should let me know, so I can write some helpers that really support the feature "properly".

[harpy eagle]

It looks like your turn_counter is basically just replicating functionality that can already be accessed through the (obscure and entirely undocumented) global helper function current_side_nturns()

The vanilla code actually uses that function! I replaced it with the turn_counter kludge because I needed the current side's turn count to increment conditionally, and I couldn't figure out how current_side_nturns() was keeping track of that state internally. I wasn't able to find the definition of that function using sublime text, so I'm not even sure if it's defined in the lua files. Is it provided by the engine somehow?

Re: inserting variables into the tactical combat execution environment; AI execution environments are a bit overly fancy, read the comment at the top of @AIContext.lua for a rundown. But, for all the fanciness, there's not currently a clean way to do what I think you're asking about: namely, creating and updating additional per-side state that would persist over the lifetime of the battle.

I see, I was hoping there might be a way. I'm pretty new to lua and am still getting a handle on the ways you can manipulate scope in the language. So If I create a table at the beginning of the do_ai_turns() function, to be used as a kind of scratch space, there's no way to get it into close_and_attack_turn() when it executes? I have to admit I don't understand what is going on in the control flow between do_ai_turns() -> tactical_ai_call() -> close_and_attack_turn().

The reason for that, more or less, is that battles can be loaded and saved, so any permanent state would need to be put somewhere that gets loaded and saved as well. The logical place for tactical ai persistent variables is probably "all_attacks", more specifically, fetching the current attack.battle via local attack = all_attacks[get_attack_id()], and then sticking per-side ai data somewhere inside attack.battle. (Hacks like this are already used to power the 'retreat_all' ai hint.)

Okay. This is an area I haven't even considered at all. So I'm guessing the problem with my idea above is that, if the player closes the battle half way, quits and later loads the game up again, then none of the data in my scratch space table will be persisted? If that's the case then the turn_counter will probably break too in that situation.

That said, using attack.battle is also really something of a kludge; as that data supports game io, but not attack action rollbacks. The *best* solution here would probably be to expose a custom battle-state variable that could act as a sortof AI notepad. That's a change that would require a little fiddling with the C++ side of the engine, but it wouldn't really be that big a deal to setup. Um, basically, if you think tactical ai state is a thing you want to really experiment seriously with, you should let me know, so I can write some helpers that really support the feature "properly".

I'm not too confident to say how important that is right now... what led to the turn_counter thing in the first place is that the stand_off_and_bombard behaviour can eat into the 30 turns that gets allotted to each side before the battle ends in a draw. While the draw won't happen as long as stand_off_and_bombard is true, each stand off turn is still counted, so it can happen that the AI gets far less than 30 turns of "real" combat once it runs out of missiles.

The decision problem of whether or not a battle is making sufficient progress to be worth continuing to process is kind of a thorny one anyways, and I'm not sure if I really want to take a deep dive into that (e.g. what if the stand off side has only a few fighters left, not enough to overcome shield regen, while the immobile side has no PD?). I may end up just reverting the turn_counter stuff and focusing on something else instead.

The mod is a bit of a work in progress in the sense that there's still a few areas I'd like to try and improve. For example the AI still tends to go overkill on allocating too many missiles to a single target, and I'd like to make the AI update a target's base priority after it gets attacked, instead of only at the start of a turn.

[sven]

I see, I was hoping there might be a way. I'm pretty new to lua and am still getting a handle on the ways you can manipulate scope in the language. So If I create a table at the beginning of the do_ai_turns() function, to be used as a kind of scratch space, there's no way to get it into close_and_attack_turn() when it executes? I have to admit I don't understand what is going on in the control flow between do_ai_turns() -> tactical_ai_call() -> close_and_attack_turn().

Well, there's a disposable temporary ai scope that gets created in the tactical_ai_call(). More exactly, right now, the definition of tactical_ai_call is:

Code: Select all

function tactical_ai_call(f,...)
 	return SCOPE_call("temp AI State", { }, 
            "calling AI", _ENV, f, ... )
end

Which creates both the "temp AI State" used for temporary variables, and defines the "calling AI". (The idea, though unimplemented atm, is that "calling AI" would eventually be set to values other than _ENV, and that would in turn allow races with different AI settings to fight battles using different tactics.)

If what you want is just a to put a some temporary data into the temp AI state, you can call close_and_attack_turn yourself from do_ai_turns, populating the temp-table by hand. I.e.:

Code: Select all

   local my_temp_data = { turn_counter=i }
   SCOPE_call("temp AI State",  my_temp_data,  "calling AI", AIContext, AI.close_and_attack_turn )

However, as is stated later on in the thread, because of game save/load situations, etc, this probably isn't actually a thing you want to do here. It is, however, <possible>

[sven]

what led to the turn_counter thing in the first place is that the stand_off_and_bombard behaviour can eat into the 30 turns that gets allotted to each side before the battle ends in a draw. While the draw won't happen as long as stand_off_and_bombard is true, each stand off turn is still counted, so it can happen that the AI gets far less than 30 turns of "real" combat once it runs out of missiles.

Ah, I see. So, things are a bit needlessly complex right now, because of the sanity checking logic in do_ai_turns(). In theory, that turns>35 check shouldn't ever really be necessary -- basically, if the AIs on all sides offer cease fires (as per whatever logic they're using to offer cease fires) the battle should end. Thus, in my version of CloseAndAttack.lua, that check should almost never be hit -- because both sides will generally offer cease fires after 30 turns. In your mod, you're going to some effort to rewrite the sanity check -- but, that effort shouldn't really be necessary: if you delay offering a cease fire in CloseAndAttack.lua, that, ideally, should be all that's necessary to delay the end of the battle. (And, similarly, ideally, the sanity check in do_ai_turns would never be necessary to end a battle). If I were you, I'd just patch the sanity check to have a much higher threshold, i.e.:

Code: Select all

		if(i > 200*Battle.num_sides() )
			sprint("max number of ai turn repetitions reached.")
			break
		end

And then call it a day

[sven]

The decision problem of whether or not a battle is making sufficient progress to be worth continuing to process is kind of a thorny one anyways, and I'm not sure if I really want to take a deep dive into that (e.g. what if the stand off side has only a few fighters left, not enough to overcome shield regen, while the immobile side has no PD?). I may end up just reverting the turn_counter stuff and focusing on something else instead.

Yeah. Thus the hard coded "30" in the original code. I think making the limit a bit higher in the case that the AI is using stand off and bombard tactics does make some sense, but, for all the reasons you're pointing out, a very simple rule is probably the way to go. Maybe we could say that the standoff and bombard behavior has a fixed limit on the number of turns for which the AI will keep using it -- and set that limit to say 5 for fleets with missile ships, or 10 for fleets with carriers. Then just add that 5 or 10 to the base 30 turn limit check when calculating cease fire offers.

[harpy eagle]

I like that idea, it's probably what I'll end up doing.

Anyways, a new update. Added a crude system to prevent the AI from going overkill with missiles on a single target. Still kinda WIP, since "how many missiles is enough missiles?" is a bit of an open question, but it does seem to make a big difference for fleets that are almost entirely composed of missile ships, since they can actually kill more than one ship per turn now!

Code-wise this update also introduces a big refactor, so that shared data doesn't have to be passed around so much. Instead it's held in a table and various functions have now become methods. I guess I've evolved up to the setmetatable() level of lua now. This also helped avoid some duplicated priority calculations and supported the above missile addition.

[sven]

I guess I've evolved up to the setmetatable() level of lua now. This also helped avoid some duplicated priority calculations and supported the above missile addition.

Well, you've evolved up to using a metamethod class pattern; if you keep on poking around in the SiS sources, you'll find that the metatable rabbit hole gets considerably deeper and weirder as one dives down.

I can reasonably be accused of having an excessive fondness for metamethods. This is at the core of why siyoa's bug went unfixed for so long (I managed to confuse myself by nesting multiple levels of metatables). But, then, fancy metamethods are also the reason the game supports an undo/redo button. So, I guess the takeaway is that they can be both tricky and cool

[harpy eagle]

Just got back from being away from home for a week and a half, so mod development has been pretty slow, but some things on the radar:

• Revert turn counter, try to replace it with something simple that doesn't require data to persist across turns, or just revert it altogether.
• Take advantage of __index to do some coffee improvements
• Experiment with considering the amount of PD possessed by the opposing fleets when deciding how many missiles to allocate to a target.
• Experiment with taking into account bombers/missiles not yet launched when allocating interceptors. This might be useful since interceptors are usually committed for a few turns, and throwing them against ships can be a waste

[harpy eagle]

After that, I want to make sure the AI uses assault shuttles correctly and see if they use the new Orthin capacitors, and then I think this mod will be complete.

[harpy eagle]

Update:

• AI now considers bombers that have not yet launched when deciding what to do with interceptors
• Reverted turn counter changes, instead stand off behaviour is limited to the first 30 turns and the AI attempts a cease-fire after 50 turns.
• Some bugfixes, code cleanup

If anyone here is willing to try out the mod, feedback on the AI's combat behaviour would be really appreciated. It would be nice to get a second opinion on how well it performs and if it needs improvement in any particular areas.

[zolobolo]

Here, will gladly give your mod a spin and get back to you

[zolobolo]

Findings:
- Interceptors are reserved and target incoming missiles
- All interceptors are launched on a single missile pack (would be better to maximize their deployment to a single squadron per missile salvo is possible)
- Interceptors do not engage enemy ships even if enemy fleet has fired all their PD weapons in the previous turn (it would be great if they would engage if in direct range and enemy PD capacity is at least 50% depleted)
- Strike Fighters seems to behave as interceptors. As they are a mix of the two they would benefit from a combined behaviour
- Missile heavy ships keep to the back - works like a charm
- Enemy ships select their target based on target threat level - seems to be working nicely but needs more testing with all the various special scenarios
- Raiding is prioritized against bases - works perfectly and is very effective which is should
- Raiding is not utilized anywhere else due to the per-requirement of engines needing to be disabled (which almost never happens) and the AI avoiding utilization of boarding module (this is due to the vanilla code)
- Assault Shuttles do not utilize raiding even if enemy crew is larger. They should probably be effected by the mod, but Assault Shuttles currently seem to be prevented by a bug of sorts from being utilized as it has been mentioned that they should work

Summary: AI controlled fleets are much more adept at taking on star-bases and utilizing their advantage in missiles thanks to the mod. Interceptor/Strike Fighters could use some optimization for their behaviour before they really get effective, and Assault Shuttles are still sadly a useless brick tied to the AIs ankles - if you could elevate this pain for them it would be awesome

Thanks for your great work!

Edit: I just saw a battle where interceptors are launched right off the bat against ships so clearly in same cases this prioritization is working fine
Also noticed though that the carrier was holding its starting position, and not closing to enemy vessels. This made the small crafts less effective due to the amount of turns it takes for them to get to the target and back, and vulnerable to other guns outside of automated PD counter - would make sense to bring carriers close enough so that their squadrons can unload their payload in a single turn