I am working on optimizing FollowerEntity to support thousands of units. Right now I have a formation that is pathing the long distance and the individual units pathing to children of the formation. Only the units have RVO enabled. As a side note, I am not using FollowerEntity directly, I have setup a baker for it and work completely in ECS.
As I scale up, I start seeing multiple RepairPathJobs in the profiler at different points in the frame. Is there any way to reduce the frequency? Seems a bit odd that AstarPath.Update occasionally schedules JobRepairPath when the AIMovementSystemGroup is going to do it again at the end of the frame. Is this maybe caused by overflow from the previous frame?
I tried adjusting the Recalculate Paths Automatically, but it didn’t seem to change much. No matter how many seconds I put in its roughly the same frequency and frame time for JobRepairPath. Though I do get more stability with “Every N Seconds” on the units, probably because their destination is changing frequently.
The repair job is invoked once at the start of the simulation loop, and once at the end of the simulation loop, for each agent. This is required for the agent to pick a new direction when it has moved. Technically one could skip repairing the path at the end of the simulation loop, but in that case all properties like “is destination reached” and “remaining distance” would be slightly outdated, until the next simulation step.
You can reduce the overhead of the repair job by having static destinations (not moving them, or only moving them every N frames for example), and you can also make it slightly less expensive by not having them recalculate their paths as often.
The repair path job is also scheduled when a path has been newly calculated. While it is technically the same job, it actually does different things when the path is newly calculated.
There is some inefficiency here, it does some things twice. It’s there to avoid edge cases if any user code happens to run between AstarPath.Update and when the ECS systems run. But assuming path calculations less than once per second, it shouldn’t have a big impact.
So having units follow the child of the formation is probably causing a bit of extra overhead. I tried static destinations for each unit but didn’t like how they moved since the paths didn’t keep the units in formation. With my current solution I adjust the speed if they fall out of formation to keep them moving together.
Is there maybe a better approach for this kind of formation behavior?
You can update their destination only, say every 10 frames. That should make it almost the same as a completely dynamic one, but should have lower overhead.
Thanks