LODing AI to reduce overhead is a good idea of course, but is there any real requirement for this to be a universal or generic implementation, though?
Different projects will want to calculate relevancy/which LOD to be ticking in different ways, not to mention how would you separate the different AI LODs in the UI. There’s the issue of common behavior to be tackled - in the sense that it becomes quite complex if you want to show each LOD as a complete tree in the editor UI, it also becomes hard to show which behaviors are shared between LODs, etc.
The functionality you describe can already be implemented. Use a timer, or a service, with the bucket approach you mention, and have that store the player distance information in the blackboard of the relevant entities. By doing so you can reduce the number of times you have to check buckets for players, and can store and share that positional data between entities with the same blackboard. They can then either use a service or a condition in their behaviour trees to check the blackboard and execute the more intensive subtrees when necessary.
As I said, its a good idea in principle, but I don’t know if there’s a suitable one-size-fits-all implementation in order to justify incorporating it into the engine directly.
It would be nice if AI had a very efficient throttling to CPU load. Bot AI is the focus of the player (other than PvP focus) and tends to go from near to far. So there are three types of throttling:
AI check frequency by distance (true LOD of AI) with some random jitter.
AI check by count, do the nearest N AI’s every tick, then the next nearest M every other tick etc.
Tracking the milliseconds of AI processing and using a per-tick-millisecond-quota.
Such AI LOD would be settings on the Behavior Tree.
The implementation does not require exact distance from the player. The current nearest player distance can be calculated on a LOD basis too. The distance to player can be checked less freqently as the distance is further. Thus you LOD the LOD timing check too. You then keep a series of bins of distance from the players and the near distance bins are checked more frequently. To reword it, the distance and order only has to be roughly correct, so you take advantage of that fact.
This throttles the CPU load of the AI. In scripts the overhead of every-tick processing on 1000 AIs even if most do nothing is fairly high. We have found that a C++ state machine implementation is fast enough that the overhead of inactive tick checks is in effect zero.
Having AI LoDing is of course a good idea and there is a wide enough range of genres that we can cover with one generic solution. Regarding the details that’s another discussion. I’ll put it on our feature backlog, but I wouldn’t expect this happening this year (unless we hire lots of new AI programmers! )
)