Performance Problem with 500 Agents - Recast Graph

Hi,

I am using A* Pro with recast graph. It works well except the significant performance issue which I described in the below topic.

TOPIC

What should I do?

Thanks in advance,

One of the top things you can do is to only calculate paths when you need to. Right now, your repath rate = 0.5f. That means every half-second they request another path, which is probably much more than is necessary. I have two behaviors: people moving to a static point receive a huge repath rate (so they never repath) and those following another transform repath more frequently depending on their proximity to it and their target’s movespeed. This lowers their burden on the system so that those that need to repath frequently can, while others don’t.

Second, make sure that you are using multiple threads within your A* Settings. That can shove a lot of the cost off the main thread.

Third, you have a lot of modifiers. Is there a way to disable them when not needed? Can you achieve acceptable behavior absent them? Each adds some cost.

Fourth, you might want to think about strategies for managing off-screen agents. Can they go into a “sleep” state? Can they simulate their movement in a lower fidelity way, snapping back into a higher fidelity state when they come on or near screen?

Fifth, if you have many on screen, is there a way to organize them so that most do not request long paths? It can get complicated, but one thing that can be done is organize your agents into squads. There’s a squad leader who requests the full path. The others merely path to be around the squad leader. This means that most of the paths requested by the squad are small, while only the leader requests anything substantial.

1 Like

Thank alot for your suggestions!

  1. Basically, you are totally right, these agents are civilians in a city, hence there are several static waypoints and patrolling between them. If they are not interacted by player, there is no need to repath since the city is totally static. So, how can I do this, is there a simple way? In RichAI, I can modify this simply but, should I manually disable it after each waypoint is activated?

  2. This is a mobile game, so is it OK to use multiple threads? Actually what I am thinking is, the game is not so lightweighted so the phone required to play smooth should be a nice one where usually these phones have multiple cores.

  3. What do you mean by modifiers? Silly question I know, but I did not understand :slight_smile:

  4. How can I do it, I did not understand this too. Because, alhtough the agents are offscreen, they nood to patrol between waypoints?

  5. Grouping will not be the case due to game logic. Does it also matter if the path is short or long if the waypoint is static and no repathing is used? Because, the agents will not stop, continuesly patrol between waypoints.

Additionally, I implemented RVO for my agents which significantly improved performance. I removed character controller and did not implement any raycasting for ground since I donot use gravity, all on ground. But still, I need more gain :confused:

So you have some script that assigns the waypoints, right? What you could do is have a script that monitors how proximal the agent is to the waypoint. If within a small distance, it has effectively reached the waypoint, so you give it the next waypoint then retrigger SearchPath. In other words, manually check how close an agent is to completing the waypoint then once it’s good enough give it the next waypoint and force repath. This lets you keep the repath rate to a huge value so these agents repath only when necessary.

Yes, using multiple threads should be fine and should improve performance.

I mean RVO, Funnel Modifier… these things that enhance the path’s look and behavior. Simpler AI is cheaper. You’re using RichAI which is kind of like a simpler AILerp plus some modifiers. Maybe it’s possible to downgrade to AILerp - which is cheaper. I can’t remember which scripts work with RVO b/c I wrote my own to simplify. The overall lesson is: perhaps you can worsen your agents behavior to just above an acceptable level and thus save some performance.

Here’s an example, perhaps too extreme for your case: lets say an agent goes a ways off screen. It then shuts itself down. Instead of using expensive AI stuff, you simply Vector3.Lerp the actor toward its next waypoint through very simple Vector operations by manually moving its transform. Since it’s way off screen it can move through walls to keep everything simple. What’s important is that it approximately moves toward the waypoints. When it reaches the waypoint, it does the same toward the next waypoint - making no path requests and staying in its sleeping state. Occasionally you check how close your agents are to the player. If within some threshold (and thus at risk of soon coming on-screen), you snap them back into an awake state and (if was on some obstacle) move it to a viable location and let them really navigate to their waypoints. And so only when the player is close by do you have any agents doing anything. Those who are really really far away could not navigate to waypoints at all and instead just not move. In the same vein, you could even completely remove agents from the game until the player comes nearby: instantiate them when and where they’re truly needed.

Squads only make sense if per your game logic / design squads are something that exists in your world, e.g. several soldiers moving together. If it doesn’t make sense for your game, don’t bother with it.

1 Like

Finally, you should be aware that Deep Profiling really takes a toll on performance, so you’re always best off profiling in a built game on a target device to get the best picture for how things really perform.

1 Like