I've been having problems with part lag, does anyone know how to counter this?
In my game, a 32 by 32 by a maximum of 10 blocks deep group of blocks are generated. The problem is, ROBLOX already starts getting laggy when the game reaches over 10000 parts, and with the current computer I have, a 32 by 32 landscape is pretty much the maximum size with a bearable degree of lag. I have already planned to make the terrain much bigger than this, scaling in at about 1000 x 1000 x 500 blocks in dimensions, or if you do the math, an approximate amount of 500 million blocks. Now does anyone know if it will it even be possible to generate so many parts? I have thought of multiple solutions to this, but as I do not want to do the work of testing them out, I am not completely sure if they would be viable or not. Keep in mind that in the code I made for the generation, the terrain starts generating as soon as the game loads, and that there are no countermeasures for the part lag created in the process. If you would like to take a look at the game for yourself, here is the link: https://www.roblox.com/games/521575040/3D-Terraria-Pre-Alpha
Here are my untested solutions so far:
Remove the pre-loaded generation and make a map of the positions of every block in the game. Locally insert the blocks into the game as the player walks close to the relative mapped position of the hypothetical block.
Keep the generation the same way it is and simply make some kind of chunk loading system that would divide and save the terrain into multiple segments. Just in case your one of those people who's answer would be "enable streaming u nob," I have already tried this and it is simply of no help to me, as it actually makes the situation worse.
If you have any other solutions to this part lag, please tell me what this solution would be, and if I am just unaware of something that makes me look like a bad developer, just correct my mistake and be on your way. Anyways, thanks for your time, and sorry for the long read. Any help would be of great appreciation on my side.
0
0
0
0
1 answer
StreamingEnabled should help for client-side lag (it is half of what you are describing in option 1), though that doesn't do anything for server-side lag. Roblox servers are fairly powerful, but you can only ask them to do so much before they start lagging. You'll need a way limit how much the server has to keep track of. If you're going for an infinite (or near infinite) terrain, there are only a few things I can think of that might work:
A non-Roblox game could store needed terrain information to disk when no player is near it. Roblox doesn't offer this functionality exactly, but you use either Datastores or HTTPService (requiring the renting/purchasing of your own servers) instead.
Use of math.randomseed can let you randomly generate a section of terrain the same way over and over again. Use this to "load" a chunk's default state. Keep track of any modifications players have made to the terrain and apply these changes onto the chunk after loading. Note that if players are likely to make a lot of changes to the majority of each chunk, this won't be worth it. Naturally you can combine this idea with #1.
You can increase the amount the server can deal with by using memory efficiently. I found the following results:
- Unanchored Part in workspace: ~9.9KB each
- Anchored part in workspace: ~2.7KB each
- Part with no parent: ~1.3KB each
- Integer in 2D lua table: ~0.016 KB each
With that in mind, if you can store each terrain block in memory as an integer (terrain type), you'll be able to store tons more in the server's memory than by using parts (a million integers takes up only 16MB -- not quite the 500 million you wanted, but still large)
Depending on how Roblox's Streaming service works, it may not know how to transmit duplicate parts efficiently. If this is the case, then it would be faster for your server to use a RemoteEvent to send the 3D table of terrain integers. The client would have a sample of each terrain type (and any other objects) so that it could locally recreate the terrain. (Meanwhile, the server itself would have few if any parts in the workspace, besides the players). You may want to experiment with both methods (using Streaming vs doing it yourself) and see which one performs better.
If terrain generation takes a long time, you may only want to do it when players get close to an area, and possibly spread it out over time (by using 'wait's so that the server can attend to other matters periodically -- otherwise the whole server will freeze for potentially a few seconds, or however long it takes to generate the relevant terrain).
In your game you mentioned to me you use Parts for your terrain. I believe that using Terrain would speed up both the server and client, even if you only use it for some blocks. (You may want to experiment to confirm whether this really is the case, of course). Roblox can display a lot more Terrain blocks than Parts, and I'd be surprised if Parts weren't slower than Terrain in terms of impact on server performance in general (even if the Parts are anchored) and certainly on memory usage. (I haven't tested out how much memory is used by the Terrain, but you could do this yourself -- I was just using the Performance window in Roblox Studio and generating 10,000 -> 1 million entitites, depending on memory usage).
I recall seeing in mining games where the lower bricks aren't created until they are needed. If you generate something 100 bricks high, 99 of those bricks are wasted while the player is on the surface (and they are all wasted if the player never digs down). Generate them only as needed.