One of the things that people love about Incursion and want to see more of, is the non-observed behaviour. They mention loving seeing signs that other life is going on in the dungeon. Now Incursion has that behaviour happening as if the player was there, but that is irrelevant and is the easy way to do it. Harder and more optimal would be abstracting it, and doing so would lessen the chance of the effect seen by the player being believable. Simulating is something games do not do enough of, and for good reason.
The difference between computer simulations and computer games is subtle but important. At the core, the distinction is that simulations are about things (or systems) and how they behave, and games are about a fun user experience.
When I said: "If a player cannot observe a behavior it is irrelevant behavior, likely indistinguishable from pure randomness or other simple fakery.", the pure randomness or other simple fakery portion refers to creating the illusion of some complex behind the scenes simulation. I disagree that faking is somehow more expensive or harder than running a real simulation.
Lets put this in a context we can all see and understand; a persistent dungeon level which a player returns to after N number of turns. There are three approaches to handling this:
1) Ignore it and revive the level just as it was.
2) Run N turns of simulation to bring the simulation and the player frames of reference into sync.
3) Fake 2 by a simple yet intelligent application of randomness.
I believe approach #3 is preferable because it is simple to implement in terms of programmer effort, less demanding of resources especially as N increases, and largely indistinguishable from the observable results of #2.
If I understand you correctly, I believe we really only differ on the level of abstraction. The higher the level of abstraction you apply to approach #2, the more it becomes approach #3. You can run an immensely detailed simulation, but if I as a player see only a small edge of it, it is largely wasted.
Bringing this all back around to the OP's questions; The less abstract simulation is the more expensive the AI implementations become. Consider that for a detailed simulation you treat the mobiles as Actors who are indistinguishable from players except for source of control input. They have their own FoV maps, complex decision making, pathing, etc, which runs every turn regardless of whether they are close to the player or on the far side of the map. Yes you can try to make this less expensive by caching various precalculations and deciding what mutations of the game state require recalculation of which portion of the various caches. I believe this is needless complexity compounding the original design error.
Alternatively, doing minimal calculations - extending and reusing the player's FoV, you can easily predict what mobiles will be observable within a move or two. At the point of transition between observable and non-observable you can apply whatever effects you like to make it look like some larger events have occurred behind the scenes - the wounded mobile stumbles into view. The simulation backstory takes place in the player's mind just as it would if you truly ran a full sim. If you desire the appearance of a larger encompassing simulation, you can track the observed 'faked' simulation events and weight future abstractions by them.
In other words, if you truly must have a simulation running in the background, abstract it to the highest degree you can get away with and keep it as separate from the AI as you possibly can. Spend the cycles you have regained on smarter decision making when you need it. The most sophisticated simulated world you could possibly run will be rarely glimpsed by the player, the responsiveness of the game and the presence or absence of unintuitive limitations and unexpected behaviors are far more noticeable.
