If one has 1000 NPCs and each is being checked each tick, it can get very innefficient even if the Behavior Tree has some delay to only process AI and physics evey few seconds. You are still calling 1000 checks per tick.
It would be great to have a physics LOD and an AI LOD where the distance from the nearest player can cause the AI or Physics to get called every N ticks. In particular phys checks such as capsule movement can be done on larger time intervals for NPCs. What would happen is on the Nth tick you calculate N times faster motion for one tick and then do colision and such. Then the capsule interpolates for the next N-1 ticks with no physics.
We did this in The Dead Linger and got 1000 zombies moving in a large area with almost no processing overhead for physics, animation, or AI. We also had a max on X physics updates by nearnes to the player. Thus it was a quote of processing then quit till the next tick. So in crowds it was efficient and in countryside the more distant zombies were more active. This pits the CPU cycles where they mopst matter for the player(s).
Too bad you’ve combined AI and physics in one questions since there’s no single person that can give you an answer to both things
Regarding AI however we do have an AI LOD system somewhere down our backlog, but it’s low priority and is not going to be done anytime soon. I mean it’s not a low priority idea, it’s just there’s so much more burning issues we need to handle first before we can move to “would be nice to have” features. Don’t hold that against us, please
Not holing it against you. We did a performance test on the Behavior Tree and AI that way and found that 1000 IA’s doing nothing dropped us to 17 fps. So we have done custom C++ state machine based AI, which is almost the same.
So now we control AI processing and CPU load.
It is a root BT node, and bunch of Selectors, and each selector has a sleep 10 sec, a ‘print the current state BTT’ and a simple state BTT. So most of the time is spent in the sleeps.
But in the last 2 days we have replaced the BT completely with a custom C++ Character implementation that does a state machine AI.
If by ‘sleep’ you mean BTTask_Wait then it’s a busy wait and could easily be changed into a proper, event driven wait which would bring down the BT time to almost nothing. But for 1k agents I’d go with custom solution as well anyway
