AI -- the Thread

[Mark_Everson]

My favorite topic hasn't seen the light of day for a few months, and there's some new folks about. So how about some suggestions or constructive criticism

Thanks,

Mark

[Leland]

Now that you mentioned it...

I find the model qutie sensible, but it seems to describe only half of what goes on in AI, namely the behaviour and how it is structured. However, I think that there's a whole another side to the way the computer operates: the way it observes the world. What does the AI know about the game world? What's the underlying model or worldview it operates under?

Now, of course it is taken for granted that the AI knows what the game engine tells it... position of units, terrain, so and so much money in the treasury et cetera. But, in addition to all this AI should be able to grasp more abstract concepts like fronts, feints, bluffs, defensive or offensive units, strategically important cities/places, and so on. Perhaps this could be implemented in kind of another tree-like hierarchy parallel to the one described earlier, and the "plans" might use this information when determining actions?

(...but what do I know )

[LDiCesare]

Leland, there used to be a thread explaining how the map was "read" by the AI. Looking deep into the old dusty threads, you can probably find it. I don't have the time to unearth it now, but it explained how strategic importance of locations was computed (roughly: a place has more importance than another if many shortest-paths from a square to another go through this square- I hope that is understandable).
Role of units is not very hard to get through as units (or elements in them) have abilities like carry, ranged fire support, scouting, wall-breaching, etc. Attack/defense role is a bit harder to check as the model doesn't really provide attack/defense phases a la civ. Though in combined arms, having a tough front row and artillery behind is a good tactic. There are lots of information available to allow the AI to chose which units to build and how to group them effectively. Finding the good formula will be hard, but the info exists, which is already something.
Things like fronts, feints, leading armies into ambushes etc. we are still far away from indeed.

[Mark_Everson]

Thanks for the comments Leland, and the response Laurent.

As Laurent said we're partway (in modeling, not much code yet) into even some of the hard things. The Map AI info he was talking about is on the Map AI Page on Clash Web Site. Check out the Map AI Demo that Jim Cockram did using my Map AI theorizing. Its about half way down the page.

The map AI can provide info about geographic boundaries and regions, so I think, in addition to the things Laurent mentioned, we will also be able to do fronts. Strategic places/locations also comes out of the map AI and IIRC are even roughly discussed in the writeup.

Feints and such are going to be the hardest part, but I think we can do reasonable heuristics on that. Specifically you don't commit a substantial part of your forces for sure till you are certain the enemy is committing a substantial part of theirs. The GA stuff can help with that also. And besides, that is the hardest part for people too!

[Leland]

Thanks for the info, most enlightening. However, what I was more after was some sort of generic framework for the way AI "sees" the world, analogous to the framework that was described in the last page for how AI does things (Plans, Actions, etc.)... it seems that the map regions and such are features that several different kinds of Plans need to know about, which is why it looks like you'll need to figure out some sort of skeleton where you put all these heuristics and algorithms for analysing various concepts of the game world, as opposed to just stuffing all that analysis code inside determineActions methods.

I am by no means an expert, but since killer AI is one of the stated goals of Clash and no doubt will settle for nothing less than state-of-the-art (well, eventually...), I do have some academic interest in how you'll intend to solve the design issues involved. Algorithmic details I'll gladly leave to active contributors.

(End ramble.)

[Mark_Everson]

I expect you may be right after some reflection. I'm not sure we'll need everything you've described. . . I think we'll figure it out as we get a ways into coding and actually using the AI Plan stuff.

Thanks for the ideas, Leland.

[LDiCesare]

I'm bumping this a bit so I'll find it more easily next time I look for it:

I am going to try to implement the stuff we talked about. Just counting the number of classes needed makes me sick, but, well, a good AI is what I want, so...
I'll try to get the Delenda scenario, from Carthage as a good AI to start with. It should basically be variations on 'Destroy Rome', so the highest level ponderings on whether it would be a good idea to go at war or not and such won't be taken into account. I'll have enough work without, and I want Hannibal to attack. I'll create at least two plans, naval and land attack.

I'd like most of the plans to be scriptable or flexible enough that we don't run into a problem if someone finds a tactic the AI can't think of, so it should be adjustable by changing values in resource files (or adding a tactic description) rather than recompiling some stuff. I am not sure I will be able to do that and that will not be my first priority, but it would help a lot when adjusting the AI if anyone could do it, not just a programmer.

[Mark_Everson]

Originally posted by LDiCesare
I am going to try to implement the stuff we talked about. Just counting the number of classes needed makes me sick, but, well, a good AI is what I want, so...
I'll try to get the Delenda scenario, from Carthage as a good AI to start with. It should basically be variations on 'Destroy Rome', so the highest level ponderings on whether it would be a good idea to go at war or not and such won't be taken into account. I'll have enough work without, and I want Hannibal to attack. I'll create at least two plans, naval and land attack.

Sounds great Laurent! And being able to put together an attack with siege weapons etc will be a good intermediate-level test of the AI.

I'd like most of the plans to be scriptable or flexible enough that we don't run into a problem if someone finds a tactic the AI can't think of, so it should be adjustable by changing values in resource files (or adding a tactic description) rather than recompiling some stuff. I am not sure I will be able to do that and that will not be my first priority, but it would help a lot when adjusting the AI if anyone could do it, not just a programmer.

Agree completely!

[LDiCesare]

I have set up a few classes for the various plans.
Here are the 4 types I have started with:
Complex plans:
"Choice" plan (OR plan). Used to select the most successful subplan.
Sequential plan: The plan requires subplans to be executed in order. Failure of one subplan means the whole plan fails.
Parallel plan: The plan requires subplans to be executed, but not in any order. Failure of one subplan doesn't mean the whole plan fails.
Simple plans: Actions.

Each plan has a Success object. Successes are object, but could be numbers.
The question is: how do I compute the success of a complex plan:
An "and" plan has roughly a success which is the multiple of all the success value of the sub plans. An "or" plan success is the sum of the success values of sub plans.
However, there are rescaling factors in both cases. Plans probably need to have a success expressed as a proportion (0-1) (although it could be negative in case of failure), and a "value". That is, successful plan A means a certain value is reached. Value is different from success. That would allow me to have success as simple arithmetics when I manage complex plans, and value objects could hold more complex data if needed.
Opinions?

About Actions/simple plans:
I started a simple implementation in which an action runs its simulations in its own thread. That will certainly ot hold for very long, as you can't have thousands of threads running efficiently. Any ideas on how to regroup computations together so that it makes sense? I think of things like regrouping plans that seem to have lots of success into a same thread with high priority, maybe having one thread per civ, or two per civ, one for high priority (short term) and one for low priority plans (long term and plans which look unlikely to work but aren't trashed yet).
I won't go very far on the threaded part yet, but I want to put it in from the start because it is not very difficult, and we will have less trouble refactoring a bad thread design than making one up when the rest is complex (synchronization issues in particular).

I must make assumptions and simulation code next, then try to pour in some intelligence in the system.

[Mark_Everson]

Hi Laurent, everything you've said so far sounds pretty good to me. On the threads, I don't have a particularly good idea at this point. Your suggestions in terms of a number of threads per civ sounds reasonable so far. Another reason its good to start the threading now is that we don't want to slow the game down further

[Richard Bruns]

I know that heuristic AI is a dead end, but is there any way to do a quick fix so that scenario designers can give the AI instructions on what to do? Right now the AI can´t even switch unit production to a better unit when it discovers a new technology. Something simple that allows me to use events to change the parameters of the AI would be a big help.

For example, I would like to set the files so that a certain civ starts with a defensive attitude and production orders to invest a lot in technology. Then when it hits a horses knowledge of 1, a technologyevent changes the production orders to chariot 100% and the highcommand attitude to attack.

It also would be good to allow different task forces to have a different military attitude, so that, for example, the Carthage civ could be set on "stonewall" while Hannibal is set to "banzai".

Also, can you tell the AI to avoid fights it will lose badly? Right now it gladly tosses puny units at walled cities with enormous garrisons.

[Mark_Everson]

Originally posted by Richard Bruns
I know that heuristic AI is a dead end, but is there any way to do a quick fix so that scenario designers can give the AI instructions on what to do? Right now the AI can´t even switch unit production to a better unit when it discovers a new technology. Something simple that allows me to use events to change the parameters of the AI would be a big help.

For example, I would like to set the files so that a certain civ starts with a defensive attitude and production orders to invest a lot in technology. Then when it hits a horses knowledge of 1, a technologyevent changes the production orders to chariot 100% and the highcommand attitude to attack.

That should be doable. I can work on the econ side of it. Laurent, do you see any problems with this part?

Also, can you tell the AI to avoid fights it will lose badly? Right now it gladly tosses puny units at walled cities with enormous garrisons.

I've pushed for this a number of times. There were issues on it in my discussions with Laurent. You can probably find it a page or two back in the mil thread. Laurent, any re-appraisal on this?

[LDiCesare]

My only gripe about the whole point is the time needed to code it. I am starting to do all the stuff needed to get simulation stuff in the "real" ai, and it will take time... I'd rather not get sidetracked.
Switching production could be easier to do because it is an option needed for the real ai too.
I think it will be some time before I can provide the changes however, because I will have to stabilize the whole code while doing the ai stuff, which impacts a lot of stuff here and there.

[LDiCesare]

OK now I made my rant, I actually coded the production order stuff. I won't be coding the intelligence for siege however, because I think it is too complicated. I'd have to hardcode it instead of coding the actual ai which is supposed to be able to handle it efficiently with a totally different code. So I'd rather do the actual ai, unless someone has an idea of a simple algorithm (simple meaning simple to integrate, so it will hard to assess from the outside).

Anyway, since I have this change which allows a lot of improvement in scenarios and some other stuff (allowing elements of manpower 1 to survive without lasting forever...). Richard, Mark, do you think it'd be worth to make a new jar to send so you can actually use the improvements you asked for? Or do you think you may have more requests so it'd be better to wait a bit?

[LDiCesare]

Slightly more on-topic.
I am coding the fight simulation stuff. This happens to need a copy of all known military units to simulate. That doesn't look like a problem at first, as I just need to clone() them. However, transport units carry other units, which are referenced by taskforces. Keeping the links between all these is a lot of work. I have decided to make some simplifications so the simulated command structure may not always be accurate, although at task force level, it will be. This shouldn't be a problem until we get big layered commands which are embarked onboard another command fleet.
But.
It raises a complexity problem. So before I make any more choices, here is my dilemma:
Do I try to simulate everything (i.e. movement + fight) or make it simple in a first run (fight only)?
Otherwise put, I think it's better to make simple, limited simulations first, and only afterwards add complexity (moves...).
I may also need a model of the world for the ai, including all known enemy units. Is there provision for scouting/assessing enemy forces without sending armies in the surrounding squares?

[Mark_Everson]

Originally posted by LDiCesare
I actually coded the production order stuff. I won't be coding the intelligence for siege however, because I think it is too complicated.
(snip)
Richard, Mark, do you think it'd be worth to make a new jar to send so you can actually use the improvements you asked for? Or do you think you may have more requests so it'd be better to wait a bit?

Thanks Laurent, I'm comfortable with your take on what to do and what not to do now. (Ok with you Richard after hearing about the opportunity costs?) It seems worthwhile to me to get a new version of the testbed out to Richard as soon as he's likely to use the new features. Owen has also done some bug fixes and improved the colonization and settlement code, so we should definitly put out a new testbed version soon in any case.

Richard, should we rush to get you something? Alternatively if its going to be a while before you'd use the new stuff Laurent coded we might hold off until the coming weekend. Your call...

It raises a complexity problem. So before I make any more choices, here is my dilemma:
Do I try to simulate everything (i.e. movement + fight) or make it simple in a first run (fight only)?
Otherwise put, I think it's better to make simple, limited simulations first, and only afterwards add complexity (moves...).
I may also need a model of the world for the ai, including all known enemy units. Is there provision for scouting/assessing enemy forces without sending armies in the surrounding squares?

I agree with you, start simple. We don't have a provision for getting info without scouting. For the first cut I would just make the AI Omniscient. We can reduce the info to a more realistic level later in the AI development. At least that's what seems best to me.

[Richard Bruns]

I can be patient. I am finishing and fine-tuning the current batch of scenarios; you might want to look at those before releasing the next testbed. It would also be good if the official testbed includes my new files as defaults.

I say keep it simple to start with. That´s always a good plan IMO.

Why does it matter what units are being transported? How does that affect the fight, aside from assigning the transport units a support role so they try to stay out of the fighting?

[LDiCesare]

Transports will be important in teh long run because I must be carefult not to simulate the troops aboard ship as if they were on land, I also want to be anle to ferry them across a sea to allow for amphibious assaults. That's not near future, though.
Getting the ai omniscient in terms of units is probably more of soon-wasted job (no use populating the map with far away units unless you know they will take part in some fights). About the map, that sounds ok.

[Mark_Everson]

Originally posted by LDiCesare
Getting the ai omniscient in terms of units is probably more of soon-wasted job (no use populating the map with far away units unless you know they will take part in some fights).

I thought you were doing the AI for local fights. Why do you need to populate a map for the AI with irrelevant units? When I said omniscient I meant it knows everything about things it would want to know about. If that doesn't clarify things, maybe I don't understand exactly what you're doing, because omniscient sounds by-far the simplest thing to me.

[LDiCesare]

I need a map because I need the square and the units thare. That is actually simpler than what I thought, because in fact I limit myself to one square. The problem would arise if I had to check all the path from current square to target square if the square is far away.
Retrieving units from a square is actually more time-consuming for the ai than for the coder (I have to check all units in the world everytime I have to know the units in a square). I'll worry about that later.

Here is a small brief of what I have been doing. Nothing in the new classes even compiles yet.
I have coded Success and Plan objects. I am in the process of coding a plan corresponding to each order currently available to the ai. I started with a TakeSquarePlan. This plan has a simulation method in which I simulate fights in the target square. I code that as limited to the target square, and include militia. I still have to check the sieges code to make sure I don't destroy walls during simulations.
The way lists of units are managed has to be changed to accomodate the simulation process efficiently, but I'll do that only after I reach enough code that I can actually test it.
Armies are part of a Resources class that each plan has, and resources are also estimated for the enemy, locally to the square of interest.
To make a good simulation for far-reached invasions, I'll have to make a copy of the world, a known world, where I have maps from which units can be retrieved easily and fast, and corresponding to the invader's knowledge. That is not a priority, however.

[Mark_Everson]

Thanks Laurent, that makes it clear what you're doing. And its even more-or-less what I thought .

[LDiCesare]

AI simulation works.
I coded the ai from both ends, and am still far from finished, but I see the first results.
The (military) ai is all about giving orders to task forces. The objective is to simulate different strategies at a high level and find the most suitable one so each unit can be given the correct orders. Currently, taskforces are given orders, execute them, and then ask for new ones. If we keep it that way, the high level ai should have plans in which they know which order they want to give to which task force once these task forces have finished their current task.
However, if a simulation shows things should be ok, and an order has been given at a certain time, suddenly, reality may prove it wrong. For example, the taskforce realizes there is an unplanned for wall around Rome. So, what I did is, before every move, a taskforce will look for opponents in the destination square, simulate a fight, and decide what to do. If the fight goes well, they will attack. If it doesn't, they will cancel their order and ask for new orders.
The problem with that simulation is that it is done per task force. That means if you have 40 taskforces of 1000 men who want to go into a square defended by 2000 men, none will move. It is a bit hard for me to coordinate all the taskforces, so I added a new order, 'merge', which means a task force will try to merge with another task force in the same square. When such a merge order happens, the task force merges itself with another one. That allows the ai to build task forces instead of individual units, and to realize that 3000 men can beat 2000 men, and attack. Probably in the 40000 men example, 3 or 4 of the 40 task forces would merge together, some would move away to choose other targets, etc., but ultimately they will attack the better-defended square. Comments on this particular point are welcome. Other ideas about merging units or what to do when an order is irrealistic are welcome.

In scenario terms, that means Hannibal won't attack Rome unless he has a huge advantage. Considering he has no siege engines, he is still unable to take the city, but he will attack only if he "wins" the fight (which is very morale dependent in a siege, but usually straightforward in an open fight).

Some problems with this approach: The simulation run is a one-turn simulation, which will not be able to take sieges into account effectively. I'd be able to if I computed the amount of damage dealt to the wall, compared it to the ratio of damage taken, then considered that the army can breach the wall before they are totally killed. This has a drawback, however, which is that subsequent turns of fight will likely be different from the current fight, and simulation is only run when deciding to go into a square, not when already there.
Other cases when simulation is not run:
-The target square is owned by the civilization. The simulation doesn't consider allied troops (yet), so it is simpler to allow moves to defend one's territory because there are already troops there anyway.
-The player controls the troops. I didn't like it when Scipio refused to fight Hannibal. Sure, I knew he was going to be toasted, but that was my decision.

Now I must get back to the top-down orders ai which simulates things in separate threads, but I think this one is really a big step in the right direction.

[Mark_Everson]

Originally posted by LDiCesare
AI simulation works.
I coded the ai from both ends, and am still far from finished, but I see the first results.

Cool, Laurent, Great progress!

The problem with that simulation is that it is done per task force. That means if you have 40 taskforces of 1000 men who want to go into a square defended by 2000 men, none will move. It is a bit hard for me to coordinate all the taskforces, so I added a new order, 'merge', which means a task force will try to merge with another task force in the same square. When such a merge order happens, the task force merges itself with another one. That allows the ai to build task forces instead of individual units, and to realize that 3000 men can beat 2000 men, and attack. Probably in the 40000 men example, 3 or 4 of the 40 task forces would merge together, some would move away to choose other targets, etc., but ultimately they will attack the better-defended square. Comments on this particular point are welcome. Other ideas about merging units or what to do when an order is irrealistic are welcome.

I think what you most need is an order that has TFs go to a waypoint, wait x turns and merge with whatever's there. This should be the "goal" order in many cases while the AI is primitive. After whatever TFs are available merge then they can search for a relevant target given their power. Coupled with a "build siege engines" order this can also allow for reasonable attacks on walled cities. A suitable waypoint is the provincial capital closest to the "front". Most TFs should IMO start with the "assemble at waypoint" order. (If two choices are nearly equally good I would send the units to the closest one when built).

The waypoint idea also helps in that while waiting the troops are in an important defensive spot where they may do some good. When Fog of War is active the arrival of new units will actually make the players' challenge in taking an enemy provincial capital much better. There are lots more specifics I could suggest, but I'll wait to see what the response is first.

In scenario terms, that means Hannibal won't attack Rome unless he has a huge advantage. Considering he has no siege engines, he is still unable to take the city, but he will attack only if he "wins" the fight (which is very morale dependent in a siege, but usually straightforward in an open fight).

Some problems with this approach: The simulation run is a one-turn simulation, which will not be able to take sieges into account effectively. I'd be able to if I computed the amount of damage dealt to the wall, compared it to the ratio of damage taken, then considered that the army can breach the wall before they are totally killed. This has a drawback, however, which is that subsequent turns of fight will likely be different from the current fight, and simulation is only run when deciding to go into a square, not when already there.

I think the simulation should be run even when a battle is in progress. Otherwise I think the outline above is quite reasonable.

The player controls the troops. I didn't like it when Scipio refused to fight Hannibal. Sure, I knew he was going to be toasted, but that was my decision.

I would still like to have local-commander override of orders available as we had in Demo 4. The player can set the odds at which he wants all forces to abort an attack. That way if Scipio gets there and he is outnumbered he can consult the standard orders and abort as specified. If the player wants his units to make boneheaded attack then they can select odds of 0 or less as the retreat threshold. It would be better to use success chance than odds. If what you have can estimate success chances even for cases like walls that would be a vast improvement. Normally the setting would be say 1.5: 1 odds or better to stay, or maybe a 75% success chance. But the important thing is with one setting the player can change to overall risk profile of the field commanders. Eventually this number should be able to be overridden in an specific order, but we don't need that yet.

Now I must get back to the top-down orders ai which simulates things in separate threads, but I think this one is really a big step in the right direction.

Looking forward to seeing it in action!

[LDiCesare]

Progress report:
I haven't been doing much progress lately ('cause of work last month, now of GalCiv -good ai by the way-). I have reached a point, however, where the ai needs a map of its own to work with. I am not tackling the map ai, but just wanting to let the ai be able to "see" the map, so it knows only units which it sees, etc. I am starting to code it. I want to allow an option to show what the ai sees (helpful to debug the ai - and to cheat).
With that in place, it will later be posssible to add some spying so a player or ai can see some units where it has significant spying info. Currently, I will keep just show military info in the neighbouring squares. Longer term, the infrastructure should also be copied (so ai doesn't know that infrastructure increased in a square it's been to only 3 centuries ago).

[Mark_Everson]

Hi Laurent, sounds like a basically good plan. At least you are making some progress. I still don't even have an IDE since I "bought" one on ebay, and it looks like the slime I bought it from took the money and ran. . .

Originally posted by LDiCesare Longer term, the infrastructure should also be copied (so ai doesn't know that infrastructure increased in a square it's been to only 3 centuries ago).

I don't think this is practical or particulary desirable. In the real world there are lots of info flows that are not included. In that way even though you haven't been to a square in three centuries there are ways to obtain lots of info about it. Also, it seems that a detailed infrastructure map for every civ will use more computer resources than its worth.

BTW, I will be on vacation next week. I should have access to my email and the forum though, so it shouldn't cause any big problems. Just if you want to discuss some AI issues in detail, its best done before this Saturday. . .

[LDiCesare]

Also, it seems that a detailed infrastructure map for every civ will use more computer resources than its worth

That's also what I thought, so I decided to postpone that anyway. I think a single figure providing a composite "value" of the square could be enough for unseen squares. I agree that a square three squares away from your civ will have some contact info coming through, but an unseen square half the world away shouldn't.

[LDiCesare]

Now that the new ai seems to behave like the old (read - it works), I would like to test it to see if it can get some strategies to evolve. I am not sure whether the current scenarii will allow me to test it fully. I think it may be a good idea to devise a "for the ai" scenario, where you have choices of targets. Current scenarios more or less enforce a straight route towards the nearest target, so they needn't clever tactics (though timing, etc. are an issue). I will set my goal thus:
Scenario where there are 2 defender cities, one walled. I want to see the attacker 1) explore, 2) attack nonwalled city, 3) build siege weapons, 4) attack walled city. I let the defender do nothing at first. The difference with siegewars is that there should be a choice between attacking walled city or attacking not walled city.

[Mark_Everson]

Hi Laurent, your proposal sounds good to me. I'm comfortable waiting until you have something that's noticeably better before I get the code. I don't have a functional IDE right now anyway!

[Mark_Everson]

BTW how do you like GalCiv? Does it have enough long-term playing potential to make it worth getting? I'm likely to get it the next time I'm in the mood for serious computer gaming anyway.

I've gone ahead and ordered an IDE too, so I should be back in business by sometime next week.

Cya,

Mark

[LDiCesare]

Mark, I suggest you don't buy Galciv if you want to do something else. Otherwise, well, it is really worth buying, although it has a bit too much micromanagement at times (things like research points not carrying on from one tech to the following). But overall it is great, and the ai is quite good.
Here are a few strengths of Galciv ai (just to look like I'm still on topic):
- It attacks people if they are weaker, not if they are stronger.
- It can use destabilization/spying effectively.
- It sees when you make buildups or when you build 'culture bombs' in their sectors.
- It is very efficient in the opening.
- It trades between one another and considers the player as just another civ.
It has a few weaknesses too...

Back more on-topic:
I've got 2 weeks without apolyton access worth of remarks, so I am dumping my notes here:


I want AI to be able to attack walls:
AI must be able to switch production to good units. This means: It must be able to know what to build, so the ai must plan some kind of attack forces required:
It will say - I want to take city X. I find out that with current simulations, I lose, so I need more troops. How many? Also, I realize there is a wall, so I need siege engines.
This means the ai must be able to find out the available units, and for each unit, decide on whether or not to build it, based on the unit's stats: (Attack*Armor*Defense*Health), Movement, Distance, Morale?, Mobility?, FlankerEffectivity, Dispersion?, Cost, available orders: Attack/Scout/Skirmish/Build/Breach/Support.
Ideally it wants: Combat troops, divided in: Scouts, Skirmishers, Melee, Flankers, Support: Proportions should be ai-dependant/scripted. If it realizes it needs breachers, it will build some until it finds out it's able to breach the walls through simulation.
Obviously, I am going to start simple here. I just want to be able to ask for reinforcements and for breachers.

Now I have more or less coded the "ask for reinforcement of a given type" order, and it will take existing idle armies and give it to the required command.
I also don't know how to exactly model idle armies. I created a "reserve" order and give it to some units. Ideally, the success of that plan would be a percentage of total army so more units are not put in reserve when more needed elsewhere. This makes the current code have three different idle orders: Do nothing, wait for reinforcements to arrive, be in reserve. I may have to make things simpler at some point.

However, I still don't have the "change econ orders" plan. This is what I will really need now. If you have any suggestions on how to handle this, in particular what this means in terms of various levels of ai, I am interested:
The ai currently works by having units ask for orders to higher order plans, which take decisions when asked. This really means each unit executes its orders until it is over. So the high level ai is actually quite lazy, as it makes some computations in its thread, and gives orders off-handedly when asked by the real-world units. This doesn't work for econ orders, which never ask for anything.

I also have a few ideas about how threads should be implemented in order to avoid concurrent modifications, but that is still a bit murky.