I’ve been doing a sort of deep dive on the performance of MoveTo, and Roblox humanoids in general for NPCs. Here’s one of the charts:
The full article is here: What is the performance effect of a :MoveTo() on a Roblox humanoid? A deep dive - lukeshadwell.com
It’s a leaderboard for the number of tests each player has run!
So essentially, it is more performant to just use :MoveTo() rather than use Pathfinding at all. I suppose you could create your own module that acts as it’s own pathfinding api, and generate waypoints for specific paths.
Hardest part would most likely be detecting blockages (unless you implement raycasting, etc).
Is that the idea? To better shout about using :MoveTo() rather than using pathfinding service, at all?
I actually made a module for exactly this, it’s not finished yet but it’s able to walk to multiple points and jump over obstacles
I noticed two factors that could also affect the performance:
Otherwise, this is a pretty good test / benchmark on the MoveTo() method’s performance scale. I think with some optimizations to the code and using the bare minimum properties / states / anything would boost the count, but we’ll have to see one day.
Also, if you could uncopylock the game for others like myself to try out different tests, that would be nice.
Although MoveTo() is more performant than Pathfinding, the purpose of Pathfinding is to assist developers to sophisticate the MoveTo() method. This test doesn’t really mean you should ditch pathfinding service, but to be more careful about overusing certain methods and services.
In some cases, NPC pathfinding without the pathfinding service / a pathfinding service can be more or less performant. You can find a lot of Roblox games with the pathfinding service being used, but in games where there’s a bunch of NPCs (Zombie Rush for example), they’re most likely using their own programmed pathfinding service that may or may not contain the same procedures.
Roblox provided the Pathfinding service to provide an easy way to code NPCs, but obviously it isn’t the most optimal solution. I’d still use pathfinding service for when it’s needed, but I would also still use MoveTo() as little as possible. It’s best to keep an NPC’s path continued until the destination is dramatically changed or something interrupts the path.
So, this article is really just about isolating MoveTo() as a factor in performance, but as far as I understand there is no way to move a Humanoid along a path without using MoveTo. Of course you could move an anchored humanoid without physics simulation, using it’s CFrame though. That’s actually something I want to add to the game for testing - Tweening the humanoid along that path instead. I also want to add pathfinding to the point, but obviously it would be a pretty simple path it would be computing.
Cool, but how do we read the graphs?
And the conclusion is that disabling animations doesn’t help much?
The graphs ingame are labelled at the top, I’ve improved the labelling. They’re in 3 second increments.
The article should explain exactly what all the graphs mean but feel free to ask specific questions!
And in terms of animations yes that’s the main conclusion, it would make sense since I believe they’re rendered clientside. The main point of this was to just have good perfomance metrics for humanoids and moveto in general though.
