AI Development Guide and M27AI v74 Devlog

maudlin27

V10 - Implemented anti-turtle logic:

Use of T2+T3 MMLs and mobile arti to break firebases
Ecoing (not very well, but better than before)
Reduced turtle feeding

Misc changes:

Large bomber attack for if we end up with lots of spare bombers
T3 air factories can be built/upgraded
Support factories will be built/upgraded instead of HQs
Higher tier power is built sooner
Engineers can request guards
Various bug fixes (see section 3.30.2 of the guide)
Updated the guide with details on how to run in FAF Develop offline

My AI also has a new icon

For anyone that's interested in the background to the last 5 versions/2 months - back at v5 I was crushed by gunner1069 (I usually get them to play a match every couple of weeks against the latest AI version) with a simple turtle strategy on Theta Passage - they didnt bother getting any mexes and instead just rushed T2 PD with their ACU and my AI had no answer despite having 4x the mass income. My primary focus in all the versions since then has been coming up with the logic that will give my AI a chance in that scenario.

Unfortunately, a relatively simple plan for a human (dont send units single-file into PD, upgrade mexes and then attack with MMLs) required a bunch of different bits of logic:

Checking for PD and running away from it (so the enemy isn't fed kills/mass), without running away when we're already in range of it and able to beat it (I had some frustrating to watch games where my AI would charge in at a firebase, overwhelm the shields, be about to destroy everything, before deciding to run and turning a winning position into a loss)
Realising there's PD when it kills our land scouts without being picked up by their radar
Making use of air scouts to reveal 'hidden' PD to avoid suiciding units and the ACU into the PD
Quickly expanding to uncontested mexes (including on enemy side of the map)
Focusing on maintaining map control and ecoing if faced with a turtle rather than trying to break them immediately, which in turn requires various logic for identifying if we're against a turtle, upgrading mexes, building T2+ buildings, upgrading factories, making use of support factories, etc. (I've still not got basic things done like capping mexes with mass storage)
Using indirect fire units to attack PD/long range enemy units while both protecting them from enemy mobile attacks, and not suiciding our own units trying to protect them

These changes also mean my AI will be worse in other situations - e.g. against a non-turtle it might choose to eco when it would be able to finish the game by pressing the attack, and it's also still poor at the mid-T2+ stage so extending the game via ecoing means it's more likely to snatch defeat from the jaws of victory. Long term though it needed to happen as a 'T1 or die' strategy only has a decent chance on 5v5 maps.

Rowey

@maudlin27 Nice list of g
Changes of updates for you Ai mod, I'd like to extend you the offer it have this in a more of a cleaner formate over on the new faf wiki, if this is somtbing your interested in please send me a pm here or on the faf discord and I can set you up with a page

maudlin27

v11-v12 update:
The big thing I've been working on in these 2 updates is an alternative approach to pathfinding to replace my use of CanPathTo with a manual method that I can run at the start of the game and then lookup the pre-recorded results later in the game (rather than calculating pathfinding on the fly), since I figured this should be much faster.
Unfortunately I failed to factor in the consequential change this would have on other parts of my code, and while my replacement 'canpathto' check itself is much faster (especially on 81x81km maps), my overall AI is significantly slower! Since my new approach is based on terrain height differences, it will also be less accurate, so I've managed to achieve the worst of both worlds! However, it should at least be easier to get some CPU performance gains in the future, even if my first attempt has failed.

Various misc changes:

Significant improvement in ecoing speed, including the ability to build mass storage
MAA and Engineers shouldn't be overproduced as much, and certain T3 MAA shouldn't be treated as land attack units
Mobile artillery should attack enemies (instead of changing their mind every second)
Surplus engineers should reassess what they do periodically instead of assisting the same factory
Minor improvements to building and upgrade decisions to deal with mass overflow and power stall
SMD can now be built in response to a nuke threat
AI will now stop ecoing if it detects certain experimental threats
Various other bug fixes and smaller tweaks to the AI

See 3.34.3 - 3.36.6 for details of the changes and the journey I went through getting an alternative pathfinding logic to work.

maudlin27

v13 Update:
My AI should finally have a chance (albeit a small one) on water based maps. Previously, it would ignore naval units (meaning they'd only die if they happened to get within firing range of a unit). It'd also assume it could send land units to attack the enemy base meaning on island maps it'd produce way too many tanks that would do nothing.

Now, it should try and deal with enemy naval threats, while also focusing on building amphibious and hover land units (although it still doesn't try to build any naval units).

Various misc changes and bug fixes, including:

Fixed hard-crash when sera sniper bots were built
Improved engineer logic for nearby enemies
Slightly less suicidal ACU behaviour (but only when it feels life has meaning)
Engineers are less likely to block units in the base when they have nothing left to do
Introduced fixes for the pathfinding on several maps where the new logic was giving incorrect results.

Evan_

Gave this AI a try and it's quite a challenge! It still tends to overextend a bit with its com and also seems to clump up its tanks, but if this is how it is now then I'm excited to see how it will be in the next few updates.

maudlin27

Thanks for the feedback, and glad it's providing a challenge! Do you have a replay that shows the tank clumping issue? It's probably just its normal behaviour but figured it'd be good to confirm (depends how bad the clumping was/what units).

New version will be up once an issue with the client preventing uploads is resolved, but I double-down on the ACU focused gameplay so will probably still suffer with ACU overextending (it just wont be as suicidal to do in the mid-game in the next version)

maudlin27

v14 Update:
I decided to take on board feedback from a number of people that the AI is too aggressive with the ACU and builds lots of land scouts, and so this version my ACU is even more aggressive and builds even more land scouts!
Also introduced a new suicide function (congrats if you manage to trigger this without looking at the code - the AI gives its first voice message if you make it commit suicide).

Summary of changes:

ACU will now sometimes get upgrades other than gun
New 'all-in' strategy where my ACU charges at the enemy
Mobile shields will now be built and used
More land scouts built
Improved logic for dealing with enemy bombers
ACU will now consider Ctrl-King itself
Various bug fixes and tweaks

Jip

@maudlin27 said in AI Development Guide and M27AI v14 Devlog:

ACU will now consider Ctrl-King itself

How does it evaluate this in practice?

edit: I just noticed the text above that it is a 'secret'.

splitice

Really interesting document. I look forward to seeing this grow.

A couple of things I didnt find (I may have missed):

Do you have any data on what % of (a typical) AI's time is spent in Pathfinding, Build Conditions etc?

Theres a fair bit of talk of CPU performance but I didnt see any direct evidence of what causes the slowness. While its great to have optimal functions knowing where to direct attention (low hanging fruit!) is a good idea.

Do you intend to test non standard game settings e.g 5/10 minute no rush or disabled units?

maudlin27

@splitice
1 - Re % of an AI's time taken on different areas, It will vary depending on the AI and the approach taken, although at a high level I'd expect pathfinding to take up a lot of time at the start of game, and build conditions to take up minimal time throughout the game.

For example with pathfinding, for a while my AI would calculate if it could path somewhere as and when it needed to (and then record the result so it could refer to later), but more recently it will do the calculations up-front, which is consistent with the approach of the other AI I'm aware. Times taken can vary dramatically - e.g. when Balthazar was testing their pathfinding logic, I think the slowest time they came across was on Alaska (which I'm guessing was an 81km map) where it took more than 5m. Softles mentioned their pathfinding after optimisation is down to 0.4s on smallest maps. Map size has a big impact though, since an 81x81km map is 262 times the size of a 5km map, so if you do things to the same level of accuracy the time taken will skyrocket.

Therefore pathfinding is largely a 1-off cost at the start of the game (where it's more acceptable to have a slight delay before the game actually starts), although there'll still be some overhead later on (e.g. if trying to calculate a safe path to use - I dont use this logic at the moment so can't comment on how much time it takes).

The most useful function for working out the CPU performance impact is GetSystemTimeSecondsOnlyForProfileUse()
If you compare the result before and after a 'heavy duty' function you can get an indication of how long that function takes (although the figure isn't that reliable).

In the latest version I'm working on I'll be including lots of comments and profiler outputs from some profiling I did of my own AI in an effort to improve its CPU performance, and the code for this as well as code Softles recently helpfully shared on the AI discord for profiling will be included as part of the AI.

As a very rough guide though, anything that is running >10k times in a single tick needs to be streamlined to avoid a performance impact. Simple checks like if a variable is true or false take up no noticeable time (you'd need to be checking millions of times in a tick I'd have thought to impact things), while more involved checks such as getting all units of a particular category within a certain distance of a point on the map will take far longer.

Examples of things that can end up overloading a tick could be carrying out logic on every part of the map (e.g. calculating reclaim), or recursive logic (e.g. in v14 and earlier I'd recursively look for units around an existing unit, and then units around those, and so on, in order to group them into an 'army' to be dealt with).

To give a rough idea of the relative weightings for M27 (other AI will be different) for different aspects of the AI, the following benchmarks are for the total time taken in the first 10m of a 3v3 M27AI game on a 10km map (WIP v15):

Determining pathing at the start of the game c.4.5s
telling platoons what to do 8.5s
threat detection logic (identify enemy threats, selecting units to deal with the threat) 3.7s
checking reclaim on the map 3.3s
managing air units 2.6s
managing engineers (build conditions and orders including reclaim) 1.7s
Deciding what to build for factories 0.1s.
As part of this, I have a function called 200k times that took 0.000s in total, and another function called 165 times that took 0.36s.

The times are a relative guide, not absolute, as the GetSystemTimeSecondsOnlyForProfileUse() isn't that accurate, and depending on how its used it won't factor in time taken by the wider game engine as a consequence of the AI's code.

2 - Not in the immediate future, but probably once I've achieved some other goals. I think Softles may be planning an AI tournament with norush at some point so that might prompt me to have a look at it!

maudlin27

v15 Update:
Focus of this release was (CPU) optimisation, so the major changes are 'behind the scenes'. It also means in some areas (primarily threat detection) my ACU unfortunately is a bit more stupid than before, as I didn't feel I could justify the increased CPU load caused by a more accurate method.

Implemented new profilers (both my own, and one Softles kindly provided) to help identify high usage functions
Rewrote most of the reclaim logic to improve performance (significant reduction in game stuttering, although still worse than I'd like)
Optimisation of a number of other functions to significantly reduce time taken
Improved SMD logic (including fixing a bug that meant SMD was never built) - AI is now much more likely to have a loaded SMD ready before a nuke hits.
Tweaks to how much power and energy storage is built to reduce tendency to over-build power and to ensure the ACU can deal 15k damage with overcharge late-game
Various bugfixes (notable ones being a bug with ACU escorts that would result in lots of errors appearing in the log, and an issue that caused escorts/assisting platoons to sometimes go to the wrong location)

splitice

@maudlin27 said in AI Development Guide and M27AI v15 Devlog:

Rewrote most of the reclaim logic to improve performance (significant reduction in game stuttering, although still worse than I'd like)

I'm not sure if it will help but I recently re-wrote AutoReclaim (dwm) as "AutoReclaim (splitice)" for more performant reclaims (for T!-3 engineering type towers).

--

I also tried a 2v2 (far slots) on Burial Mounds and noted many issues (including a general lack of awareness of the no unit paths and lack of serious economic growth). This was on v14. I think I'll re-asses though when this gets more mature.

splitice

I also gave v15 a try but failed on start with:


info: playable area coordinates are { 0, 0, 1024, 1024 }
info: Offmapareas are {
info:   { x0=-100, x1=1124, y0=-100, y1=0 },
info:   { x0=-100, x1=1124, y0=1024, y1=1124 },
info:   { x0=-100, x1=0, y0=0, y1=1024 },
info:   { x0=1024, x1=1124, y0=0, y1=1024 }
info: }
warning: false\000M27ERROR GameTime 1: Exceeded max loop count; iCurIntelLine=6
warning: stack traceback:
warning:         [C]: in function `assert'
warning:         [C]: in function `pcall'
warning:         ...nder forged alliance\mods\m27ai\lua\m27utilities.lua(45): in function `ErrorHandler'
warning:         ...er forged alliance\mods\m27ai\lua\ai\m27overseer.lua(387): in function `RecordIntelPaths'
warning:         ...er forged alliance\mods\m27ai\lua\ai\m27overseer.lua(4108): in function <...er forged alliance\mods\m27ai\lua\ai\m27overseer.lua:4042>
warning: false\000M27ERROR GameTime 1: Exceeded max loop count; iCurIntelLine=7
warning: stack traceback:
warning:         [C]: in function `assert'
warning:         [C]: in function `pcall'
warning:         ...nder forged alliance\mods\m27ai\lua\m27utilities.lua(45): in function `ErrorHandler'
warning:         ...er forged alliance\mods\m27ai\lua\ai\m27overseer.lua(387): in function `RecordIntelPaths'
warning:         ...er forged alliance\mods\m27ai\lua\ai\m27overseer.lua(4108): in function <...er forged alliance\mods\m27ai\lua\ai\m27overseer.lua:4042>
warning: false\000M27ERROR GameTime 1: Exceeded max loop count; iCurIntelLine=8
warning: stack traceback:
warning:         [C]: in function `assert'
warning:         [C]: in function `pcall'
warning:         ...nder forged alliance\mods\m27ai\lua\m27utilities.lua(45): in function `ErrorHandler'
warning:         ...er forged alliance\mods\m27ai\lua\ai\m27overseer.lua(387): in function `RecordIntelPaths'
warning:         ...er forged alliance\mods\m27ai\lua\ai\m27overseer.lua(4108): in function <...er forged alliance\mods\m27ai\lua\ai\m27overseer.lua:4042>
warning: false\000M27ERROR GameTime 1: Exceeded max loop count; iCurIntelLine=9

Map: Liberiam Battles

maudlin27

@splitice said in AI Development Guide and M27AI v15 Devlog:

Liberiam Battles

What were the game settings, in particular what player slots were in use by what teams and/or do you have a replay ID? I tried it just now in slots 1+2 and didnt get an error but from the log extracts and look of the map it might depend on what the player and team setup is.

splitice

@maudlin27 said in AI Development Guide and M27AI v15 Devlog:

What were the game settings, in particular what player slots were in use by what teams and/or do you have a replay ID? I tried it just now in slots 1+2 and didnt get an error but from the log extracts and look of the map it might depend on what the player and team setup is.

From memory was a mix of Sorian and your 2x m27 aix v 2x sorian aix v 2x sorian aix v1(player)

Just added m27 on a whim so didnt record game settings. Replay is https://replay.faforever.com/16044970

maudlin27

@splitice Thanks, found and fixed the issue in the latest version (will upload in a moment). Re Burial Mounds, having a look at the map it's not one that my AI will fare very well on at the moment (confirmed by it losing vs Sorian Adaptive when I tested just now). The biggest issue being the heavily fortified civilian base which will stop some of the ACU rushes that M27 relies on to gain an early game advantage (and which probably is also why it's not ecoing quickly), as well as making its current reliance on land for victory late-game flawed since amphibious tanks dont fare well against significant PD fortifications.

maudlin27

v16 - Hotfix:

Rewrote my land scout pathing logic to fix a bug that caused a crash on Liberiam Battles (thanks @splitice for flagging)
Minor tweaks to overcharge logic to increase the units that will be considered
Low health enemy ACUs are more likely to be targeted for an all-in attack even if M27's ACU isn't nearby
Bugfix to air threat logic so that air units near the ACU are correctly prioritised; also tweaks to the logic for building air factories when outnumbered in air

splitice

@maudlin27 Re; Burial Mounds if I was to describe the problems with the strategy they would be (in no particular order) - sorry was late.

Over reliance on light artilery. I (a human player) would see this and respond with a small air fleet and this unit is not particularly useful on a water map. The AIs pumping these out were largely limited to defensive operations.
After the early rush fails (or if AI suspects it will fail) the AI really needs to switch to economy building first. A player who has a well optimized build queue can easily push many orders of magnitude ahead of this AI
One of the AIs didnt build any mass extractors, just a single land factory and pumped out units. Given the extremely low cost and quick pay back time of a T1 mass extractor I struggle to see why they should b skipped (of course they could be delayed, but I stopped the game after ~15m and it was still just pumping out units). Perhaps if a early rush tactic is chosen a max game time before mass extractor build within at-least the players own area continues should be implemented?

I havent played against the AI as a human yet so this is theoretical.

splitice

@maudlin27 said in AI Development Guide and M27AI v15 Devlog:

To give a rough idea of the relative weightings for M27

Thank you for the time you spent gathering this.

That's quite a low % of total time, I assume this is pegged at 100% (i.e max sim speed until saturation)?

In retrospect I wonder what % of time goes to AI vs lua game logic vs engine. I'd always assumed the AI code (being there is multiple instances of it running and they typically can be quite intensive) would be a good (50+%) of the total sim time.

maudlin27

@splitice Thanks for the feedback!

Re 1 - Likely a flaw due to the civilian point defences - the AI treats civilian units as enemies, considers the total weighting of enemy units, thinks its up against an enemy who favours PD far above mobile units, and so builds lots of arti in response. No easy short term solution where the civilian base cant be pathed to (I'd probably need to come up with map specific logic which will be a long way away, or special rules for civilians which would similarly be very low down on my list as this is the largest civilian base I've come across on a map to date)
2 - Unfortunately it's not straightforward to come up with an approach/set of rules that would handle this well, and the current approach assumes it should be able to gain map control if it spends more than the enemy on units.
Longer term I'm planning on introducing turtle logic to the AI which I'd probably look to use on a map like this which would make it eco a bit better, but that's at least a few versions away.
3 - Sounds like a bug - doing a quick test with 8 M27AI, within the first 5m all mexes on each side were either claimed or queued up to be claimed, so I'd need a replay to investigate further. When checking back on the 4v4 test I ran though I noticed some other bugs which led to a massive slowdown/broken AI after certain players died which I'll be looking into for another hotfix!

Re the low profiling, I think the low % of total time is due to the limitations of the method I'm using - while getting the difference in system time seconds gives a good guide of how long a function takes relative to other functions, I think there're other things that happen in the background as a result of the code which don't get picked up (e.g. Sprouto's mentioned there's a garbage collector that can require resources to deal with clearing redundant variables) - these could be linked to the AI, or the normal game engine/operations, and I'm not sure of a reliable way to quantify. However I'd also assume the AI will take a majority of the total sim time, especially where multiple AI are used.