Using Animator Instances on the Server Is a Bad Idea

Help and Feedback Scripting Support
1

Hi everyone,

Why Server-Side Animators Are a Bad Idea

I’ve been doing quite a bit of research on this topic, and I feel like it’s not being addressed clearly enough.

A lot of people say that animations should always be played on the client to avoid unnecessary load on the server, which makes sense. However, very few actually explain what that means in practice.

From my understanding, to properly do this, you need to instantiate the Animator objects on the client, not the server. Otherwise, animations may also play on the server, which is just a waste of resources.

While testing with a few players in a local server setup, I noticed that if the Animator replicates from the server, animations get played on the server too. That seems inefficient…

My Setup and Workflow

So in terms of workflow, here’s what I’ve set up:

I have a module called ServerNetworkController on the server side, which tells each client whether they should play an animation, and on which instance (either an NPC or a player).

By default, I destroy any Animator instances that are created on the server.

On the client side, I use a module called AnimationService that handles playing the animation using the parameters provided by the ServerNetworkController. If the target Humanoid doesn’t already have an Animator instance, the module creates one.

Just to clarify, this Animator is created locally on the client. Any animation track played from this local Animator won’t be replicated by the server, which means it will never be played on the server.

I’d love to hear your thoughts or experiences with this. Am I missing something?

Thanks!

1 Like
2

Usually, roblox replication is typically the problem, the reason why roblox animator replicates is because you’d want your animations to replicate to the server. If it didn’t replicate it, no one would see any ones animation.

This is false, this is not a waste of resource, it would only be a waste of resource if you’d play the animation in the server and not the client.

Why?

  • Because It would not be smooth in the players screen
  • The server would then need to handle the animations, making it more laggier

However, that is why you play it on Animator on CLIENT.

The main problem:

This is because the animator is being created on the client. Anything that is being created on the client, Wont be seen on the server. This is why its not working.

3

I feel like this topic would be more appropriate as Development Discussion

1 Like
4

Here’s a quick clarification, because I think we might be talking past each other:

I completely agree animations should be played on the client, not the server. That’s exactly what I’m doing.

The point I’m trying to make is more specific:
From my observations, if you create the Animator on the server, even if you play the animation on the client, it will still play on the server too.
This means the server ends up doing unnecessary animation work, which is a waste of resources.
For example, if you have 30 players and their animations are replicated and also played on the server, the server is running all 30 animations in parallel. That’s completely pointless and adds avoidable CPU load.

To avoid that, I make sure the Animator is instantiated only on the client. That way, only the client plays the animation, and the server does nothing.

However, this also means that whenever a player changes their animation, the server won’t automatically replicate it to other clients. So we have to handle replication manually: the client notifies the server, and the server then relays that information to the other clients, who each play the animation locally on their side.

It’s a bit more work, but it gives us full control over when and how animations are played, and avoids any unnecessary processing on the server.

My theory is that animations are still played on the server to help with replication when StreamingEnabled is on.
It would make sense, since new clients might stream in mid-animation and need a consistent state from the server.

1 Like
5

If I were completely sure about this, I would’ve posted it in Development Discussion.
But since I’m looking for help and feedback, I think this is the right place to ask.

6

If thats what you are asking yes you should be doing this. Atleast that’s what i have seen in multiple roblox starter places. Generally you want all sounds, visuals, animations, non important frame by frame updating parts to be handled on the client. While data should be handled on the server. Ultimately yea I agree that the client should handle the animations.

And the best way to handle this I believe is to create an attribute on the server that is stored somewhere. Then to access this attribute you let the client who wants to play an animation fire a remote to communicate with it-specifying which animation to play. Then on all clients you want to listen for that specific attribute and play the appropriate animation.

Basically the way you described it

1 Like
7

Thanks!

I’m glad to hear that looks like I’m heading in the right direction.

Using attributes as a sync point is an interesting idea. In my case I went with a RemoteEvent-based setup where the server just tells each client when and what to play, but yeah, it’s basically what you described.

What I really wanted to highlight with this post is the fact that creating the Animator on the server can unintentionally cause animations to run there too, even if they’re only triggered by the client. That small detail seems to be overlooked a lot.

That said, I feel like implementing proper custom replication requires a solid architecture.
Just consider the StreamingEnabled issue I mentioned earlier:
If an NPC is playing an animation outside of a player’s streaming radius, and the player streams that NPC in mid-animation, the server needs to tell the client exactly where in the animation timeline to start playing it.

So you need some sort of caching system to keep track of the animation state.
At least, that’s how I see it…

Thanks again for the thoughtful reply!

8

Just dont reinvent the wheel.
Everything works as intended.

3 Likes
9

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.