Worker map and multiple villager building speed

[MaanooAk]

I originally tried adding a vector of ClentUnit pointers to the ServerObject to keep track of workers, but then there was too difficult and possible buggy to maintain the list. So my idea is to have a map from ServerObject to ClentUnit:

  /// A map from objects to all of their workers. Workers are considered:
  /// - For buildings under construction: all the villagers building.
  /// - For buildings/units being repaired: all the villagers repairing. TODO: implement
  /// - For resources spots: all the villagers gathering. TODO: implement
  /// - For farms: the villager farming. TODO: implement
  /// The map is reconstructed in every frame.
  std::multimap<ServerObject*, ServerUnit*> workers;

The key is that the list is cleared at the start of every simulation step and used in this way:

    bool firstBuilder = workers.count(targetBuilding) == 0;
    workers.emplace(targetBuilding, villager);

The advantage of is (compared to a vector in each object) that you don't have to find all the cases where the villagers stops building and go update the list.

Note: After the "too many villagers -> retask" is implemented we can figure out if the ServerUnit pointers are needed and if not the map could be reduced to a std::map<ServerObject*, int> keeping track of just the number not the actual units.

I think this design opens up a lot of things to be implemented easily. What do you think?

This is quick pr before I go back to stats...

[puzzlepaint]

+1 for the per-frame check.

I think that instead of the multimap, it might be sufficient to store either only the number of workers per object, or only a bool saying whether any worker is currently working on an object.

• For building and repairing, it seems that only the first villager behaves differently than the others, so it is sufficient to know whether any villager is working on it already.
• For farming, only one villager can work on a farm.
• For the "too many villagers on a resource tile" check, I imagine that this would mainly depend on the pathfinding being able to find a (sufficiently short) path to the resource. For example, a tree could be accessible only from one side (in this case, maybe 2 lumberjacks can work on it at the same time), it could be a straggler tree that can be accessed from all sides (then maybe 8 lumberjacks could work on it at the same time), or it might be in a thin forest, where it can be accessed from the front and the back, but going to the back side would require taking a long detour, so only 2 lumberjacks should work on it from the front side at the same time. So, I think that a check based on the number of workers only won't be sufficient for that, although it might help to some extent, for example if 20 villagers are tasked to a tree, then it is clear that not all of them will be able to reach it (at least not at the same time, but still at different points in time ...).

I might be overlooking some other applications where a multimap might be useful though.

Let me know whether you want to merge this as-is (as it fixes the multi-villager building speed) or whether you would be fine with a std::unordered_set<ServerObject*> hasWorker or std::unordered_map<ServerObject*, int> numberOfWorkers as well.

[puzzlepaint]

Actually, to minimize friction, let's just merge this directly and then keep in mind to revisit it when implementing the villager distribution mechanism, as you suggested.