Server authority model

In a server authority model, the server is the single source of truth for the entire game state, and clients are only trusted to report their own inputs. This architecture is the core netcode foundation of a fair, competitive game because it prevents entire classes of cheating like flyhacks or speedhacks by never trusting a client to report its own position or state.

Advantages

In a naive server-owned system, clients would simply send their inputs to the server and display the results of the game sent back by the server. While technically correct, such a system would face significant input latency because every player action would have to travel to the server, be processed, and have the result sent back to the client before it could be displayed. For most games, especially those fast‑paced, that round‑trip delay would cause gameplay to feel laggy, unresponsive, and unplayable.

In Roblox's server authority model, latency is compensated for by having clients instantly predict the effects of their inputs in addition to sending them to the server. For example, when a player presses a key, the client doesn't wait for the server to respond; instead it predicts a few frames ahead of the last known server state. This allows the client to show the result of the input action instantly, effectively hiding network latency and making the game feel responsive.

Sometimes the client will get its prediction wrong (misprediction) and, because of network latency, the client will not know that it has made a mistake for a few frames. For example:

When a misprediction is detected, the client must correct its prediction based on the server's authoritative state. If the authoritative state is different from the client's predicted state, the client must roll back and resimulate its predicted frames. This system of client‑side prediction, rollback, and resimulation is known as "latency compensation" and helps make server‑authoritative multiplayer games feel smooth and responsive.

Setup

The server authority model requires certain other engine technologies to function correctly. Confirm the following property settings on the Workspace object in the Explorer:

1. Workspace.AuthorityMode must be Server (setting this automatically sets the following five).
2. Workspace.NextGenerationReplication must be enabled.
3. Workspace.PlayerScriptsUseInputActionSystem must be enabled.
4. Workspace.SignalBehavior must be Deferred.
5. Workspace.UseFixedSimulation must be enabled.
6. Workspace.StreamingEnabled must be enabled.

Concepts

The server authority system runs on a few core concepts as follows.

Client prediction

Through client prediction, the client simulates a few frames ahead of the last known server state to predict the effects of player inputs immediately. This hides input latency, but the prediction may later turn out to be incorrect (client misprediction) and thus require correction. The client tries to simulate just far enough ahead of the last known authoritative server state so that its inputs arrive on the server at the intended frame. The number of frames the client will predict ahead of the known server state is based on the latency behind the client and server.

Client misprediction

When the client receives the authoritative state from the server, it checks that state against a historical record of what it predicted locally for that frame. When there is a difference between what the client predicted and what the server actually did, this is a misprediction. Mispredictions can occur for several reasons, including shifts in network latency, other players acting in ways the client didn't anticipate, the game running certain logic exclusively on the server, etc.

If the authoritative state is different from the client's predicted state, the client must roll back and resimulate.

Rollback and resimulation

When a client detects a misprediction, it must reset to the server's authoritative state and then resimulate to jump back to its predicted frame. Based on the network latency, the client tries to simulate just far enough ahead of the last known authoritative server state so that its inputs arrive on the server at the intended frame.

In summary, the client:

1. Receives the authoritative state from the server and compares it against its own predicted state.
2. If the client's prediction was incorrect:

   1. Client rolls back to the last known authoritative state received from the server.
   2. Client resimulates from the authoritative state to its predicted state, re-applying any local inputs.

Implementation

Network ownership and prediction

In the server authority model, you're able to keep the core gameplay objects server‑owned without incurring the input latency cost normally associated with server ownership. Things like cars, player characters, or other gameplay‑critical objects can remain server‑owned, even when interacting with other players.

By default, Roblox will automatically predict properties with simulation access near the local player Character, but if you want more fine‑grained control, you can explicitly force an instance's prediction on or off with RunService:SetPredictionMode().

Simulation sync

In the server authority model, the client and the server must both run the core simulation, and the client's simulation needs to be able to roll back and resimulate when a misprediction occurs. To enable this, write your core logic inside functions bound through RunService:BindToSimulation() in a ModuleScript that's initialized on both the client and server.

During a resimulation, Roblox will re-run the functions bound to the simulation via BindToSimulation(). Processing player inputs, interacting with synchronized physics objects, and updating the core game state should live inside those bound functions.

ModuleScript named Simulation in ReplicatedStorage:

Simulation
local RunService = game:GetService("RunService")
local Players = game:GetService("Players")

local Simulation = {}

Simulation.Initialize = function()
	RunService:BindToSimulation(function(deltaTime)
		-- Read player inputs
		-- Update game state
	end)
end

return Simulation

State sync with attributes

Roblox automatically synchronizes all properties with simulation access on predicted instances. For custom data, attributes are the primary way to synchronize instances marked as predicted; on such instances, any mismatch in attribute values between the server's source of truth and the client's prediction will trigger a full rollback and resimulation.

Attribute limits

In order to be replicated, an attribute must meet all of the following criteria:

• It is among the first 64 attributes on its Instance.
• Its name contains at most 50 characters.
• If a string type attribute, its value contains at most 50 characters.

Simulation access

Many properties and methods in the engine API reference include the Simulation Access label, for example BasePart.CFrame. Properties with this label will be predicted by the server authority system. Additionally, only properties and methods with this label can be accessed inside functions bound with RunService:BindToSimulation().

Input actions

In a server-authoritative game, the primary way for a client to affect the game's state is through the Input Action System. These inputs are sent to the server and are replayed during resimulation on the client. As a result, InputActions should be used for all inputs that affect the core simulation and they should be checked for sanity before they're processed.

Note that InputContexts must be a descendent of a Player so that the engine knows who has ownership over the InputContext. One approach is to add your InputContexts to a folder under ReplicatedStorage and use a Script under ServerScriptService to clone the InputContexts per player:

InputSetup
local Players = game:GetService("Players")
local ReplicatedStorage = game:GetService("ReplicatedStorage")

local InputsFolder = ReplicatedStorage:WaitForChild("Inputs")

local function onPlayerAdded(player)
	local clone = InputsFolder:Clone()
	clone.Parent = player
end

Players.PlayerAdded:Connect(onPlayerAdded)

for _, player in Players:GetPlayers() do
	onPlayerAdded(player)
end

Using this pattern, you can read InputActions for all players in RunService:BindToSimulation() on both client and server to receive the same data for a given frame and record the previous frame's input in an attribute, for example to trigger a character run when a RunAction input action is triggered.

Remote events

Remote events can still be used within the server authority model to facilitate discrete communication between client and server. For example, servers can use remote events to broadcast data about players scoring points or picking up objects, and clients can use remote events as an alternative API for sending inputs to the server, such as for button presses or tapping objects in the 3D world.

Animations, sounds, and effects

Client-side effects like animations and sounds must be written knowing that the client simulation is merely a prediction of the authoritative server state. BindToSimulation() limits what properties and methods can be called from within bound functions to help guide you in writing only to the synchronized simulation state. Displaying the results of this simulation, triggering effects and sounds, etc. should be done in a separate function connected to RenderStepped that reads the results of the simulation and triggers the desired effects.

Further guidance around rendering a predicted simulation is covered in the advanced techniques guide.

Example projects

In addition to this documentation, the following templates can help you get started: