How much parts is too much? Advice needed for Obby

Help and Feedback Game Design Support
#1

Hello. As the title already tells, I’m trying to understand how many parts would be too much for a game intended on mobile/tablet heavily.

My obby averages over 150 players at any given time. However I did a huge revamp and dropped the part count from 11k+ to 7.5k

I am using meshes, not parts nor unions so that my meshes can be instanced and memory won’t be as much as if I were to use parts. So that’s already really good for performance.

However, i’d like to add a bit more detail, I was wondering how much do you think is too much?
Keep in mind I want any and every device to be able to play… well ofcourse not really outdated terrible ones, but most.

All the render fidelity on meshes are set to performance and models level of detail set to streaming mesh.

No memory leaks with coding either, nor any huge big concepts that would chunk server memory, as well as most interactive if not all obstacles and cutscenes are client sided.

Any advice?
I know I can enable streaming however it breaks a lot of my stuff.
Everything is already moved really far apart from eachother, currently there is almost no lags or crash reports on dev stats.
But I do wanna add more detail.

1 Like
#2

If you’re having issues with Part limits, try implementing a rendering system.

In my opinion, this kind of system helps a lot in games that have to render a lot parts all at one time. With obbies, this should help even a tiny bit with performance.

If you want a pretty performant system, I’d try to make a system that “Caches” obbies in and out based on how close each Player is to that obby. I’d to this on the client and never on the server because each Player renders each obby differently at different intervals, etc.

By setting the CFrame of each obby to a large number (away from where the actual gameplay happens), you’re able to stop rendering of those parts and make sure players never see those obbies when they aren’t supposed to be rendered.

You could store a CFrame of each part in a table when the server first starts up, and when a Player gets close enough (you could make a chunk-based system or check the difference and give a constant radius):

local ObbyCFrames = {}; -- The table for our CFrames
local ObbiesFolder = workspace.Obbies -- Wherever your obbies are stored.

for _, Obby in pairs(ObbiesFolder:GetChildren()) do 
	if Obby and Obby.Parent then 
		ObbyCFrames[Obby] = Obby.PrimaryPart.CFrame; 
		
		-- ^^ I would create a 'Core' PrimaryPart for each obby (if it's a Model) that is Transparency 1, etc. 
		-- so that you can set each obby's CFrame off that one PrimaryPart. 
	end
end


-- UNRENDER (CACHE):
Obby:SetPrimaryPartCFrame(CFrame.new(0, -1000000000, 0)); -- Set it to something huge.

-- RENDER BACK :
Obby:SetPrimaryPartCFrame(ObbyCFrames[Obby]); -- Set back to the original CFrame.

Helpful articles:

3 Likes
#3

Thank you for your advice/input, really appreciate it.

Question though, do you think let’s say… 9k parts is too much for mobile / tablet devices? Considering all the other measures I’ve taken for it to be smooth/performance wise good.

My memory in game maxes out at around 680-700.

#4

I think 9k parts should not influence much at all, as long as you’re handling those well.

If you’re mainly worried about memory, controlling what renders and what doesn’t is something you should consider looking into. I feel like if you store most of the obbies or parts away somewhere such as ReplicatedStorage, they will never take up much memory unless you render them in.

I think that most memory usage comes from too many parts ending up in Workspace since that’s the service that handles all those physics, rendering, etc.

3 Likes