Hi there. I’ve played with your A* Pro off and on over the last couple years, and it has worked great in the instances I’ve used it. My question is: on a very large runtime procedural map that is online co-op multiplayer, would I be better suited using the Grid mover on NPCs, on the players, or not using the grid Mover at all? I have a test project working out the kinks in the AI pathfinding before I move it to the more developed Multiplayer project. I have MapMagic2 (runtime terrain generation), Digger ( runtime Digging terrains), and a runtime house-building system in this test project and have the Grid Mover attached to the player, and it’s been pretty smooth traversing heavily vegetated terrains (the odd issue moving the NPC between terrains sometimes) and having an NPC following me with the AI-path script attached to it. I also played with a half dozen NPC with the Grid Mover attached to them with smaller graphs, and all felt pretty smooth there as well. I’ve done a build and on a weaker laptop, and it all still felt pretty smooth. I expect at no time would we have more than 20 or so NPCs around the players at any given moment. So my general question is really trying to find out the best practices for something like this. Will I be digging myself into a hole if I choose one way or the other? Would another type of graph like Recast be better potentially (I played with a bit on a single 1k squared terrain)?
I figured before I get too much deeper into implementing a path-finding solution, there might be a better solution to save me some hours. Any help would be appreciated. Thanks in advance.
Hi
With 20 agents, a procedural grid mover might get heavy unless you have very small graphs. But if you have profiled it, and it works well for you, then all is good 
Also try the beta, grid graph updates are faster in the beta since they use burst.
Ideally I think you should have a single large graph, but your world might make that impractical.
You could try using a recast graph. That you would be able to keep in memory, even for a very large world.
Hi Aaron,
Thanks for getting back to me. I could be wrong but with all the Digging and the house building, wouldn’t using a Recast graph and graph cutting potentially not work well? From my understanding, cutting does not allow for adding new graph mesh. So if I dug a hole in the ground 4x4x4 meters, let’s say. Then the NPC could never get into the hole even if I made a nice low-angled ramp into the hole. Again, this is all at run-time. But maybe I misunderstood what you said in your documents with this quote: “With navmesh cutting you can remove (cut) parts of the navmesh that is blocked by obstacles such as a new building in an RTS game however you cannot add anything new to the navmesh or change the positions of the nodes”.
I’m using the Beta now since I had bursts 1.8.0 already in my project and the grid graph around the player seems to work a bit nicer though my frame rate was already in the 200s, so it was tougher to see an improvement. I guess when I bring it into the multiplayer project, and each player has one around them, we’ll know the real computational price for it. This brings up one last thing: for multiplayer, should I just have one ProceduralGridMover() script for each player? Can I just add it to another script that would hold a list of ProceduralGridMover() scripts and all the script details for each player? Do you see any pitfalls there? I figured if I did that when there were overlapping grids, I could turn off one player’s grid until they needed their own again. Since my players are kinematic, all ground detection is done by raycasts so I could determine when a player would need or not need a grid and then toggle it accordingly. Any pitfalls in that strategy?
One note for you: When I downloaded the Beta, I have to say it was a bit of a painful experience. It took me three tries on 3 backups to get it right. I’ll tell you what I believe messed me (and potentially others) up in your instructions:
You state in step 1:
- If you have installed the package previously “without using the package manager” then delete the AstarPathfindingProject folder before continuing.
So I “had” used the package manager to install Astar, so I knew from your instructions I “Did not” have to delete the AstarPathfindingProject folder. And that one little line messed me up the first two times. Then on the 3rd try, I figured why not just delete the folder and see what happens. And then everything went smoothly. I just wanted to pass that on to you in case you want to reword that.
With navmesh cutting, no. But you can also use graph updates with a recast graph. That will recalculate a whole tile (or many tiles) from scratch and it can handle arbitrary world modifications. It is slower, but it does run asynchronously. So for buildings and such that are relatively rare it could work well.
Should work. Make sure you configure the agents’ seekers so that they know which graph they are supposed to use. Otherwise they may get confused when the graphs overlap.
Hmm, yeah I should probably add a check for this in a script. Other users have gotten stuck on the same issue.
Hi Aaron,
Thanks for the crazy quick reply. I’ll play with ReCast a bit more before I commit to grid graphs. The building and digging will be heavy in the game, so I’m a bit worried about whole graph updates, but I’ll play with it and see.