To improve performance for some devices, I’m looking to have a standard, detailed map, then for mobile, a much less detailed map to reduce the strain on the generally weaker device type.
To do this, I’m planning to have both maps located in ReplicatedStorage, then parent the appropriate map to workspace accordingly.
I’ve out together a place of roughly what I mean here:
In StarterPlayer:
local rs = game:GetService("ReplicatedStorage")
local map1 = rs.Map1
local map2 = rs.Map2
while true do
map1.Parent = rs
map2.Parent = workspace
wait(15)
map1.Parent = workspace
map2.Parent = rs
wait(15)
end
Obviously I would teleport and load the character correctly, this is just a rough setup to test the system.
This is a technique used by several games already, but in order to fully understand how this impacts performance, it’s important that there are roughly speaking 3 factors that determine the performance of a device running your game:
How much is currently being displayed in the Workspace (i.e. your active map)
How much data is stored in other locations such as ReplicatedStorage
How much data is being communicated over the network
Your technique ensures that only the appropriate detail level of the map is visible in the workspace, and thus decreases rendering resources on lower-end devices. That’s great! But, depending on the size of your map, you are now storing two (potentially really big!) versions of your map in ReplicatedStorage. This means that a mobile device loading into your game, does also load the fully-detailed version of your map into storage. This doesn’t directly impact FPS or Physics, but does increase the chance of devices quitting the game because they run out of memory.
Something you could do, is to have the low-detail version in the Workspace from the start, and make an overlay model that includes the more high-detail assets you want to load if the client is on a PC or Xbox. You could then store this model in the ReplicatedStorage, which would be an improvement. Or, you can break up all the models in your map and store them individually, and then spawn them in on predefined locations to prevent storing 100+ tree models in ReplicatedStorage memory. We used that ‘instancing’ method for VentureLand and it greatly helped reduce resources, plus it allowed us to write a system that spawns models close to the player, and removes them once they are far away. That allowed us to get much more detail into the world without using too much resources.
If you want to go even more advanced, you want to lower the resources for the first two factors, and utilize the third (Network communication) to stream models to your client. I would advise against using StreamingEnabled unless you are 100% sure you know what you are doing, but generally speaking it is a good idea to not have copies of the map stored in client memory that the player isn’t likely to see any time soon. If you have an outdoor world that leads to various indoor locations, you could store those indoor locations on the server and only send them to the client when the client is about to enter the location. There is unfortunately not a built-in way to do this, but you can parent models to Player.PlayerGui to replicate something exclusively to one player. If you would like Roblox to build in better support for this type of streaming, you should head over to Custom replication via Zones/Scenes and give it some support.
Lastly be aware that, when the client loads the map locally, the server doesn’t see the geometry and might as well think that your players are now floating in mid-air. This is something to keep in mind when designing your game and programming it.
I hadn’t considered this before -I’ll definitely look into doing this now.
I’ll consider applying this technique. I think for now it may be difficult as I’d have to make a trade off between the time-taken to enter a building and overall lag, but it’s something to look into.
Very helpful reply.
For the armour and weapons in my game (there will be a LOT of them), I store them all in ServerStorage and send the correct one over to the client only when a player has it equipped.