I’m making a game where the user cooks recipes and competes against time. The user can press SpaceBar to grab/place on the table that is nearest to them. Currently, I’m firing the remoteEvent to the server and moving things around on the server, but this causes Replication delay which makes the game appear laggy.
@EchoReaper suggested that I make the action on the client and ping the server instead. Now, for me, this seems a bit difficult as the conditions for cooking is a long script.
My question is since the Server has to check to ensure what the client did is valid, would I have to have the long script of conditions on both the server and the client now? (it seems difficult to edit in the future as I’d now have to edit both scripts?)
It depends on how you implement your sanity checks on the server. For each recipe, I would probably store the “instructions” on the server, then after each step on the client is completed, verify with the server that the action was done in a reasonable time/whatever criteria is used to detect exploiters.
Unfortunately, I don’t see how you can avoid having to edit at least two scripts, as splitting the tasks up for the client/server implicitly calls for >1 script.
If it’s multiplayer, have the sever handle sanity checking and have clients move objects around per the server’s firing. As far as the worker client is concerned, you don’t need to make any checks with the sever, just have the server hand the client a copy of the ingredients. Then, just have the client run checks the same way the server does via validation ModuleScript. If the client does something invalid, don’t bother letting it know. As long as you program the client correctly, only exploiters will encounter sync inconsistencies.
No, the idea is that if you write your code in an elegant clean enough way, you will be able to put the shared logic in a ModuleScript in ReplicatedStorage, which both the Client and the Server will be able to call on to check / track things. Though there will usually inevitably be some small amount of code replication at the edges of the API you develop when you’re hooking everything together.
You’re absolutely correct that doing so is quite a bit more difficult than just having the server do everything, since you have to keep the two in sync somehow (either by explicitly including synchronization communication between them, or by having the process be entirely deterministic, so that if you start both with the same initial conditions at the same time they should match up exactly even if the client and server don’t communicate further). That’s just the price that you pay for dealing with real-world latency in a non-exploitable way.
