A* Pathfinding Project

ECS based path finding


Hi, I’m working on masive multiplayer game and I’m looking for good tech that can handle over 20k entities.
I’v implemented navmash based path finding and it works good and scale good but I have a problem with avoidance and simple features like doors.

Do you have any plans for create job/ecs based path finding with dynamic obstacles?
I have up to ~21k simultaneously active entities in pure ECS, I want to make ~1k or all of them to work as dynamic obstacles and I need doors too.

So I have 2 questions.

  1. Do you have any plans for that? If you do than how long it can take?
  2. Mayby your asset have open source code included?

Maybe you don’t event though about it and we can start discussion here?

To provide more information:
I’m talking about map size equal to the 500 terrains 12500/1000 25x20 terrains.
Half of that will be covered by water and can be ignored by regular entities.

Path finding will be performed only on a small distance because it is isometric game.
I need to cover buildings floors and stairs too.


Ok I see you don’t want to response :slightly_smiling_face:
Soo what I’m talking about is taking advantage of well optimized for vectorization math library,
burst, IComponentData instead of MonoBehaviours, jobs and finally transform access which is the biggest problem speaking about scale.

So I spent one evening to dive into your asset and it looks like quite easy to refactor this asset into ECS and make it much more scalable and modular to give us possibility to include in build only a part that interests us.



The ECS/Job system is definitely interesting, most interesting being the Burst compiler which I really like.
I do not have any concrete plans for it yet, when i do implement it I would likely start with either RVO or the recast graph, both of which I think could benefit from the burst compiler (not so much the job system though, as they are already multithreaded). The downside of converting movement scripts like AIPath to ECS is that it increases complexity and reduces readability, especially for users that are new to Unity. Those scripts are the ones that users are most likely to look at and edit, so I am kinda hesitant to increase their complexity too much.
20k entities is a ridiculous amount though…

Job/ECS Support

I’ll try to create an example for a* pro for RVO and give you a feedback.
I agree its bad idea to “change” current asset for ECS but maybe a great idea to create new repository branch and create ECS/Job based as a new product. When I done I’ll describe here what performance I’m able to achieve.