So, i have a game which consists of lots of parts, models, meshes falling down a ramp where the player has to get to the top. If anyone is interested : Ramp Of Hell (Game)
Ive got a few problems where sometimes either parts start moving extremely slowly along the ramp and start accumulating, other times, some parts just like freeze and will only start moving again once a player gets close enough.
I was wondering if there was a way to optimize my game? Wether its better to drop parts or meshes? Or even if there was some other way of making the parts flow swiftly.
Btw, this only happens sometimes, and im not sure if its due to larger models spawning or wether there are too many people in the server. Thanks for any help!
A possible unoptimized solution to this would be to change the bounding box to “Box” to simplify the collisions and then set the NetworkOwnership to nil (the server as default) because what ROBLOX does to offload some of the work is calculate the physics of each part through the client and send the information back to the server, possibly the reason why parts freeze and resume when you get near them (This can also happen just due to physics simulation distance as well). However this approach wouldn’t be good for the server as it would be taking on a massive load depending on how many parts there are. A more valid solution would be if this is done with a collection service I would experimenting with looping through each player to get the distance of the player to the part and set the network ownership to the nearest player to the part, that way you can unload the physics calculations off of the server and send it manually to the nearest client, if done correctly the closest player to the part would be experiencing a more accurate physics calculation and they wouldn’t be hit by ROBLOX’s infamous ghost parts (which just comes down to network replication as this is an issue with poorly made NPCs as well)
Hey thanks for the reply! I already have a debris system where parts despawn after about 40s which is the average time taken for parts to reach the bottom of the ramp. Sadly parts spawn at a greater rate than they despawn and when they slow down it just gets worse and worse.
Thanks for the reply. Yeah the network onership looks like a viable option though wouldn’t it add a lot of load to lower end devices? ill try it though and ill tell you how it ends up. Thanks
It could add more load to lower end devices but the alternative would be a server struggling to properly replicate the positioning of the parts and people would get hit by the ghost parts I had mentioned earlier, with this method it would sacrifice the few to save the many.
Hey. Thanks for the response. I was reading the docuumentation and i decided to set it to “Adaptive”. Right now i dont really notice any difference in terms of physics acting different. Do you know how setting my game to “Adaptive” would change the physics of the falling parts and what are the advantages/drawbacks? Performance wise it seems to work well for now. Thanks
Setting the NetworkOwnership to nil will not help your problem. This will only put more load on the server. The reason why parts move when you get closer is because you gain network ownership over the part, hence your computer does the calculations.
You should really start thinking about simulating these falling objects on the client instead of the server. That will actually help with the lag.
That could also work, it’s essentially changing the update rate of the physics calculations on the parts. You wouldn’t see as much of an improvement I think, you might see some stutters a bit still, but if you really need your parts on the server, here’s what to keep in mind:
Here’s some insight on Exploiters.
As a normal behaviour, Roblox sets the NetworkOwner of the physics parts to the server, but the behaviour is adaptive, meaning if you get closer to a part, you gain network ownership, and if someone else gets closer, they also get network ownership.
This system seems amazing at first sight, since it can lower the load of the server by simulating these parts on the client, however, since the physics are simulated on the client, this means exploiters can make these parts move in all directions at free will. And can make people fling, die etc.
Therefore, you’d have to set all parts to NetworkOwner to nil at the end of the day to prevent this from happening on the server. So you would have to combine both their answers to get a protected and faster result. An issue you wouldn’t have if you created the parts on the client in the first place.
Try their method first, if you do not see any improvement then move to the client.
Good point. I really appreciate the help man. So for now ill try the Adaptive physics system and see how that works out. If its still not working i’ll make the parts be on the client-side. And well ofcourse i will still have to optimize the models and meshes i spawn down the ramp. Thanks for your time!
Creating objects on the client won’t cause more lag than creating them on the server. The impact on client-side performance remains the same, however, it avoids using server resources and completely remove lags caused by network ping, so this could fix these issues:
Yes, the client can handle more physics parts, as mentioned. I said that in case there’s just too many parts. But there’s little chance this lag is created for network reasons, its most likely a high amount of calculations needed.
You coulf also use :FireAllClients() to render physics on the client while still being semi-synced:
Server: Sends partData → RemoteEvent:FireAllclients(partData) → Client: Creates part using the partData
