Current state and plans for ECS integration?

Hi, I’m evaluating the options to switch (parts of) my game to ECS. Regarding the pathfinding library, what is the state of ECS at the moment? Are there some premade systems for pathfinding for entities or plans to integrate this? Maybe parts of the follower entity could be used without big changes?
And even more important: are there plans to integrate unity physics and attached entity colliders somehow in graph scans?

The background of these questions is the following: I’m working on an RTS and thinking about converting the units to entities. As the game is also physics based, it would be ideal, changing the entire physics system to ECS, so projectiles, forces and colliders can all be handled in the same system.
However, since I also have other types of objects, like buildings, that are constructed at runtime, I wonder if there is a way to include their colliders in graph updates when they are converted to entities and to include colliders in the subscene. I did some initial tests, but it seems colliders of gameobjects that are attached to an entity are not considered for graph scans.
Any ideas?

PS. Still kinda learning the concepts of dots, so sorry if the workflow or terminology is not totally accurate.


There’s a new movement script called FollowerEntity in the beta which uses ECS under the hood. It can be used completely without its monobehavior if you wish. The monobehavior is more of a convenient (but somewhat slow) wrapper.

However, it does not interact with the unity.physics ecs package yet. It uses the UnityEngine.Physics API (which I don’t think works with the unity.physics package? but to be honest I’m not 100% sure).

Thanks, I read through the source code.
So just to understand it correctly, I would pretty much use all the components mentioned in the archetype defined in the FollowerEntity, right?

The GravityState is used for aligning the characters with the ground?
The normal Raycasting is using unitys PhysX engine as far as I know and this is different from the dots physics package, so raycasting will not return any result if hitting a dots collider.
However, the FollowerEntity allows to define a Movement Plane Source. If this is set to Graph, what exactly happens? Does it use raycasting under the hood anyways?
In this case I guess I’d need to either use the movement system without gravity and run an additional custom GravitySystem or rewrite the AIMoveSystem and replace the raycasting algorithm with a dots physics raycasting algorithm?

It is used for gravity. Moving the agents downwards and raycasting to check for intersections.
If the movement plane source is set to raycast, this raycast will be used to align the agent with the ground. Otherwise the agent will be aligned along the graph’s natural up direction. I strongly recommend keeping it set to Graph unless you have a spherical world, for performance reasons. If your agent needs to rotate to align itself with the ground in smaller ways, I recommend doing that separately from the pathfinding agent.

Pretty much

Do you have any plans to include unity physics (dots) in general?
I think it could be quite beneficial for recast graph scanning/updates and potentially also for RVO.
Also in regards, that scanning entities will probably not work otherwise…

Edit: There is a github project that uses apparently dots physics to create a normal unity-navmesh. It looks rather simple, but maybe some principles can be derived from it.

Is there a baking/authoring component somewhere that can be used by people who don’t want to their entities to have game-objects? I think I could probably make one from looking at FollowerEntity.OnEnable(), but I just want to check before making that effort.


There’s no baking/authoring component at the moment. So looking at FollowerEntity.OnEnable is currently the way to go.

Thanks Aron!

I took your advice and built a baker/authoring based on FollowerEntity. Since I couldn’t add the managed entity in the baker/authoring I had to add it at runtime with an initialization system.

EDIT: I fixed all the issues below - see my follow-up post.

The problem is that it’s not behaving as expected. I think there are so many different settings to copy in and maybe I’m missing one of them or setting an incorrect default? I tried to use your default values for as much as possible.

I tried to upload a video here but this forum seems to have an error - it says the file is too big and the max size is 16MB, but the gif is only 7.1MB.

As you can see it’s all messed up. :laughing: While the agents are under the terrain, they are paralleling it, so that’s good.

If I change the RepathMode to Never (which is actually the setting that makes the most sense in this scene), the ground is completely ignored.

The authoring/baker that I just made is here: Assets/Scripts/FollowerAgentAuthoring.cs · master · Luke Clemens / AStarPfpBenchmark · GitLab

The whole project is here: Luke Clemens / AStarPfpBenchmark · GitLab

In the project there are two scenes.

  • BenchmarkScene is the old way I used to do a pure entities before FollowerEntity existed. It took over a month to get that working because I had to write and convert a ton of code and do a lot of research. The agents in this scene works properly if you want to see an example of what the scene is supposed to look like.
  • FollowerBenchmarkScene is the new way with the authoring/baker that I just wrote, which is broken. You can change agent settings on Assets/Prefabs/FollowerAgent.

I know you’re probably really busy, but if you could help figure out what is wrong, I’m sure other devs would be interested in trying out a pure-entities mode. The repo is public so other people can use the authoring/baker I made. @Chriss99 - were you able to get something working?

Good news - I figured out that the main problem was that I had the XY plane set instead of XZ. Once I changed that things started looking a lot better!

There is one thing that I still don’t understand… If I disable autorepath, the agents don’t move towards the destination even though it is set. Is there something other than setting the destination that’s needed if autorepath is disabled?

If you disable automatic path recalculation, you need to call ai.SearchPath to recalculate the path manually. I would normally recommend to not disable automatic path calculation.

OK thanks!

Another question - if I enable gravity, the agents start bouncing up and down again. The only way it works is with gravity disabled… but with gravity disabled, the agents go slightly underground when going up and down hills. Any ideas for fixing that?

Are you sure their gravity raycast mask includes the ground layer?

I’m not sure which setting corresponds to the raycast mask…

These are the settings:

I tried setting the Move Plane Source to Raycast instead of Graph, but that didn’t make a difference.

The Ground Mask is set to terrain - I tried it also with Everything but that didn’t help.

Are you using the inspector in debug mode?
I’d recommend not to (though I guess it works).

[EDIT] Oh, right. You have written your own authoring component.

Have you double checked that you actually propagate the ground mask to the ecs components?

It looks like it’s propagating correctly…


If you figure out why gravity mode won’t work, let me know so I can apply the fix to the repo in case anyone else wants to use the authoring/baker script.

In the meantime I’m going to go back to using the other package because when I benchmarked the A* Pathfinding Project it was able to run around 1,700 RVO agents before FPS drops under 60, but the Agents Navigation asset was able to handle between 9,000 and 12,000 agents with local avoidance depending on the mode. Unless there is some sort of setting you can think of that would improve performance?


Still no idea why the gravity doesn’t work for you. I haven’t been able to replicate it.

In terms of just local avoidance, this package can definitely match the Agent’s Navigation package (check the Lightweight RVO example scene, I can simulate 30 000 agents at >60 fps on my computer).
However, the FollowerEntity does a lot of work to provide very strict guarantees when it’s following the path. And I think this is the part where the agent’s navigation package takes a different and more relaxed approach (which is a totally valid approach, different needs for different games etc.).
I know of a few things that might be able to boost the performance, but likely not anything that will bring it to the 10k territory.

It should be trivial to replicate - simply clone/download the repository that I linked to above, open the follower subscene, enable gravity on the FollowerAgent prefab, and press Play.

Yeah I think you’re right about the pathfinding being more relaxed in the other package.

Anyway, I think I solved it though - I needed to put a Terrain Collider on the terrain game-object. I think that’s what Chriss99 was talking about and why he suggested the bustedbunny repo would be useful for using ECS physics instead of legacy Unity physics.

Chris99 - In my repo, I tried two different methods where in the first one I got A*PFP working before FollowerEntity existed. In that method, I was able to get pathfinding and RVO working while also using DOTS Physics (and a DOTS Physics terrain collider). It was a huge pain and a lot of work but it did work for the most part (though sometimes entities could get stuck). Feel free to use my code there if you’re interested. The guy who made Hostile Mars also used a similar approach (though I think he’s using a more home-grown pathfinding solution now).

Ah, yes, you definitely need a collider. The agents need something to stand on.