Openage: Grouping resource collection to save CPU

[Piruzzolo]

In the original game, when a lot of workers all work at the same resource tile they make frequent collection calls (C)
time-------->
x---C1--C2---x---C1--C2---x---C1--C2---x

C1 stands for "call of worker 1", likewise C2, traits are frames, x is the nth frame

When the resource collection is off-screen (i.e. the player doesn't watch), we could "group" resource collection calls from miners, lumberjacks and others in a single one, to save CPU, so that, say every nth frame, the resource tile value is resource -= (number of workers) * (resource taken by each worker). As a worker is full, the resource (and the rate) diminishes by a worker until he comes back to work.

Something like:
time-------->
B{1, 2}----------B{1, 2}----------B{1, 2}---G1------B{2}---R1------B{1, 2}

• B{1, 2} is "big call {worker 1, worker 2}" (B is at frame nth),
• G1 is when "worker 1 goes",
• B{2} is big call with worker 2 only,
• R1 is when "returns 1"

The resources taken by each worker would be updated syncronously in the same nth frame, with a delay to take into account the time workers actually began working at the tile (so they're not full all at the same time - wouldn't be faithful of the original game)

[zuntrax]

Is this really a bottleneck? Do you have profiler results? As long as we stay close to the original game, there is a cap to the amount of villagers harvesting from the same resource node, so the actual speedup would be limited.
Also there would be quite a few corner cases to keep in mind:

• Every player could potentially watch the resource node.
• Multiple players could be harvesting from the same node.
• Resources need to be distributed correctly when the node is mined out.
• How would this behave for recordings and netcode?

In total, the added management logic could easily take as many CPU cycles as "just decrementing the resource counter" for every harvester every few seconds.

@TheJJ @mic-e What is your opinion on this?