You’re forgetting one intricate detail, this is for chunk generation and chunks should change gradually not eratically, under the assumption that similar numbers correspond to similar chunks not bit32.btest would be a feasible solution.
I think you still don’t realize how bad and inconvenient the idea with local number generation is…
I would love to hear your approach regarding this issue.
1 Like
My approach is obvious.
Generate the numbers on the server and send them to all the clients.
Why are you refusing to make it this way?
Because the map is infinite. We would have to use remote events to exhaust the RemoteEvents queue.
I don’t see any real issues with a client-sided approach anyways.
I don’t see any problem with an infinite map either.
In a server script you loop every X seconds through all the players and check for players who are close enough to the end of the map to generate new terrain.
If you find such player - you generate all the data on the server and then send this data to this specific player. You save the data on the server in a table. Then, a local script handles the map generation.
If any other player is close enough to the zone which was previously generated for other player, you send the saved data to this new player not to repeat the generation.
Alternatively, you could automatically generate the terrain for all the players when any of them is close enough to the end, and customize content streaming so the game stays optimized.
https://developer.roblox.com/en-us/articles/content-streaming
1 Like
We tried this, however, at higher player amounts the Server Latency got very high and eventually the entire server crashed.
Our current solution is working with no flaws.
Both my solution and yours handle the terrain generation locally so there has to be something else you’ve missed that caused these issues. Our solutions are the same in this regard.
Also, your current solution is vulnerable to exploits.
It is going to become more and more problematic as your game grows.
Let’s say you’re adding loot boxes and each new piece of generated terrain has 0.01% chance to contain super unique item.
What an exploiter can do is simply mess with local terrain generation script and modify it so there’s 100% for this item to spawn in.
And that’s only an example of a low-harm concern.
The more complex mechanics you apply, the more open doors you leave for the exploiters and since you handle the generation locally, it’s going to be impossible to patch most of the vulnerabilities.
While handling the terrain generation on the server, you can easily implement sanity checks to prevent what I mentioned above entirely.
The game is purely about exploration. It is a Backrooms game, to be precise. The only thing someone could archive with manipulating the generation is being able to walk through walls.