So here’s the idea: I have a voxel-based terrain generation where multiple players can go out and explore in a procedurally generated terrain. Players can edit the terrain and it should replicate to all clients. I can either have the server do all the instancing with the blocks, or I can have all of the clients do it locally. My question is, which method would be most feasible in terms of performance, efficiency, and security?
Server-side: Players send requests to the server to load in new parts of the terrain, and the server generates and physically builds it. Requests to edit the terrain are sent with remotes and the server handles all that too.
One major downside would be the performance, since it’s gonna have to create a lot of parts, even with optimizations such as greedy-meshing, which can severely lag or freeze the server.
Client-side: The terrain is stored on the server using numbers and coordinates instead of physical instances. When the player requests to load in a region, the terrain is generated and stored in a similar fashion, then the server sends the information about that newly generated area to each player with the same format. Then the clients use that information to construct the terrain separately. Requests to edit the terrain are handled by the server, which then sends the updated terrain to each client and have them rebuild it.
A potential downside would be the latency players would experience from receiving the large packets of information. Another problem could be synchronization, where players’ worlds are different from each other due to lag which can cause problems with interactions.
1 Like
I believe the server-side approach would be safer to use for synchronization and security. The efficiency of it ultimately depends on the amount of terrain and the number of players in one game. Obviously, the more terrain and the more players in one game will impact the performance of the system.
The client-side approach could potentially be more optimized and efficient depending on how exactly you implement the code. The client-side approach could be less performance-heavy on the client compared to the server, but depending on how many times the terrain has to be rebuilt by the client it could be just as noticeable on performance. Keep in mind that roblox servers are dedicated to running the game; whereas clients have other tasks running at the same time and are less likely able to handle larger tasks as smoothly as the server depending on what machine they are using. As you mentioned in your post, there is also a higher chance that you will run into problems with synchronization through the client-side approach.
How frequently you update the terrain will have an effect on the performance of the system regardless of whether you take the server-side approach or the client-side approach. Overall, I believe that you will run into fewer problems through your server-side approach compared to the client-side approach. Optimization is something that you will have to address regardless of the approach you take. I don’t think that either approach is a bad idea, but I personally think it will be better in terms of efficiency and security to implement the server-side approach.
This is just my opinion based on my past personal experience with server-side and client-side systems.
I usually don’t recommend doing client-side systems unless you want a unique outcome for each client, or if it doesn’t require too much processing. However, it really depends on what system you want to create, and your server-side approach seems to be the best approach to me in this case. I hope this helps!
Always server-side. Remember to never operate anything under the client unless deemed completely necessary to avoid exploiters.
Generating terrain on the server would replicate said generated terrain to every player’s device, no matter where they are in the world (and obviously with more than a few players, performance is going to get bad very quickly). I would have the server keep track of which blocks have been changed (if a block has never been changed, you can just use the coordinates and the seed to know what type of block it is), as well as keep track of any free-floating entities. You’d definitely want to use chunks to hold data including changed blocks, and any entities in the chunk. When a player loads a chunk, they’ll also load any entities in it locally (you’ll need to implement anti-cheat for this, and it also gets a bit more complicated when multiple players have loaded the same chunk), as well as build all the natural and changed blocks.
What I’ve said mostly applies to making something similar to a certain popular voxel game, but obviously if you’re making some little 2-player island game or something like that, things are going to be a bit different from this.
1 Like