Hello 
! Today, I’m here to teach you the basics of the new Server Authority system that Roblox has released out of Early Access and into Beta. In this tutorial, I will explain the core concepts behind Server Authority and Rollback Netcode and give you information on how to begin working with it on Roblox. Let’s begin.
How to Enable Server Authority
Before we start this tutorial, you first need to enable the Server Authority Core API beta feature in Roblox Studio. To do this, simply go to “File > Beta Features > Server Authority Core API”, check the box, and click “Save”.
After restart, head over to Workspace, and configure these properties to the required values:
Workspace > StreamingEnabled:EnabledWorkspace > UseFixedSimulation:EnabledWorkspace > PlayerScriptsUseInputActionSystem:EnabledWorkspace > NextGenerationReplication:Enabled
Configuring these properties will now allow you to configure another property, which you need for enabling Server Authority:
Workspace > Server Authority > AuthorityMode:Server
After configuring the properties above, Server Authority should now be ready for usage.
What is Server Authority?
Server Authority is when the server becomes the only source of truth for game actions, logic and data in your world.
In this model, clients can no longer hold network ownership of any instances. This ensures the trusted data replicated from the client to the server is kept at a minimum. The only trusted data that the server recieves from the clients are their inputs, which is used to simulate their characters or systems controlled by them. This results in a far more secure model, which reduces or outright removes many problems that have arisen from giving clients network ownership of certain parts and systems in your world.
How does this effect the physics around my world?
Server Authority completely changes the behavior of all unanchored Parts in the Workspace. Before; the physics calculation of a Part was handled by both the server and the clients in a place. When a client came close to a Part, the network ownership would automatically shift from the server to the client, so the client could take the burden of calculating the physics for that Part.
A similar case was also in effect for the characters too. Before, because of network ownership, the client had full control over their character. This allowed them to change certain properties of their character such as velocity, position, rotation, and many others to their liking. This of course, caused many security issues. Using exploits, the client would be able to give themselves an unfair advantage in gameplay by changing these properties. This gave the rise of many exploiting issues such as speed-hacking, fly-hacking, no-clipping, teleporting, and many others inside popular places on the platform.
The issues are not only limited to exploiting. In many competitive games, such as racing, the cars would most of the time be misaligned, or their position would constantly jitter, or look very different. That is because of client calculated physics of the previous system. Because the network ownership of each car is set to each client, rather than the server, the car positions would end up different than expected.
However, with Server Authority, most of these issues, if not all of them, are automatically resolved.
For the case of the character, where a client would modify their character to gain an unfair advantage such as speedhacking, would no longer be possible, as the client no longer holds ownership of their character, and all that is given to the server are inputs.
For the case of the racing games, since the server now calculates the positions of the cars, they now move more consistently. Maneuvers, drifts, hits become more accurate, and the system works as smooth as possible.
The Problem with Server Authority
For the reasons I’ve given above, Server Authority sounds amazing, it improves accuracy, increases security and overall produces a better experience for players, right? Not exactly.
Server Authority on its own is horrible for player experience. This is simply due to the fact that players are from all around the world, where they might be hundereds, if not thousands of miles away from the nearest server. This distance means their ping will be high, which means the time it will take for a player’s input to reach the server will also be high. This creates a choppy, very uncomfortable experience where a player might only start seeing their character move after a long time has passed since they sent their input. Imagine pressing the “W” key and only seeing your character move after a second or two. It would make it incredibly hard to play a game, if not outright impossible for some players.
Luckily, there is a solution that exists which solves these problems. This solution has existed for a very long time, and many competitive games out there already use it. It is called “Rollback Netcode”.
What is Rollback Netcode?
To give a short explanation on what Rollback Netcode is, this concept is when the client also simulates its own input alongside the server, but just a little bit ahead of it. For the inputs to feel responsive and smooth, the client immediately simulates them when they are given, while sending them to the server. Since the server is the authority here, this simulation doesn’t hold an important value, and is purely done for the visuals, so we call them "prediction"s. Essentially, the client “predicts” how their inputs will effect the game state (e.g, their character), while the server determines how their inputs will actually effect the game state.
However, there might be times where the client prediction and the actual simulation results may differ from each other. For example, assuming T is the current time, the client has made a prediction at T-3, and when the authoritative update arrives for T-3 from the server, the client notices its prediction and the authoritative update results are different from each other. This is called a “Misprediction”. In this case, the client rolls back to the authoritative update frame by reverting its current state and time. This is called a “Rollback”. Then, the client re-simulates automatically after rollback to speed back to its current predicted frame. The number of frames to re-simulate is based on the latency between the client and the server, however, the client tries to stay far enough ahead of the server so that its own inputs arrive on the server just in time to be processed on the frame the player intended to perform them.
Mispredictions are normal and expected. They should be small and the resulting correction should be imperceptible to clients.
(You can check out articles on the web, such as this one, to learn more about the concept of Rollback Netcode.)
Example:
Your client thinks you’ve moved forward. However, the server registered that you were hit by a stun grenade and can’t move for a few seconds. The client and server now have different states.
Like I have mentioned above, this divergence is called a misprediction. It can occur for several reasons: the network latency has shifted, other players acted in ways the client didn’t anticipate, the experience runs certain logic exclusively on the server, etc. While you can’t prevent every misprediction, you can keep gameplay feeling smooth and responsive by using the right techniques.
Example:
Let’s say there is 100ms of latency between the client and server, and the experience is a 60Hz game.
Each frame is 1/60s (or 16.67ms). Since 100ms of latency is equivalent to ~6 frames (100 ms divided by 16.67 ms/frame), we know the client will be 6 frames ahead of the server. This means that, when the client detects it made a misprediction, it will rollback to the server’s state and then re-simulate 6 frames ahead. In general, the player should hardly notice this.
How can I start working with Server Authority on Roblox?
Now that we have learned the basic concepts, we can now move on to learning how to actually apply these concepts on Roblox. To begin, we first need to talk about IAS.
The Input Action System
The Input Action System (IAS) is a major part of the Server Authority system. It allows you to reliably transfer inputs from client to the server, while allowing you to customize them easily. I will not be explaining this system and how it works however. You can check out the main post talking about it through here.
Player inputs like joystick movement and button presses are sent from client to server using InputActions. You have to use InputAction for all inputs that affect the core game simulation, because they are the only client authoritative data in the core rollback system.
You can send any continuous stream of data from the client to server using this API, and the server will trust what the client has sent. It is up to you to validate that the clients have sent legitimate inputs. Be sure to enforce maximum and minimum ranges on numbers sent from the client, just like how you would validate values sent from remotes.
Note: The server will automatically ignore input data from the client if it arrives far too late or far too early, which can happen if there are sudden changes in a client’s network conditions.
Now, let’s apply all of the concepts I’ve explained above with IAS on Roblox. We start by using the new methods of RunService.
RunService
RunService:BindToSimulation(function: (deltaTime: number) -> (), frequency: Enum.StepFrequency?)
This method allows you to bind a function to the simulation with a certain amount of frequency. Depending on the frequency, this function will be called with a deltaTime argument. If a frequency argument has not been provided, then it will default to Enum.StepFrequency.Hz60. This is the right place to put your core game logic, including processing input and updating your synchronized game data. This function will also be ran when a rollback occurs.
RunService:SetPredictionMode(context: Instance, mode: Enum.PredictionMode)
Determines whether the engine will rollback and resimulate the context Instance.
- If
modeisEnum.PredictionMode.Off: Disables rollback and resimulation for the Instance. When a place’sWorkspace.AuthorityModeis set toServer, theInstancewill be owned by the server with no client-side prediction. - If
modeisEnum.PredictionMode.Automatic(default value): Allows the engine to determine whether to rollback and resimulate theInstance. ForInstances that derive fromBasePart, the engine uses the player’s simulation radius to determine if anInstanceshould be predicted. This helps limit expensive client-side prediction to only the relevantInstances. At the moment, Non-BaseParts will not rollback when set toAutomatic. - If
modeisEnum.PredictionMode.On: Will ensure theInstanceis always rolled back when a misprediction occurs. ForInstances critical to your experience, use this setting. Otherwise, do not overuseOnforInstances, as it’ll have significant performance implications for low-end devices.
RunService:GetPredictionStatus(context: Instance): Enum.PredictionStatus
This function allows you to check the prediction status of the context Instance. This may be essential for scripts affecting multiple instances (e.g., vehicle controllers, custom physics) where some might be predicted and other might not. It may also be useful for debugging and observing the effects of automatic prediction.
RunService will be our main tool in creating systems with Server Authority and Rollback Netcode. We utilize it to run a functions during simulation on both the Client and the Server.
With RunService:BindToSimulation(), we run our important core game logic on the Server, allowing the Server to be authoritative over this game logic. Like I mentioned in above sections, this can be character or vehicle movement systems, or other logic that is very important to your game. However, for the client to predict these systems to the inputs can remain smooth and responsive, we also need to run the same simulation code on the client.
Essentially, we need to run the same code on both the Client and the Server, using RunService:BindToSimulation(), to apply all of the concepts mentioned above. This ensures the server to stay authoritative, while allowing the client to be more responsive.
To do this easily, we can opt into using a multi-script architecture, where a ModuleScript is parented to a location that is accessible from both the Server and the Client, such as ReplicatedStorage, is required and ran by both the Server and the Client.
Here’s a simple example of this architecture:
We have two scripts which initialize the “SimulationModule” ModuleScript on both the Server and the Client.
SimulationClient and SimulationServer
require(script.Parent.SimulationModule).Run()
SimulationModule
local RunService = game:GetService("RunService")
local module = {}
function module.Run()
RunService:BindToSimulation(function(deltaTime: number)
-- This code will be ran on both the server and the client.
end)
end
return module
This simple architecture is the foundation of many systems that run on the server-authoritative model. Using this, we can implement many types of systems, such as a character movement system, and more!
Closure
Thank you all for reading this tutorial, if you have any suggestions or feedback, please let me know in the replies section. This tutorial was made with the information that I have compiled in my own documentation, which can be found here. It also includes examples of systems which you can create with Server Authority, such as an admin commands system with a Fly command.
I would also like to thank everyone who gave me additional information about this system, without all of that information, I wouldn’t have been able to create this tutorial this early. Thank you.
I’d like to implement server authority but I don’t want to use streaming for my game’s environments.
)