I am building a mobile RTS game with Unity that features over 200 active units on screen. The built-in NavMesh works okay for a few agents, but once the unit count crosses 100, the CPU usage on mid-range Android devices goes through the roof. Should I stick with NavMesh and try to optimize it, or is it time to write a custom A* pathfinding solution using the C# Job System and Burst Compiler to keep the performance high?
3 answers
For 200+ units on mobile, the standard NavMesh is likely too heavy because it runs on the main thread and isn't highly parallelized out of the box. I highly recommend moving to a custom solution using the Unity DOTS framework. By using the C# Job System and Burst Compiler, you can offload pathfinding calculations to worker threads. In my last project, we moved to a flow-field pathfinding approach for group movement, which handles hundreds of units with almost zero overhead because they all follow a single vector field instead of calculating individual paths.
Have you tried adjusting the NavMesh "Pathfinding Iterations Per Frame" setting in the Navigation window to spread the load across multiple frames?
You should definitely check out the A* Pathfinding Project Pro on the Asset Store; it has a local avoidance system that is much faster than Unity's default.
I agree with Linda, that asset is a lifesaver for RTS devs. It uses multi-threading very effectively and handles large unit counts much better than the native NavMesh.
I did try that, Christopher, but it created a noticeable 'lag' where units would stand still for a second before moving. It felt very unresponsive for an RTS. I think the bottleneck is actually the obstacle avoidance (RVO) more than the pathfinding itself. Do you think a custom RVO implementation would be easier to manage than rewriting the entire A* logic from scratch?