I’m working on a small round based game where players handle dice with their mouse. I’m currently using Body Positioners and Gyros to smooth and soften out movement, but I’ve hit a design decision I’m unsure about regarding client-server handling:
Option 1: Create the dice on the server, give the client ownership, and let the client move them freely while the server rapidly runs sanity checks. Option 2: Both server and client create their own dice, with the client sending CFrame updates every frame, and the server running sanity checks to validate movement.
I’m wondering which approach is best for smooth, responsive dice movement while keeping cheating or desync issues in check…or if there’s a better alternative I haven’t considered.
I’ve faced many hurdles with client-server interactions before, and this seems like it might bring up the same challenges again.
Any advice or examples from experience would be super helpful.
I’m aware that’s how player characters are handled as well. Both would work though, and would be responsive on the client, the server would only deal with the delay.
Hello! Option 1 is actually not the best choice and rather option 2 is the better choice since the client would not have to deal with server lag and you could interpolate any difference in the two positional results and and also handle checks completely on server while transmitting the results to client, if you want further elaboration I can give it!
Talking in terms of verification that the client and server both got the same results, you would just need to fire a simple RemoteFunction to clarify the results of the server were the same as the clients.
If you are referring to the physical aspect of the dice, I will first need to know exactly how the dice works and who will see it? Does the dice need to have the same exact position? Elaborate more please!
The game determines the results of all dice based on physics (varying on which side of the dice is actually facing up). The player uses their mouse to freely sway the dice around, and then release allowing them to roll. However, for responsiveness, this is solely done on the client. Does that inform you more of what I’m currently doing?
Yes this helps! You would not need to do validation checks on every position but you would certainly need to make sure that the final result is validation and is the same on both the server and client side, there’s no reason to check to see if the position or even the side is facing the same thing, only if the final result is the same. Let me know if you need anything else!
I’m not sure I understand.. Are you suggesting I do the roll on the server and client and then ensuring their results are the same? I’m not sure this would work very well with a system which revolves around the engine’s physics…
Correct..
I could just make it so they both do a roll and then the server decides the results, but then it wouldn’t necessarily match what’s actually facing up. It’d be a cheap solution and leaves a huge gap in the immersion.
I think to most optimally help you you should start out with the dice system now then when we get to the point of client/server replication I can help you with the replication of the results since it’s harder to explain without code and only discuss theory.
Well that’s why I made this post. Is because I’m not sure what I should do from this point moving forward, or if I should be taking a different approach altogether.
He is asking what is the best way to do it so that the client doesn’t experience delay from his perspective when he starts the action, of course there will always be delay but what he is trying to do is prevent it from being noticeable to the person who is initiating the action.
Network ownership poses a exploitation risk, giving the client network ownership of the dice allows them to manipulate it (Until server-sided authority comes out, but it will likely have the same timeline as FilteredEnabled when it came out so it’s still not safe to rely on SS authority just yet.