Replication questions

Replication, I have no idea how to handle replication in my game(sorta).

I understand the basic concept that something made on the client will never be shown on the server and everything on the server will be shown to all clients but I don’t know how or why that has to do performance.

I am creating a 3rd person shooter and I have just started making my own custom character and character controller. So, the big question is what do I replicate(in regards to movement)?

Do I keep all things on the server or do I have to manually replicate them to the client.

Currently I am just using a player local script which talks to a character script which moves the player. Do I need something more complex?

I am not using humanoids since they have very weird physics I just want to know what is the best solution for the best performance in my game?

3 Likes

When something is replicated, what you refer to as ‘showing’, the server has to use resources to send a network packet to the client(s) that contains information about the data that is being replicated, so that the client can display it on its locally running instance of Roblox.

Things can be replicated to everyone or a specific player, and clients can also send data (replicate) to the server, but the server would authenticate whether it will actually do what the client requested. The general rule is this: The server is always right and never trusts anything sent from the client. When you start to trust the client you are also trusting anything malicious and your game will be exploited.

In terms of performance, the server can only do one thing at a time. You do not want to be wasting the server’s time by replicating things uselessly or too much that you don’t need to. This will cause the server to appear to ‘lag’ for players in the server because the server will begin to replicate slower and slower to clients as it has too much work to do.

Want you usually want to do is offload some of this work to clients whenever possible. Work that is done on the server can contribute to everyone lagging, but work that is done on a client will only ever affect themselves.

A good rule of thumb is:

  • Try and do work on the client whenever possible

with an exception for

  • Data that needs to be validated, in which the server must do
  • Data that all players must know of can be done/stored on the server

An example of something that would only be done on the client and not ever sent to the server is advanced gun effects. Other players do not need to be aware of bullet casings ejecting or detailed sway animations for your gun. Some games even have low-detailed gun models for everyone except yourself. Visual effects for the most part can be done on the client (with low-detailed versions for others).

An example of something that would only be done on the server is player hit detection and damage. The client would tell the server it has shot their weapon, but its up to the server to validate whether or not that resulted in a legit hit (whether they can shoot that fast, shoot in that direction, or if they even have any ammo left, etc)

Movement is special and is actually generally done on the client, replicated to the server, and the server will 100% trust them. This is how Roblox handles player movement (which is why teleporting exploits work). This is the only way to do player movement that is not laggy. If the server was to validate player movement, you would have an input delay proportional to your ping and server lag. For example, if you had 2000 ping it would take you 2 seconds to start moving after pressing W. That’s no good.

To prevent movement exploits, the server will validate movement after it has happened. A simplified example of an exchange that could happen:
(client is at position (0, 1, 0) and teleports with an exploit)
Client: I am moving to position (1000, 1, 250)
Server: Okay! I will let everyone else know.
(a tiny bit of time later)
Server: Wait a second, you were just at position (0, 1, 0), it’s impossible for you to move there that fast!
(server teleports the player back to where they were before)

Hopefully this explanation and info helps!

3 Likes

Wow thanks for this. It does answer quite a bit. I was just wandering also about how animations should be handled? Do you know if the server handles them or do the clients since that is kinof part of player movement.

Animations are also a special case for replication similar to the default humanoid movement. In the case of Roblox’s built-in animation system (using the Animation & AnimationTrack instances), this is how it works:

  • AnimationController must be used when animating objects without a Humanoid.
  • AnimationController:LoadAnimation will create an Animator instance, if one does not exist, which automatically handles replication of animations. I believe you can create an Animator manually with Instance.new
  • If the Animator instance is a descendant of either a Humanoid or a player’s Player.Character, then the animation can be started on the client and it will replicate to the server and all other players.
  • If the Animator is not a descendant of the things said above, then animations will not replicate for others if started on the client. It would have to be done on the server to replicate to others in that case.
  • An important note for the third point, as far as I’m aware, is that the Animator must be created on the server first for replication to work. Once the Animator is created by the server and replicates to everyone for that player, the player can start animations locally and it will replicate.

I believe it would be generally alright to have all your animations replicate to everyone, but if somehow it causes performance issues in the future, you could pick out specific animations which are not important for everyone to see and only play those locally. It really depends on the circumstances.

Further reading

API Reference Links

Animation | Roblox Creator Documentation
AnimationTrack | Roblox Creator Documentation
AnimationController | Roblox Creator Documentation
Animator | Roblox Creator Documentation

1 Like