What do you want to achieve?
I’m spawning a bunch of R6 zombies. The zombies will walk towards the nearest player. My goal is to make it run efficiently no matter where the zombies are.
What is the issue?
Even though the zombies are in the same collision group (with no internal collisions), lag starts building up fast when they intersect. Using my ping as a benchmark, it increases from 70ms when no zombies are intersecting to 500ms+ when they are all in a big blob. The “Simulation” job listed in ServerJobs changes proportionally to my ping, so that must be the culprit.
What solutions have you tried so far?
a) using RunService.Stepped to set the CanCollide of zombie parts to false
b) setting NetworkOwner of zombie parts to nil
Unfortunately, having a lot of humanoids in the same place does put quite a load on the servers.
I’ve seen developers solve this by creating their own Humanoid system for their NPC’s which doesn’t impact the servers nearly as much, especially if they have over 50 NPC’s. This might require some advanced scripting, though.
Other than that, the only solution would be to not have as many NPC’s in the same place.
As far as I know, Collision groups do perform better than setting each zombie part to CanCollide false repeatedly.
An alternate solution to rewriting humanoids is disabling some of the states you aren’t going to use, maybe swimming and climbing for example. I haven’t tried it myself, but I’ve heard it helps performance quite a bit for lots of humanoids.
It’s odd because 50 zombies in one blob lags much more than 500 zombies spread evenly across the map, even though collisions are disabled. As far as optimizations go, there’s just one animation state for these humanoids, and that is walking which is set on spawn. The only job lagging the place is physics.
If there really is no way to make intersecting humanoid parts less taxing, I suppose the best solution would be to discourage the zombies from walking into grids with an already high number of zombies.
Been a long time problem with no definite answer other than that humanoids are expensive and hacky by nature. Thread I participated in back in 2017 with the same issue:
The Humanoid object does not cause any lag, in fact i believe it is a myth in this forum
Or at least not as laggy as people think
see my 1500 NPC test place:
These all have humanoids (and a single part)
And there is hardly any lag at all
I actually think it is the large amount of parts that causes the lag
if not that then it might be the fact that most people have one script per humanoid.
If your zombies use touched events to hurt the player then that might be the cause of lag;
i suggest using magnitude in a loop to find the nearest player.
(the same as pathfinding but they damage when the player is near not follow)
Your post is almost completely full of misinformation and unsubstantiated remarks.
It’s not a “myth”. The Humanoid object is very laggy. The backend of Humanoids themselves are expensive and hacky. There are already several threads discussing this, as well as workarounds beacuse of the fact that Humanoids are laggy. Example: Vesteria doesn’t use humanoids, they have their own custom implementation that they use.
I don’t think you’ve done enough research on this topic. Please go run through some threads. Even your repro lags heavily. The NPCs clump together, they don’t move efficiently (very sluggish movement, at times no movement at all) and the MicroProfiler is absolutely screaming with several bars spanning over several frames. The performance in this repro is terrible.
Don’t know what you’re talking about, “hardly lag at all”. There is very clearly latency in your game. Have you even tested and debugged your own repro? It doesn’t seem to be that way. Just because your client is running at what seems to be 60 FPS, doesn’t mean that things are going smoothly.
No, this isn’t the case. Part count hardly does anything to performance. NPCs are worth 7 parts, all limbs plus the root. None of the parts except the root are physically simulated because limbs are welded to the root. Welded parts behave statically. Collisions are disabled on all parts except the Head and the HumanoidRootPart for handling character collisions and raycasting.
Not relevant either. Developers use a single script to consolidate and streamline behaviour between NPCs. It’s much easier to handle NPCs, track down issues and update behaviour for an arbitrary number of NPCs than it is to update one script, then Copy + Paste updates into every other NPC’s script. This also fits well with structures that developers set up.
The number of scripts has nothing to do with the performance. You can still have the same inefficiency rate with a single script as you can with several scripts. Conversely, you can have the same rate of efficiency with many scripts as you can with one script, albeit with a negligibly higher memory usage cost due to Script instances being objects. By their own nature, objects take up memory.
looks like i didn’t explain what i mean’t properly
What i was trying to say was that humanoids don’t cause as much lag as people think.
I used to think they were extremely laggy but that was just because of the number of Player checks per second in the AI for them.
They clump together because i forgot to make their collisions work properly
There is 1500 humanoids in my test place, realistically there would only be about 100 of them in a game
Keep in mind there is 1500 of them. So all lag is expected.
i will do more research on this topic.
Thanks for correcting my post.
