I’m trying to optimize a game I’m working on. Some people have reported a recent problem of it crashing as it loads on lower-end devices like iPad Airs and such. I want to only make some of the game load in at first, and make a screen when they join that would give them the option of a “Low-end mode” or a “Normal mode,” where the low end mode wouldn’t load in the rest, and normal mode would.
I’ve seen the solution of keeping bits of the game modeled in ServerStorage, and only loading them into Workspace when need be, but in my scenario, doing this would complicate the building process of the game a lot, especially since updates are made regularly.
Is there anything that I can script or do that would be a better way of keeping all of the game from loading at once?
You can check out the Streaming Enabled property which basically does that. Although it can only be pre-set in studio, you can’t re-set it when a game is running. And honestly just keep it on even if a user is on PC, it’s always better performance.
A chunk loader is the best way I know to do this. What exactly do you mean by complicating the building process? You can make a chunk loader by placing parts of your map into folders, then having those folders load in and out based on distance.
If you’re still 100% against this, then unfortunately ROBLOX has no built-in render distance setting aside from the in-menu graphics settings, and this has been suggested multiple times before, but I think they’re too scared to touch those settings for some reason because it’s been years and we still haven’t gotten anything of the such.
In terms of complicating the building process, in the case of putting some of it into ServerStorage, this would leave the map in Studio to look very empty, as though it’s always on “low-end mode,” making it harder to picture the correct aesthetic for the world, on top of needing to re-insert new things we add that could be cut in low-end mode into ServerStorage. Though, maybe I’m going about it wrong. I wouldn’t say I’m 100% against it, as it certainly isn’t the end of the world, I just wanted to see if there was anything better I could try.
Gotcha. If there is a better solution, I’m not aware of one. You could try StreamingEnabled as @starmaq mentioned, but I think that’s more for updating parts within a fluctuating radius instead of loading them in.
Your problem of loading in chunks could actually be fixed without having to remove parts of your map manually in each update, but depending on the physics of your game, this method could be buggy. Still, it might be somewhat worth mentioning if you really want to attempt it, only as a last resort maybe.
So this “last resort” would be to parent the entire map to ReplicatedStorage as soon as the game starts, then have the client load in the chunks individually. This would result in the server loading in no chunks and not even having a map, while all the individual clients would have the chunks around them loaded. I’m almost 100% sure this would lead to physics bugs and also cause problems with server scripts which would need to be fixed (probably with remote events/functions), so if you have any important physics-related mechanics in your game, this probably isn’t a best idea.
I’m unaware of any alternatives, so unless I’m under-informed of ROBLOX’s mechanics for things like this, the best option might would just be for mobile players to lower their graphics before joining the game.
On a related note, are you sure the size of the map is what’s causing these players to crash? It’s a fair assumption to make, but in reality it could be something else.
So, having a script that immediately puts the map into ReplicatedStorage as soon as the script loads? I could try that, especially since the game isn’t reliant much at all on physics. I’ll also play around with StreamingEnabled a bit.
I’m honestly not 100% sure the size of the map is what’s causing players to crash, but I’m not able to play around and test things myself, as I don’t have any low enough end devices to test it on.
I tried your method of putting the map into ReplicatedStorage. It worked, technically, but you were right about scripts having trouble communicating like usual; a lot of scripts broke, and I had no idea I had so many server scripts that relied on the map being in workspace!
So I tried StreamingEnabled, and that was when things got interesting.
I played around with it A LOT, mostly because I wasn’t sure what exactly it did or didn’t do. After writing many local and server scripts about fetching things that are/aren’t loaded, I was pretty sure Streaming Enabled doesn’t load things into the client’s workspace until you get close enough to them…except for models.
Oddly enough, StreamingEnabled keeps all models in the workspace intact–they’re just empty. It doesn’t load any of the bricks INSIDE of the model until you get within range. This was crazy to me, but it answered a bunch of questions I had while writing the scripts. And BECAUSE of this, I’m now able to group everything to be cut in “low-power mode” into models, and have the models be deleted locally. Because, when StreamingEnabled tries to load the bricks into those models, since the model is deleted, they don’t parent into anything. Not even Workspace. And since the map is too far away from spawn to be loaded at first, by the time a player in “low-power mode” gets to the map, all of the low-power-cut models will be deleted.
That’s my understanding of what’s happening, anyway. Pretty nifty!