We are still using Unity navigation system, but it is very obvious now, that it’s just not good enough for our game. We need a smart local avoidance for our agents who need to have various priorities, so that the boss does not move to make a way for a simple common enemy, but continues moving on the shortest path to the objective instead for example
Also our enemies/agents have different sizes - from small to very very large, therefore we have been using multiple NavMeshes. We need this feature a lot.
Also the enemies have various max speed, which puts a lot more pressure on the solid local avoidance system. Especially in the combination with having different priorities for each enemy type.
It’s an already demanding mobile game. What do you think of performance with A* Pathfinding Project, provided we use all the features I named on like… 60 enemies tops?
What graph would you recommend? Will multiple NavMesh graphs per scene for various size agents provide all the features and great performance at the same time? Our maps are huge 2x2km, while some obstacles like various rocks etc. are small. So a grid graph would need to have a big resolution. I also don’t see where multiple agent size would come into play in case of the grid graph. I don’t see any setting for it there.
We don’t need no fancy nav mesh linking, nor steps, multiple floors or anything like that. Our maps are mostly flat (at least the roads are, meaning they could literally almost perfectly lie on a simple plane).
A* Pathfinding Project seems like an only path to our salvation. Nothing else looks that advanced, not by a long shot.
I’ve been happy with using the project for a professional project, though I have no experience with TD games. What you’re talking about - some local avoidance agents being more important than others - works out of the box. You’d just set the boss’ rvo agent to the rvo layer “boss”, and turn off collision with the common enemy’s layer, and turn it’s priority way up.
The obvious upsides compared to Unity’s built-in Navmesh is that you get the source code, and that the author replies on the forums. Both of those things means that it’s actually possible to fix any shortcomings.
For example, the way both Unity’s Navmesh Agents and the A* project’s default path modifiers handles corners is to try to stick pretty close to them. That does not look good if those agents are pedestrians on a road, you want them to take pretty wide corners. For Unity’s system, handling that means setting multiple destinations, and dealing with slowdowns in between. For A*, there’s an API for customizing how paths are postprocessed, so you can just set the intended target and deal with the navigation through that API.
Unfortunately this package and Unity’s system use very similar local avoidance systems. Both use a variant of RVO. There are some difference in the implementation, but they share many of the underlying assumptions.
You can set priorities both in this package as well as in Unity’s navmesh system (have you tried that?), or as @Baste mentions you can make the agents completely ignore some other agents.
Multiple agent sizes can also be used in this package. You can create multiple graphs and then make an agent use them. This is relatively rare so currently this is not exposed in the editor however (I probably should do something about that though). You set the graph by passing the ‘graphMask’ parameter to the Seeker.StartPath method call (which is called by the AIBase.cs script if you are using one of the built-in movement scripts).
With large worlds, recast graphs really are the only way to go.
Thanks for a quick reply, both of you. Seems good so far. Just one more thing about the local avoidance, to be 100% sure whether it’s going to work for us or not. Let’s use an example:
Slow, high priority, huge enemy is moving over a bridge, where there is no space to the left of him
Fast, low priority, small enemy is closing in on him from behind and needs to move around the huge enemy at his current speed, no enemies can ever slow down! There is just enough space to the right of the huge enemy.
Can I be sure, that he will choose the right path? Is the local avoidance smart enough to foresee the the path to the left of the huge enemy is not available?
If not, what would you recommend? Is it even possible to achieve without implementing my own local avoidance? Is there any other way? In the worst case scenario, I can just make the huge enemy clear the path even for 20x smaller enemies. But in that case I need to be sure that he will never slow down, or change a direction completely, not even for a second. It would make no sense if he would delay his devastating arrival to the objective just to make a way for a small little enemy
Your help is greatly appreciated guys, navigation is a new topic for me
No, the smaller low priority agent will currently slow down a bit and then move to the closest side of the larger enemy. It will not necessarily pick the right side. RVO only finds a local maxima, not a global one unfortunately.
The larger enemy will not slow down much assuming the priority is high enough (or not at all if you use layers as @Baste suggested).
What if I would use the “Navmesh Cutting” to cut out the part where the huge enemy currently is?
If the local avoidance is somewhat the same as in Unity navigation system, what else could the A* Pathfinding Project offer as a bonus to my project? Except for the possibility to run the navigation within the FixedUpdate function, which is a nice bonus
The the huge enemy would be very confused as the navmesh below it disappeared. It will try to avoid itself as it doesn’t want to be outside the navmesh. It is possible with a bit of code to use one navmesh for the large enemies and one navmesh for the small enemies and then the large enemies would only cut the navmesh for the small enemies. I suppose that could be a solution for you. Though as I said it requires a little bit of code, but I can show you that if you want.
Thanks for the quick replies, I definitely want to give this a try. At the same time I am checking Polarith AI and NavAI assets though. And all solutions cost pretty much 100$. And neither even mentions how it will perform on mobile (or I just overlooked it). Is it possible to benchmark your solution WITH local avoidance as well first please? I can imagine it’s a costly operation, especially if I’m going to use the realtime NavMesh cutting with it. So I would like to make sure that I buy just the one solution I will use, if any will be suited well enough for our use case even
Local avoidance is not that expensive actually. Pathfinding, rendering and navmesh cutting is generally more expensive. On a desktop it can support over a thousand agents.
I can send you a code so that you could try it out if you want.
The local avoidance can use the navmesh (with the RVONavmesh component which adds local avoidance obstacles based on the graph borders), however on mobile I would suggest that you avoid that as when cutting the navmesh very often it will be quite slow to update the local avoidance obstacles).
Note that I think mobile could handle the cutting itself, however converting the graph borders to local avoidance obstacles can be heavy, so I recommend that you do not use the RVONavmesh component.
Also. If you try out the package, try the beta. It is usually more stable (as in few bugs) than the release version anyway and it has more features and fixes.
