Large Part Count & How To Defeat Lag



Hi there everyone!

So my game has almost 40K Parts and 80K Instances in Total, which is not good for lower end devices :disappointed_relieved: & it also lags when I move around and do stuff in Studio which is Annoying and I hate it so much.

But I’m a Scripter so I can Script in a separate place HAHA!

My goal is to open my game to Mobile & Tablet after releasesing the Game to PC first and once it gains popularity.

(I don’t want to focus on too many things at once that is why I am optimizing for PC first but Part count benefits all devices)

Anyways I am pretty sure there are Experienced Devs that has a few Tips/Tricks of there own.

So for my sake, the player’s sake and other Dev’s that has this problem sake, please tell me ways that can reduce lag due to Large Part Counts.

Thank you


I am a scripter so I do not know much about building in fact my Building Skill sucks :joy:

Please remember that I’m not the Builder so I don’t have control over how my Builder builds but I can always guide her to what she should do to help reduce lag, so let me know.

I know that there is no such thing as No lag Script, it’s the most ridiculous thing ever invented because how can more Script Activity = less lag?

What I am already doing

I know some of you will say “Lower the part count”, well my reply to you is “no can do”.
(I mean I can delete Parts/Instances that are unnecessary which is what I am already doing but all the parts that are left are needed for the game)

Most if not all Parts are Anchored.

I already have a plan to Teleport Players (NOT using Teleport Service, just CFrame stuff) to other buildings that are far away from each other. (which leads to my question down below)


Does putting Builds far away from each other or the origin help?

I will leave a link to a separate game with the builds when I get home (My main game’s closed to visitors atm so Linking it now wouldn’t help + I do not want to leak my game so I will add people that reply to this Thread to the Whitelist :+1:)


Putting builds far away from each other would improve things; however it also has some cons which I will get into after why it is good.

You want to remove as much stuff from memory as possible, as well as reduce the amount of stuff that needs to be rendered.

If you have anchored 100k parts behind you and you are looking forwards at an empty baseplate than you should have significantly better performance than if you were looking at the parts.

Honestly I’m no expert on this area of Roblox at the moment.

If you have builds far away from each other, you will start encountering floating point decimal issues. You should be able to get a good description of that issue by doing a Google search, but essentially it means that numbers like 5.0 and 3.6753 will be defined inaccurately e.g. 4.999999999 or 3.67.
It gets worse the farther you go away from 0,0,0.
It will cause big issues with basically everything, but depending on the size of the game it won’t be important.


I don’t know exactly how your place looks like since you did not provide us a link to it - please do that. It helps us help you.

A solid way of improving performance is to combine a lot of parts to single MeshPart instances where possible. It is not suitable for all collections of parts, but if you can have a single MeshPart instead of ie. 1000 Parts you have a lot to save.
Try to avoid a lot of moving and unanchored parts if they’re not absolutely necessary. Colliding parts are especially bad in that sense.

If all your parts are anchored and opaque (non-transparent), they’re already really efficient.
MeshParts should have CollisionFidelity set to Hull or Box where possible to not store a lot of detailed, unneeded physics data.

The biggest memory hog is very often textures. Meshes with Textures, Decals, ImageLabels, ParticleEmitters, Beams and so on. People tend to use very high-resolution images in places where low-resolution would be sufficient. You do not need a 512x512 image for your ParticleEmitter when a 128x128 or even 64x64 could get the job done. Similarly you do not need a 1024x1024 image for a Beam if it’s so tiny that you could get away with a 64x64.
Reducing the rate of ParticleEmitters could also help some.

You could make a Level of Detail system which shows less detailed models/maps for low-end users and loads in the details for high-end users.
Alternatively (or additionally) you can load in the objects/zones they need to see when they need to see them. MeepCity is an example here; they load in areas only when the player visits them.

You can also consider turning on Streaming for your place. It will help you with the “loading in objects only when they’re needed” by only rendering he objects when the user is close enough. Streaming still has some weird quirks and might require you to adapt your scripts to how it works, but it is worth a try.

These are my top tips. You need to choose what you want to do, and not all tips may be ideal for all types of projects.


@EmeraldSlash @Ravenshield

Game Link Seriously 30 Clicks? You really want to know what this is do you?
I will open it to DevForum members later, only to people who are in the DevForum Group will be Whitelisted.

Please do not leak my game.

Others can’t join the game just you 2 are on the White List, if you have any suggestions or want to discuss about my game please take it to DMs.

You can use these commands in chat

;speed number
;jump number

to move around in game faster

Thank You!


It is quite hard to play on my phone due to performance, yes.
The first thing that strikes me is the size of the map. Does it have to be so big? It feels like you’re just endlessly walking, and bigger also means you need more things to fill. Are you planning to fill in all the empty area that you currently have?

Average memory was at around 440 MB, with Textures taking up most of the memory. Textures took up 313MB out of the 739MB allocated for PlaceMemory. I assume this is mostly the textures from your foliage/bushes, since you have a lot of those bushes (including the “vines” on the buildings behind the dorm). Other than that, it was running at a steady 60 FPS on my computer and I could not see any obvious performance sinks when I explored the level.


So from what I’ve learned about laggy games isn’t necessarily the part count (though that does contribute to the performance) it’s also based on the amount of scripts that are running in your game. A few ways to solve this would be to form unions with your parts, lessening the count.

I don’t know how many scripts are in your game but if there’s more than 20 I would consider putting a few inside of each other that way they aren’t all running separately. (Another helpful tip could be to make your main script a model then make a script to require the main script, I know a few people who have big games and do that and they don’t lag as much because of that)

And the third way would be to add fog, so that way the player doesn’t render the entire map, only a good chunk of it, depending on where they are at.


I would advise against unioning unless your array of parts is supposed to move or otherwise interact physically (not just static collision). Each and every unique UnionOperation needs to be downloaded from Roblox every time you enter the place, which puts additional strain on the client upon startup. Parts are generally lightweight as long as they’re anchored and opaque (or entirely invisible, because then they don’t render).

The amount of scripts also do not usually impact performance that much. The important factor is what the scripts do and how performant (optimized) your scripts are. The script instances in themselves do not cause performance drops, but the executed code might. There’s really no difference in having the ModuleScript local in the place or if you’re loading that from a model, because the source code is loaded in either way.


I have 1 Script 1 Local and 1 Module. Mostly just some more are in tools.

The game has more than that tho due to some models were imported but don’t worry about it, those scripts will be removed.

I actually found like 120 Scripts…Which will definitely be removed.


Well yes it’s a big game but I have plans on making the Player Teleport within the game from a large place to another place which should help with performance.

It’s as big as Robloxian High School I think
how do they not have problems(or less) for Mobile?

One thing that I can think of to increase Mobile performance is to have a Settings that players can turn On/Off which will delete some Details.


I can add you to the Whitelist if you want but I can’t do that now, just let me know. :+1: