The golden rule of animating an object by updating its CFrame is to never do it on the server, because network replication is at 20Hz while client rendering is ideally 60Hz, so the movement will appear choppy.
However, I am unsure if this behavior also applies to Roblox animations (i.e. made using the animation editor) played on the server. Is the interpolation handled on the server itself, or does each client render the replicated animation on its own machine? (i.e. the animation is not handled on the server, but instead on each client that the animation is replicated to). In other words: when you play an animation on the server, will it appear just as smooth to the client as if it was played client-side?
I believe this also applies to client-side animations played on the local character’s Humanoid which then replicate to the server.
Hope the question makes sense in terms of the network logic–not really sure what jargon to use here.
Yes, animations played on the server are sent to the clients to be played locally. I’m pretty sure they’re played on the server too, though. This applies to client-side animations assuming the Humanoid already has an Animator.
So the animation is just as smooth as if I was playing it on the client?
My personal use case is that I need to animate zombie NPCs. I would like to animate it on the server, because this will reduce extra work in trying to synchronise all the networking (and animations with attacks), but I need it to be ultra-crisp.
Sorry to be lazy–thought I’d ask before I decide how to design my system. Plus I like hearing your ideas.
Ah, you were referring to NPCs. I assumed you meant players, my mistake. In that case, I’m not sure if what I said above stays the same.
I’m not quite sure how roblox handles this when it comes to non-player characters, but I’d assume they’d do the same and have all players play the animation locally.
If you want to be safe, there’s not much harm in doing the animations on the client. You say you don’t want extra work in synchronising everything, but I don’t think that’s necessary. Animations may not be on the same keyframe across clients, but it shouldn’t really affect the players that much.
I stopped being lazy and tested this in-game with a super simple setup, and I couldn’t tell the difference between an animation played on the client, and the same one played on the server (for an NPC). Looks like the client plays everything locally, which is a good thing.
From that, I would assume there’s no extra overhead in playing animations on the server; it’s just pinging clients to play animations themselves.
However, my server is already very overloaded. I don’t want to catch it on fire by animating 300 NPCs, so it might be more efficient to animate locally (so I can control who actually needs to be animated from the player’s view).
Hang on–this replication logic is more big brain than I thought. Each client supposedly plays the animation on their own machine, but the animation is also clearly run on the server (because you can see it in the server view in Play Solo).
Yes, animations started in scripts are played by their network owner. Those started by local scripts are only updated locally. If the server plays an animation on a player, the animation is sent to the player and they play the animation. Part updates are then sent through regular physics updates to the server which sends it to all other clients. This is because the player is the network owner of BaseParts in their model.
I’m not sure where the 20Hz updates statistic comes from but I do know that setting the CFrame on the server is a bad idea for many reasons including latency and noise (late updates causing a frame to have no updates or early updates causing a frame to have too many updates).
