Artificial Unintelligence

[Delnar_Ersike]

Hey Delnar, I just wanted to check for sure, are you okay with people cherrypicking some of your changes? I'm working on integrating my own Hierarchical Task Network/A* planner implementation into the Civ 5 DLL and I'm trying to reuse code wherever I can, but I'd obviously like to reuse the better version of that code. It's likely this thing will never see the light of day as it's a huge undertaking and I'm largely doing it as a proof of concept, but you never know.

Sure, you can use my code, so long as you attribute me if you ever release your implementation.

Know though that the Experimental branch, and therefore version v10 and up, has A* classes structured differently than the current Master branch and the unmodified A* classes.
In the original code and all AuI code up to and including v9, A* classes worked with function pointers: the A* class had a bunch of function pointers for path validation, path cost calculation, path addition, etc. These function pointers were assigned to classless functions when the A* class' Initialize() function was called and were rarely (in some cases never) reassigned.
In all AuI code starting from v10, A* classes work with the FastDelegates implementation that Firaxis originally used as delegates for random number generators. The functions that previously used function pointers now use FastDelegates, and the original, classless functions that were originally loaded into the function pointers are now all members of the CvAStar class. Besides reducing namespace pollution and possible performance improvements, one of the biggest benefits of this restructure is that I can properly access functions and members of CvAStar from the path validation, path cost calculation, path addition, etc. functions without having to constantly refer to a pointer of the CvAStar instance calling the function.

 

[monju125]

Sure, you can use my code, so long as you attribute me if you ever release your implementation.

Absolutely. Wouldn't do it any other way.

Know though that the Experimental branch, and therefore version v10 and up, has A* classes structured differently than the current Master branch and the unmodified A* classes.
In the original code and all AuI code up to and including v9, A* classes worked with function pointers: the A* class had a bunch of function pointers for path validation, path cost calculation, path addition, etc. These function pointers were assigned to classless functions when the A* class' Initialize() function was called and were rarely (in some cases never) reassigned.
In all AuI code starting from v10, A* classes work with the FastDelegates implementation that Firaxis originally used as delegates for random number generators. The functions that previously used function pointers now use FastDelegates, and the original, classless functions that were originally loaded into the function pointers are now all members of the CvAStar class. Besides reducing namespace pollution and possible performance improvements, one of the biggest benefits of this restructure is that I can properly access functions and members of CvAStar from the path validation, path cost calculation, path addition, etc. functions without having to constantly refer to a pointer of the CvAStar instance calling the function.

Interesting. I need to look into doing FastDelegates for my implementation as well. I currently use function pointers for my task and heuristic functions and haven't seen a reason yet to switch, but that might be because my test plans are all fairly limited in scope. Currently I can replan over a 100 times a second over a fairly small planning domain, but it might scale poorly to larger domains like the ones I'll be dealing with in Civ 5.

Thanks, man. Great work, by the way. I've been passing it around to people asking for suggestions for AI mods on reddit.

 

[Mikemayday]

Hello, small question:
I've started a game with a different AI mod (Smart AI) then disabled it, enabled this one and now I'm continuing the same game. Is that going to cause problems?

 

[Mikemayday]

Ummm, sorry, doublepost.

 

[Delnar_Ersike]

Hello, small question:
I've started a game with a different AI mod (Smart AI) then disabled it, enabled this one and now I'm continuing the same game. Is that going to cause problems?

It should cause problems, seeing as even though quite a bit of AuI's code is based off of Smart AI's, AuI adds and retrieves certain variables from saved data that does not exist in Smart AI's save data (eg. AuI caches and saves each player's unique improvements). That said, you should notice fairly quickly if things mess up, since the game should crash in the next few turns after the load; if it doesn't crash, I guess you'll be fine.

 

[Mikemayday]

Alright, it didn't crash, so that's cool.
Problem is, I've been seeing some good old military stupidity - units embarking on a lake in the middle of a large battle, single units loitering in city range and getting bombarded while accomplishing nothing. I kinda thought such problems were fixed? Not being nitpicky, just making sure if the mod is working correctly for me.

 

[Delnar_Ersike]

Alright, it didn't crash, so that's cool.
Problem is, I've been seeing some good old military stupidity - units embarking on a lake in the middle of a large battle, single units loitering in city range and getting bombarded while accomplishing nothing. I kinda thought such problems were fixed? Not being nitpicky, just making sure if the mod is working correctly for me.

Those cases should be rarer in v9, but they still very much exist. This is primarily because the AI doesn't actually know how much damage units would take if they were to stay in a given tile, as the DangerPlots system it relies on only records a very rough estimate of how "dangerous" a tile is.

 

[Mikemayday]

Alright, thanks for the clarification. Out of curiosity, are there any hopes of such problems being tackled in any way?

 

[Delnar_Ersike]

Alright, thanks for the clarification. Out of curiosity, are there any hopes of such problems being tackled in any way?

Yes, I'm completely retooling DangerPlots in v10 so that the AI can accurately predict how much damage it would take in each plot (and also things like accurately predict whether a suicidal attack would be useful, whether sitting still and fortifying would be better than attacking a target, etc.). Unfortunately, this has a bunch of side effects, especially when it comes to performance (as you can imagine, constantly checking and verifying which units can damage a tile from where can be a big performance killer), which is one of the main reasons v10 has been in development for so long.

 

[Mikemayday]

Alright, that's great to know - I only started playing a few days ago, so my patience reservoir is full enough (gave up after one play after the game release because of the AI).

 

[Gort]

Very excited for a mod that both fixes the multiplayer AI and the standard AI problem of not being able to move and do ranged attacks. Double-excited 'cause it's on git.

 

[ThorHammerz]

Quick question Delnar,

As

void CvMilitaryAI::MakeOffensivePurchases()

is only called once per turn, that means that the AI is only capable of purchasing just one unit (ignoring anything from MakeEmergencyPurchases()) "offensively" per turn, regardless of empire size? .

 

[Acken]

Many of the buy functions are limited to 1 per turn. So that wouldn't be surprising.

 

[ThorHammerz]

Hm, figured as much... that certainly explains why the AI is often slow at mobilization.

 

[Delnar_Ersike]

Quick question Delnar,

As

void CvMilitaryAI::MakeOffensivePurchases()

is only called once per turn, that means that the AI is only capable of purchasing just one unit (ignoring anything from MakeEmergencyPurchases()) "offensively" per turn, regardless of empire size? .

Sort of. MakeOffensivePurchases() is called only once, but MakeEmergencyPurchases() also lets the AI purchase a single unit to complete an operation if they are in a war and not winning all wars (it's only called once as well though). If DoHurry() is configured to work properly, it can allow the AI to purchase a third unit as well (if it doesn't decide to hurry a building instead). So basically the AI can purchase one unit per turn if it's doing well in all wars and two units per turn if it's not doing well in all wars and it has at least one operation that is missing one "required" unit slot, with a possible third if DoHurry() is re-enabled and works properly.

 

[ThorHammerz]

If DoHurry() is configured to work properly.....with a possible third if DoHurry() is re-enabled and works properly.

Implying it's not configured properly in the mod...?

 

[Delnar_Ersike]

Implying it's not configured properly in the mod...?

It's not configured properly in v9, and I don't know if it's configured properly in v10: I fixed its issues on paper, but I've yet to see the AI use it, mainly because my v10 games tend to crash long before the AI has enough gold to be able to purchase something with DoHurry().

 

[ThorHammerz]

It's not configured properly in v9, and I don't know if it's configured properly in v10: I fixed its issues on paper, but I've yet to see the AI use it, mainly because my v10 games tend to crash long before the AI has enough gold to be able to purchase something with DoHurry().

Is your v10 the "experimental" branch (on Github)?

 

[Delnar_Ersike]

Is your v10 the "experimental" branch (on Github)?

Yup; master branch will always be the source code for the latest stable release, experimental is source code in development.

 

[ThorHammerz]

Do you think it would be a good idea to fully divorce the purchase-consideration algorithm for buildings, worker/settler, and combat units into separate routines? I'm currently experimenting with expanding the extant unit purchase algorithm MilitaryAI has (e.g. current GS, treasury/GPT, etc) and plan to limit the EconomicAI to non-combat purchases (when DoHurry() is working).

An spend-thrift AI might end up spending all its gold on whichever algorithm comes first (assuming the AI can now purchase multiple things per turn) and have no gold left over for the others, however (though that might not be a bad thing, and can be controlled by spending caps and whatnot).