Are Humanoids laggy?

Help and Feedback Scripting Support
#1

I want to make a large, open world game. It will have many objects containing Humanoids, such as enemies and various interactive objects. My current understanding includes:

  1. Too many humanoid models will cause the game to lag, as too many moving parts on the client takes up memory.
  2. Too many humanoids containing scripts will cause lag, as that’s a lot of running scripts.
  3. Too many moving parts in the Workspace causes the server’s physics to lag.

My questions are the following:

  1. Will a lot of Anchored humanoids without moving parts cause lag?
  2. If there are lots of Humanoids in the Workspace (1000+) but they’re spread out and not all loaded by the client, will the client lag? Also, will the server lag?
  3. Is there a Humanoid limit I should be aware of? An example of a limit I’d worry about is something like the limit of 31 Highlight objects active at once.
#2

I don’t think spawning 1000+ humanoids is a good idea, from my experience 60-130 NPCs already causes me some server lag.

#3

if the NPC is made in the client, then just make them spawn in an circle area within the player’s character, to avoid lags.

#4

first of all why would you have 1000+ humanoids

  • despawn npcs which have been idle for a long time (15-30 minutes)
  • only spawn npcs if players are around or nearby

aand use collectionservice to handle multiple humanoids with only one script

2 Likes
#5

Would making it show/disappear based on the player distance to/from the Humanoids be an option?

That’s what I did for my avatar shop game where I have over 900+ standing humanoids on one large map but only a few are shown when I am close to them, and disappear when I walk away from them. Like a rendering distance type of thing

1 Like
#6

So I’m assuming you have a localscript that gets the nearest mannequins and hides the rest, right? In that case, are the 900+ mannequins still in the workspace on the Server side?

#7

Yes correct to both. On client side for my localscript, the mannequins are moved to a folder in ReplicatedStorage so its not being shown in workspace.

Example:

But here’s mine since it’s not lagging the game:

local refreshFrequency = 12 -- Amount of frames to wait before checking the distance of objects
local irfs = 0

local function updateRender()
	irfs = irfs + 1
	if irfs >= refreshFrequency then
		irfs = 0
		-- code here
	end
end

game:GetService("RunService"):BindToRenderStep("RenderSys", 1, updateRender)
#8

Having 1,000 + NPCs and them anchored doesn’t really do much besides add to part count; until you unachor them as you’ve probably witnessed. I’ve done this test before with 1,024 NPCs and by the time it gets to 150-200 NPCs it starts getting really bad on the server, the client is relatively fine because it’s not doing all the physics calculations itself. This is why you’ll notice a lot of these TD games will do custom networking along with custom humanoids, so that the server isn’t dying do to update time and constant physic applications.

If anything, you’d probably want the server to disable the Humanoids that are out of range by any active user. So the client won’t lag nearly as much as the server since it’s not doing the physics, just receiving constant updates of where the humanoid is, state etc, unless your machine can’t handle a lot of parts it should be fine.

As far as I know, I don’t think there is a humanoid limit (besides machine capabilities) but getting to a certain point definitely questions whether you should be using humanoids or something a little more custom.

If you’re worried about using memory, instead of reparenting to replicated, you can just have the skeleton of the model in replicated, then delete the ones being unused until the client comes in radius of the Humanoid. But to reiterate for however many times I said in this reply, most of the stress is on the server.

1 Like
#9

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.