Hello, I am currently working on a sandbox focused game similar to Minecraft, where you can create worlds and play them with your friends. Like Minecraft, there is a unique seed that is used to generate chunks. Although the script for that has already been made, I am a bit confused on how I can smoothly load them, avoiding sudden pop-ins and pop-outs.
To give you some context on how the chunk building works, the server checks every 0.5 seconds if the chunk location of a player has changed, and if it has, it gets the surrounding chunks in a radius of 2, and then attempts to load them and store each block in a table. After that’s done, it sends that table over to the client via a RemoteEvent, and then the blocks are loaded based on the information received. Also, if it finds chunks that are out of reach, it will again send a message to the client to unload them.
Chunks are stored in X,Z. For example “1,3”
Now, I need some advice on how I could improve this kind of system, reducing lag on the client and loading only the necessary chunks while still keeping the game playable. As mentioned above, I would also like to know how to avoid chunks suddenly popping in and
popping out which is not really pleasant for players to see.
Unfortunately, since I am writing this on my phone, it’s not easy to send code. My main computer is currently broken, and I am using my laptop which is very slow. If the code really needs to be sent though, I will try logging in from that.
If your terrain is blocky, you can use greedy meshing to reduce the number of parts in each chunk, also you can only render the “visible” blocks that are exposed to air and hide the blocks that are covered by other blocks; and to boost it even more use Parallel Luau to compute the calculations in parallel and execute the chunks in serial (ex: assign 4 chunks to 1 actor; for instance, 60 total chunks divided by 4 is 15; thus having 15 actors each handle 4 chunks)
Greedy meshing, from what I understood, is taking multiple adjacent blocks and “grouping” or connecting them together. In my case, since users will be able to break and place blocks, greedy meshing might not work.
As for hiding invisible ( to the user ) blocks, I will try figuring it out. I am not sure how I would handle things like mountains which have stacked blocks.
Now, parallel luau, I had a bit of trouble understanding it, but I think I know how it can work with actors. Were you mentioning putting this kind of “tech” in the server’s calculations or in the client’s block loading?
and how would I split these actors? One way I can think of is storing which ones are unavailable or used, and if none are then it creates a new one.
I am very sorry for all these questions, I just couldn’t understand it well enough.
yeah its quite hard, i tried to do it but i lack the brainpower; but i remembered that theres an opensource minecraft clone thats actually quite performant with a lot of cullings
it could be both but I’d go parallelize the heavy calculations in the server only cause thats the only purpose of parallelization as far as i know
as I have said, one way is that you can assign (x) chunks to be handled by 1 actor, for example:
1 actor will handle 4 chunks; and the master will send messages to the actors to do their assigned chunks. in this case we have 12 chunks, and 12/4 = exactly 3 actors
note: this is my way of doing chunk generation parallelization (or any kind of parallelization really) and there might be flaws in my approach
Thanks for your reply. I managed to get culling to work with my current system, now I’m fixing some strange bugs. I’ll work on it and will post the results here.
