For example, when you enter “The Neighborhood”, your screen dips to black and you’re teleported to a completely new area.
Is this for performance? Are they offloading structures and areas where the current player is not near? Is this achieved by replicating the current area when the player wishes to enter it?
I’m looking to do something similar, but don’t know the approach that would be less intensive for the client. Any ideas would be appreciated!
One way that I did this before, was when you go somewhere new, i.e., inside a house, the game would unload stuff you wouldn’t see outside and would load in the inside of the house. All of this would be done with Client sided scripts so that the other players outside would still see everything that’s out there, but wouldn’t see the items inside the house like you do.
This works because of the Filtering Enabled property that goes and stops replication from Client to Server so you can load whatever you would like on the Client, and the server wouldn’t see it change.
Does this approach not cause a massive lag spike when replicating to and from the client?
I wouldn’t want to suddenly have massive lag spike and crash mobile devices.
What I did was I had the exterior of the house in the world where everyone could see it, and then when you walked up to the door and pressed “E” to teleport in. The screen would fade out, and move a cloned model of the interior from ReplicatedStorage into the house.
I didn’t test this on mobile, but we didn’t have any memory leaks or problems while testing it on PC. We tested it on an old laptop as well and it worked fine.
TL;DR; Haven’t tested on phone, but it should work fine without crashing the mobile game.
Okay, I will try this approach. Thanks!
I hope it works out for you!
I believe this method is also used to have larger insides/separate insides from the house model
because making a accurate house inside and out at the same time is a lot harder than just having the inside and outside separate
@MrLonely1221’s approach is not the most beneficial possible, as it saves no client memory. As long as the loaded area iisn’t in render view normally, there’s no real performance gain from doing what he does. His approach does have a computation penalty, so this approach may be a negative with no benefits if these parts are not normally able to be in render view.
For a loading system like this, you want to store this sever-side, not client-side at all. Put the instance inside Player.PlayerGui when you want the player to see it, so that it is replicated only to the client you want to. The client proceeds to clone the instance from Player.PlayerGui and parent it into game.Workspace, then you can teleport the player to that area. The sever can now destroy the replicated instances in Player.PlayerGui.
It’s important to note that according to @evaera, instances parented like this in particular do not guarantee that they will be fully replicated before the root instance of what was cloned exists on the client. The ramifications of this are that you need to wait for the number of descendants of the cloned instance to be equal to what the sever passes the client. Alternatively, it may be possible just to pass the instance root through a RemoteEvent to the client, but it is unclear whether or not there is a guarantee that the instance cannot look like it’s nil when the client is handling it. A Roblox engineer may have to confirm this, though @lpghatguy says he thinks that the RemoteEvent handler can’t be called until the instance is done replicating.
The downside to this approach is mostly that you are constrained by the player’s Internet. Normally the bandwith used for these replications would be done when the player joins the game first and never again. With this setup, you can be replicating the same data multiple times in the same session. Additionally, the time to download the data may negatively impact user experience due to the latent time the player must wait for the download to complete.
What do you mean storing it on the server-side? Where is the map being stored before the client wants to render it?
Also, you mention that it should be placed in Player.PlayerGui and then parented to game.Workspace. Why does it have to be parented into PlayerGui first?
I mean storing these parts of the map in a non-replicated container like game.ServerStorage. You need to parent it to Player.PlayerGui so you can replicate the data to the client you want to individually, without wasting everyone’s bandwith and computation. Then, the client clones what it received in Player.PlayerGui and can parent it to game.Workspace or wherever. The point is that now the server is free to destroy what it parented to Player.PlayerGui so server memory isn’t wasted, and the client can keep what it received.
Yes, it has to go to Player.PlayerGui first.
Okay. Thank you for the clarification!