I had this issue years ago, I’ve only recently returned to ROBLOX. But then and now, I find no matter how small the map is. After about 10 units all pathfinding at the same time. The game just bogs down to a choppy state that no one would enjoy. And that’s not even taking into account how many other possible parts are in the map or scripts running.
Anyone know how I can improve these systems so I can in theory have more like 20-30 pathfinding scripts running at the same time? If so, please tell me what I need to read up on. Thanks.
You can try making a custom pathfinding system, but that’s probably very difficult. Out of curiosity, how much are you calculating the path? You can also show your script in #help-and-feedback:code-review to get some feedback on what can be optimized.
Since generating the path is the biggest laggy component of pathfinding, I suppose you could reduce the amount of times the npc runs the ComputeAsync function for the path.
If your npc just needs to walk to a point, then you can just have it create a path once and have the npc follow it without creating another path every cycle.
But if your npc chases players, you could have a system where it only pathfinds when it does not have direct line of sight to the player. otherwise, it walks straight at the player to reduce calling the function.
also, to avoid spamming the function when the player is out of sight, you could have the npc save the player’s current position and pathfind to it once, and only pathfind again when the player loses line of sight with the point or the npc reaches the point.
I’ve never actually tried this, so I don’t know if theres any funny situations this system could result in.
if the zombie can see the player by direct line of sight that most likely means it can walk straight at the player, ignoring a few edge cases. So in this case, you can save computation power by just having the humanoid:MoveTo() the player’s position
first get direction from zombie to player:
local dir = (player.Torso.Position - zombie.Torso.Position).unit
then make a ray by entering it’s start point (zombie’s torso)
and direction multiplied by maximum visual range
local raycastResult = workspace:Raycast(zombie.Torso.Position,dir*range)
if the raycastResult is not nil and the raycastResult.Instance is a child of the player, then that means the ray hit part of the player, so there is a line of sight between the player and zombie.
your probably doing the common mistake of constantly creating a new path while going to the given path. This is the wrong way to do FSM models. Instead you precalculate wandering paths and have them follow those tracks. Then, if a zombie sees them they explicitly calculate a path to their position where they are at, then after say 0.5 seconds you calculate them again. During the updating, if they lose LOS then have them pathfind back on their designated pre calculated path. Remember they are zombies they don’t have like insane 0.03 reaction time
(endpoint - startpoint) gives you a direction from the start point to the endpoint. Of course it is still a vector3 and can still be graphed as a point, but in this case we are using it as a direction.