I’ve been getting stuck recently on what should be handled by the server vs the client.
Take something as simple as opening doors. As pretty much everyone knows that server tweens are no good. What I’ve been doing is sending the tween data through a remote, and creating the actual tween on the client. Everything else like sound and collision is on the server.
I recently ran into a situation where I would need to pause the tween, which obviously wouldn’t really be possible/synced across clients in this case.
Also, I made a module that clones sounds, plays them, and destroys them when finished. How would this even function on the server? Each client would probably load the sounds at a different speed, so would it just get cut off?
At that point, should it ALL be on the client? Where do other devs usually put a line between server and client in this type of thing?
Using a remote event to trigger tween animations on the client is the right way. You could have a second remote event for pausing and it would “stop” the tweening on the client.
You could use something like this on the client:
local tween = TweenService:Create()
Event.OnClientEvent:Connect(function(action)
if action == "start" then
tween:Play()
elseif action == "pause" then
tween:Pause()
end
end)
Effects belong on the client. Effects that must display like animations be handled with normal RemoteEvents and ephemeral effects like bullet tracers can be handled with UnreliableRemoteEvents.
if you do go with the second option, you could also store a value to go along with the state that would be the time the state was changed to the new state, which could be used to sync up the clients.
Like if one client is just realizing the state changed 2 seconds later, and the door tween is like 5 seconds, skip to the 3rd second of the animation (thats just an example)
I mean its all tradeoffs. At some point you are sacrificing something. Either state won’t be perfect or it won’t be smooth. You really just need to pick what tradeoffs you want and minimize the side effects.
In general have everything that doesn’t effect the game play loop heavily (such as animations, particles and sounds) on the client. And things that do effect the gameplay loop on the server (mostly just to stop cheating). Generally visual effects can be a bit buggy from time to time (like say the door moving back due to a pause command) without truly breaking the game. You just want to minimize that, which you can do often just by tweening back to where it should be when you mess up. Also if it’s vital to the game you should make sure it happens on the server. Like the door open/close, you may need an invisible wall that blocks it the moment it’s meant to be closed, but it’s probably fine to leave that purely to the client anyways since we are talking difference from animation speed alone. (A cheater could teleport to the other side anyways so a better anti chest system would be needed)
Why do you want it completely synced? A few milliseconds won’t cause anything bad. You can also check the collision on the server so if a player lags and somehow goes through a door you can push them back.
There is a common myth that you shouldn’t stress the server, but there isn’t one that tells you shouldn’t stress the client too!
The first and most important thing to consider when choosing where to handle VFX, is it’s interaction with player, for instance projectiles, animations, sounds or camera are usually fast and have effect for short amount of time, so it would be useless if player can’t see them, this is where client-sided effects shine, as they can be smooth and player can be more immersed
Another less important factor might be to not overcomplicate, if you have fancy OOP replication then there is no difference, but if you’re using other, less synced systems replicating inputs from client to server might be harder, and this is where VFX might also be played on server
On the other hand, the slower, less important VFX that might have impact on gameplay later that aren’t very smooth like building doors, small lamps, campfire or artillery, can be played on server, this way they wouldn’t cost that much of a network bandwidth and don’t stress the server, most of them usually are used occasionally and are used later, artillery might be loaded, but not used, doors might be opened, campfire lit and ect.
It’s up to you to decide which you choose, remember that each have pros and cons, also don’t send large strings over networks, they cost 1 byte per character