[glob2-devel] resource gradients

[Nuage]

> Sorry, I wasn't clear about this before.  As I understand it, only one
> gradient gets updated each tick, and all gradients are always completely
> remade.  I think we agree that this is inefficient in many cases.  My
> idea is to continue updating one gradient per tick (for the most part,
> at least), but to provide a list of recent updates so that when a
> resource comes to be upgraded, it can decide whether a full rebuild is
> really necessary.  The only case I'm currently tackling is that if all
> the recent updates are convex, the gradient can be updated in a far more
> efficient way.
>
> Destroying a building is a good example of a convex change - all
> gradients can be easily updated by propagating values from squares
> adjacent to the building.  If the only change to a resource map between
> two updates is that a nearby building was destroyed, this should only
> trigger a minor alteration of the current gradient map, not a complete
> remaking.

Yes, if you remove a building, there is good chances that you can update only
the inside. No, it's not that simple. (take a look into Map.log for what I have
checked and computed some probabilities). Please design a full system.

Such events can trig a gradient update, local or global:
-resource grow (included other resource!)
-resource shrink (included other resource!)
-building creation
-building removing

For each of them, there is a probability to occur, a computation time needed to
take the trigger in account, and an update computation time.
(for fun, compare the mean time a resource to growth, and the actual mean time a
gradient is updated now)

My bet:
Detecting that only a local update is needed takes more computation time than
making timeout-based update of the full gradient.

My advantages:
- Much simpler system. So easier to understand. Less prone to bugs.
- The computation time does not depend on the number of buildings, not units nor
events.

Now if you think it's wrong, then collect the numbers and show what we can gain.
(there are already quite a few into Map.log)

Actually, I do believe we can do better, but that it does not worth the trouble.
I am first willing to solve the problem where too many units are dead-locking
into a corridor. Then, I may work on further optimisations.