Roblox Networking

roblox-networking

When to Use

Use this skill when the task is primarily about multiplayer communication, replication, or trust boundaries in a Roblox experience:

• Designing or reviewing RemoteEvent, UnreliableRemoteEvent, and RemoteFunction usage.
• Deciding what the client is allowed to send versus what the server must derive or verify.
• Choosing safe remote payload shapes, validating arguments, and handling replication timing.
• Protecting server logic from spam, malformed payloads, impossible requests, or exploit-driven abuse.
• Building interactions where the client initiates an action but the server remains authoritative.
• Reasoning about network ownership, client-predicted physics, or Touched-related exploit risk.
• Applying server-authority ideas, prediction, rollback-aware structure, or input routing for competitive or authoritative gameplay.
• Designing multiplayer logic that must remain correct when streaming affects what the client can currently see or access.

Do not use this skill when the task is mainly about:

• Persistent data architecture, save formats, trading storage, or DataStore and MemoryStore design.
• Broad engine API lookup as the primary task.
• Open Cloud, OAuth, or external web integrations.

Decision Rules

• Use this skill if the main question is "how should client and server communicate safely and correctly?"
• Use this skill when a feature depends on remotes, replication timing, ownership of simulated parts, or server validation.
• Prefer RemoteEvent for one-way signals and state notifications; prefer UnreliableRemoteEvent only for disposable, continuously changing data; prefer RemoteFunction only when a synchronous reply is truly required.
• Treat the server as the authority for shared game state, rewards, combat outcomes, movement permission, and any action that affects other players.
• If a client can request an action, validate permission, context, type, structure, value range, and frequency on the server before mutating state or broadcasting results.
• If the task is mostly about where scripts live, core services, attributes, bindables, or basic runtime structure without a strong networking/security angle, hand off to roblox-core.
• If the task is mainly about data persistence or cross-server state, hand off to roblox-data.
• If the task is mainly about exhaustive class/member lookup, hand off to roblox-api.
• If a request mixes networking with out-of-scope systems, answer only the multiplayer and trust-boundary portion and explicitly exclude the rest.
• When unsure, omit material that would drift into persistence, cloud auth, or broad API catalog guidance.

Instructions

1. Start by classifying each piece of information:

• Client input intent.
• Server-derived authoritative state.
• Replicated presentation or notification.
• Disposable telemetry or cosmetic updates.

2. Choose the narrowest network primitive that matches the job:

• RemoteEvent for async one-way communication.
• UnreliableRemoteEvent for frequent data where dropped or out-of-order updates are acceptable.
• RemoteFunction only for short, bounded request-response flows where yielding is acceptable and server ownership of the decision is clear.

3. Keep remote contracts explicit and small:

• Prefer stable argument order and dictionaries with string keys.
• Do not rely on metatables, function values, mixed tables, non-replicated instances, or table identity surviving a network hop.
• Pass identifiers, compact values, or validated replicated instances instead of arbitrary object trees.

4. Design remotes around intent, not outcome:

• Client says "I pressed interact on this target" or "I attempted to fire from here toward this hit point."
• Server decides whether the action is legal and computes the result.
• Avoid remotes where the client directly declares rewards, damage, inventory changes, or unrestricted instance mutations.

5. Validate every client-triggered request on the server:

• Permission/context: is the player alive, in range, in the right state, and allowed to do this now?
• Type/shape: are the arguments the expected kinds, sizes, and instance classes?
• Value sanity: reject impossible numbers, NaN, inf, out-of-range vectors, or unknown ids.
• Timing: apply per-player rate limits or cooldowns before expensive work or broadcast fan-out.

6. Treat server-to-client rebroadcasts as privileged operations:

• Never act as a blind relay from one client to other clients.
• Validate first, then broadcast only the minimal safe data needed for presentation.

7. Use RemoteFunction conservatively:

• Expect the caller to yield.
• Keep the callback fast and deterministic.
• Avoid InvokeClient() for critical flows because the server can hang or fail if the client errors, disconnects, or never returns.

8. Reason about replication explicitly:

• A remote arriving does not guarantee a related instance or property has already replicated to the client.
• With streaming enabled, clients may not currently have distant workspace content.
• Use WaitForChild(), replication-aware design, tags, or model streaming controls instead of assuming presence.

9. Treat network ownership as a performance tool with security cost:

• Client-owned physics can feel responsive.
• Client-owned physics can also be abused, and Touched-based server logic becomes especially risky.
• Keep gameplay-critical physics server-owned unless the responsiveness tradeoff is worth the validation burden.

10. For authoritative or competitive gameplay:

• Prefer a server-authority mindset where the server is the source of truth and the client primarily contributes input.
• Use the Input Action System for inputs that affect the core authoritative simulation.
• Keep simulation state separate from local rendering and effects.

11. When discussing examples, stay inside scope:

• Focus on multiplayer communication, validation, ownership, authority, and streaming correctness.
• Do not expand into persistence architecture, cloud APIs, or general-purpose API catalogs.

Using References

• Open references/remote-events-and-callbacks.md for remote selection, directionality, argument-shape limits, and safe payload design.
• Open references/client-server-runtime.md for replication timing, latency expectations, and side ownership of gameplay responsibilities.
• Open references/security-and-defensive-design.md for the security mindset, defensive design, and rate-limiting patterns.
• Open references/client-server-boundary-guidance.md for concrete validation layers, secure rebroadcast patterns, and protection of client-triggered interactions.
• Open references/network-ownership.md when physics responsiveness, client-owned parts, or Touched validity are part of the problem.
• Open references/server-authority-model-and-techniques.md for authoritative simulation, prediction, rollback-aware structure, and latency-conscious design.
• Open references/input-action-system.md when networked or authoritative gameplay depends on action-oriented, cross-platform input routing.
• Open references/streaming-and-replication-behavior.md when correctness depends on streamed workspace content, replication focus, or models that may not be locally present.

Checklist

• The client-server contract is defined in terms of player intent, not client-declared outcomes.
• The chosen remote primitive matches the required reliability and response behavior.
• Remote payloads use stable, replication-safe shapes.
• The server validates permission, context, type, structure, and values before mutating shared state.
• The server applies rate limits or cooldowns to abuse-prone entry points.
• Server-to-client broadcasts happen only after validation and never as blind relays.
• RemoteFunction use is justified and bounded.
• Replication timing assumptions are explicit, especially when remotes reference freshly created or streamed content.
• Network ownership choices are deliberate and paired with server-side validation where needed.
• Touched, proximity, click, or drag interactions are not trusted just because the engine fired them.
• Authoritative gameplay uses client inputs and server-owned state rather than trusting client simulation results.
• Input guidance stays focused on networked or authoritative use of the Input Action System.
• No persistence architecture, Open Cloud, OAuth, or broad API catalog material is included.

Common Mistakes

• Letting the client tell the server who was damaged, what reward was earned, or which state change already happened.
• Using RemoteFunction for convenience when an async RemoteEvent plus server-side state would be safer.
• Broadcasting one client's payload to every other client without validating it first.
• Passing mixed tables, metatable-backed objects, huge payloads, or sender-only instances across remotes.
• Forgetting to reject NaN, inf, oversized strings, or spoofed instance references.
• Assuming a remote means an associated part, attribute, or model has already replicated.
• Relying on client cooldowns without server-side rate limiting.
• Treating client-owned physics or Touched events as authoritative proof of contact.
• Using unreliable channels for state that must arrive in order.
• Mixing core authoritative simulation logic with local-only animation, camera, or VFX code.

Examples

Design a secure client-triggered interaction

-- Client: request an interaction attempt, not the reward itself.
InteractRemote:FireServer(targetId)

-- Server: verify range, state, and target validity before applying effects.
InteractRemote.OnServerEvent:Connect(function(player, targetId)
    -- Validate player state, target existence, distance, cooldown, and permissions.
    -- Then mutate shared state on the server.
end)

Use unreliable remotes only for disposable updates

-- Suitable for frequent cosmetic aim or camera direction updates.
AimDirectionRemote:FireServer(lookVector)

• Accept dropped or out-of-order packets.
• Do not use this pattern for inventory, damage, scoring, or one-time transactions.

Keep authoritative simulation separate from rendering

-- Core state changes live in shared/server-side simulation logic.
-- Local VFX and sounds react to the synchronized state afterward.

Client-Server Boundary Guidance

Key Concepts

• Every client-triggered action is a trust boundary.
• Validation has multiple layers: permission, type, structure, value, and timing.
• Client-triggered instances such as prompts or click detectors need the same skepticism as remotes.
• The server must be a gatekeeper, not a transparent relay to other clients.

Rules

• Validate player context on the server: alive state, distance, ownership, cooldowns, and permissions.
• Validate argument type and structure before using values or instances.
• Reject NaN, inf, impossible coordinates, unknown ids, and oversized strings or tables.
• Confirm instance arguments are real instances of the expected class in an expected container.
• Never trust client-side cooldowns or distance checks as sufficient.
• Validate before rebroadcasting to other clients.

Patterns

Layered validation

local function isNaN(n)
    return n ~= n
end

local function isInf(n)
    return math.abs(n) == math.huge
end

• Type-check first.
• Then validate shape and ownership.
• Then validate value ranges and action timing.

Server-side rebroadcast

LightningRemote.OnServerEvent:Connect(function(player, strikePosition)
    -- Validate type, cooldown, permission, and range.
    LightningRemote:FireAllClients(player, strikePosition)
end)

• Broadcast only after the request is proven safe.

Secure client-triggered interactions

• ProximityPrompt: verify enabled state, distance, hold timing, and player state on the server.
• ClickDetector: add your own server checks; engine-side trust is minimal.
• Touched: validate contact independently, especially for client-owned assemblies.

Examples

Spoof-resistant instance check

if typeof(item) ~= "Instance" or not item:IsDescendantOf(ItemCatalog) then
    return
end

Unsafe relay pattern

Remote.OnServerEvent:Connect(function(_, payload)
    Remote:FireAllClients(payload)
end)

• This turns one client into an attack surface for every other client.

Client-Server Runtime

Key Concepts

• Roblox experiences run in a multiplayer client-server model by default.
• The server is the authority for shared experience state.
• Clients render local presentation, read local input, and observe replicated state.
• Replication covers the data model, relevant physics updates, and other synchronized systems.
• Real player latency is significant enough that networking design must tolerate delay and reordering.

Rules

• Put authoritative rules, shared state transitions, and final decisions on the server.
• Put local input collection, camera, and UI response on the client.
• Assume a remote signal and a related replicated object may arrive in either order unless the API guarantees otherwise.
• Test with simulated replication lag instead of relying on zero-latency Studio defaults.
• Treat the client view as partial when streaming is enabled.

Patterns

Separate request from result

-- Client requests an action attempt.
OpenDoorRemote:FireServer(doorId)

-- Server validates and then changes replicated state.

Handle eventual replication

local ReplicatedStorage = game:GetService("ReplicatedStorage")

local SharedFolder = ReplicatedStorage:WaitForChild("SharedFolder")

• Use WaitForChild() or equivalent guards on the client when order is not guaranteed.
• Avoid assuming a server-created instance already exists locally when a remote arrives.

Examples

Server owns the outcome

ClaimCheckpointRemote.OnServerEvent:Connect(function(player, checkpointId)
    -- Server verifies order and updates progression.
end)

Client owns presentation

CountdownRemote.OnClientEvent:Connect(function(secondsRemaining)
    print(secondsRemaining)
end)

Input Action System

Key Concepts

• The Input Action System maps gameplay actions to device-specific bindings.
• Actions are a better network contract than raw hardware events.
• In authoritative gameplay, core simulation should consume action data rather than ad hoc local input events.
• Contexts let the same experience switch input sets safely across gameplay states.

Rules

• Use action-oriented inputs for gameplay that must work across keyboard, gamepad, and touch.
• For authoritative simulation, prefer action data over direct UserInputService.InputBegan handling.
• Place InputContext objects where the owning player can use them correctly.
• Keep core simulation inputs distinct from local-only UI or camera controls.
• If writing custom input-derived data into authoritative systems, keep that write path outside the simulation callback when required by the engine model.

Patterns

Define gameplay actions

• Jump
• Sprint
• Shoot
• Throttle
• LookDirection

Bind multiple devices to one action

local inputAction = script.Parent

inputAction.Pressed:Connect(function()
    print("Action pressed")
end)

• One action can represent a keyboard key, gamepad button, or touch button.
• Network code can reason about the action instead of platform-specific hardware.

Separate action classes

• Core simulation actions: movement, jump, fire, drive, interact.
• Local presentation actions: camera-only or UI-only behaviors that do not change authoritative state.

Examples

Authoritative-friendly design

• Client records "sprint pressed" as an action.
• Server or shared simulation code decides whether sprint is allowed based on stamina and state.

Avoid for core authority

UserInputService.InputBegan:Connect(function(input)
    -- Do not use raw device events as the primary authoritative input contract.
end)

Network Ownership

Key Concepts

• Roblox can assign ownership of unanchored physics assemblies to a client or the server.
• Client ownership improves responsiveness because local simulation avoids a round trip.
• Ownership is also a security boundary because the server cannot directly verify every client-side physics step.
• Touched behavior is affected by ownership and can be abused if treated as authoritative proof.

Rules

• Keep anchored parts server-owned; their ownership cannot be reassigned.
• Use manual ownership only when responsiveness clearly outweighs the validation burden.
• Prefer server ownership for gameplay-critical objects when exploit resistance matters more than feel.
• Revert temporary ownership with SetNetworkOwnershipAuto() when special control is no longer needed.
• Treat client-owned physics events as claims to validate, not facts to trust.

Patterns

Assign a driver-controlled vehicle

vehicleSeat.Changed:Connect(function(prop)
    if prop ~= "Occupant" then
        return
    end

    local humanoid = vehicleSeat.Occupant
    if humanoid then
        local player = Players:GetPlayerFromCharacter(humanoid.Parent)
        if player then
            vehicleSeat:SetNetworkOwner(player)
        end
    else
        vehicleSeat:SetNetworkOwnershipAuto()
    end
end)

• Give the driver responsiveness.
• Reset ownership when the seat is empty.

Validate ownership-sensitive interactions

• For melee or projectiles, verify range and state on the server.
• Avoid trusting Touched alone for damage on client-owned parts.
• Anchor or server-own critical interactables when feasible.

Examples

Good use case

• A drivable vehicle that needs low-latency steering.

Bad use case

• Letting a client-owned sword hitbox directly determine server damage with no additional checks.

Remote Events And Callbacks

Key Concepts

• RemoteEvent is the default primitive for async client-server communication.
• UnreliableRemoteEvent is for disposable, high-frequency updates where loss or reordering is acceptable.
• RemoteFunction is synchronous and causes the caller to yield until a response returns.
• Clients cannot talk directly to other clients; all cross-player communication goes through the server.
• Remote payloads are copied across the boundary and lose table identity and metatables.

Rules

• Prefer RemoteEvent unless a true request-response contract is required.
• Use UnreliableRemoteEvent only for transient data such as frequent aiming or look updates.
• Avoid RemoteFunction:InvokeClient() for critical flows because the server can error or hang on client failure.
• Keep argument shapes simple: numbers, strings, booleans, vectors, replicated instances, and tables with string keys.
• Do not send functions, rely on metatables, or mix numeric and string keys in one table.
• Do not expect sender-only instances to survive replication; non-replicated objects arrive as nil.

Patterns

Choose direction by authority

• Client to server: send player intent or request attempts.
• Server to client: send authoritative results, UI updates, or local presentation instructions.
• Server to all clients: broadcast validated state changes or shared presentation events.

Keep payloads compact

FireWeaponRemote:FireServer(origin, hitPosition, targetId)

• Send compact, validated facts.
• Let the server derive damage, ammo use, and legality.

Use a function only for bounded lookups

local success, reason = BuyItemRemote:InvokeServer(itemId)

• Keep the callback fast.
• Return a small result, not authoritative ownership of the game state.

Examples

Safe server callback shape

BuyItemRemote.OnServerInvoke = function(player, itemId)
    if typeof(itemId) ~= "string" then
        return false, "invalid-item"
    end

    return true, "ok"
end

Unsafe argument shape

Remote:FireServer({
    weapon = "Sword",
    [1] = "mixed-table",
})

• Mixed tables can serialize in surprising ways.
• Prefer either an array or a dictionary, not both.

Security And Defensive Design

Key Concepts

• Never trust the client; assume any client-controlled input can be fabricated or spammed.
• Defensive design is stronger than purely reactive exploit detection.
• The server should be the source of truth for rules, rewards, combat outcomes, and shared state.
• Abuse resistance includes both validation and limiting how often an action can run.

Rules

• Threat-model every client-triggered feature before finalizing its network contract.
• Design features so cheating is impossible or low-value instead of only trying to detect it afterward.
• Keep sensitive logic and authoritative state on the server, not in replicated containers.
• Apply server-side cooldowns or token-bucket rate limits to abuse-prone operations.
• Reject malformed, oversized, or costly inputs before expensive work or fan-out broadcasts.

Patterns

Defend by changing the game rule

• Obby rewards: require ordered checkpoints, not just final-position claims.
• Combat: let the server compute damage from trusted weapon state.
• Economy: validate server-side inventory and cooldown state before granting items.

Token bucket limiter

local function allow(bucket, now, capacity, refillPerSecond)
    local elapsed = now - bucket.last
    bucket.tokens = math.min(capacity, bucket.tokens + elapsed * refillPerSecond)
    bucket.last = now

    if bucket.tokens >= 1 then
        bucket.tokens -= 1
        return true
    end

    return false
end

• Allow short bursts.
• Block sustained spam.

Examples

Good design question

• If a player can call this 500 times per second, what breaks first?

Better network contract

CastSpellRemote.OnServerEvent:Connect(function(player, spellId, targetPosition)
    -- Validate unlocks, cooldown, range, and value shape before broadcasting results.
end)

Server Authority Model And Techniques

Key Concepts

• In a server-authority model, the server is the source of truth and clients primarily contribute inputs.
• Responsiveness comes from client prediction, then rollback and resimulation when predictions are wrong.
• Competitive or exploit-sensitive gameplay benefits from this structure.
• Roblox's current server-authority APIs are beta-specific and should be treated accordingly.

Rules

• Keep the authoritative game state on the server.
• Let clients send inputs, not final simulation outcomes.
• Separate core simulation from rendering, animation, and effects.
• Expect mispredictions and build systems that tolerate correction.
• Use remote events for discrete messages even in authoritative systems, but keep authority on the server.

Patterns

Prediction-aware structure

• Simulation logic updates state.
• Render logic reads synchronized state and plays local presentation.
• Corrections should update state first, then visuals react.

Latency-conscious design

• Prefer mechanics that tolerate delay and correction.
• Use delayed or state-based feedback when instant all-or-nothing actions produce obvious artifacts.
• Forward only the inputs or small synchronized state needed to reproduce behavior.

Shared simulation module

local RunService = game:GetService("RunService")

local Simulation = {}

function Simulation.Initialize()
    RunService:BindToSimulation(function(deltaTime)
        -- Read synchronized inputs and update core state.
    end)
end

return Simulation

Examples

Good authoritative contract

• Client sends throttle, steering, or action input.
• Server decides movement, collisions, scoring, and legality.

Render-side response

RunService.RenderStepped:Connect(function()
    -- Read synchronized state and play sounds or VFX.
end)

Streaming And Replication Behavior

Key Concepts

• With Workspace.StreamingEnabled, clients may not have the full world loaded.
• A remote or replicated property change does not guarantee a related workspace instance is already present locally.
• Models can stream in and out based on global and per-model settings.
• Replication focus affects what regions stream and continue simulating on the client.

Rules

• Never assume distant workspace content exists on the client.
• Use WaitForChild(), streaming detection, or per-model streaming controls when client code depends on an object being present.
• Keep large 3D content in Workspace, not replicated containers, so streaming can manage it.
• When teleporting or moving a character far away, request streaming around the destination before relying on local presence.
• Do not use persistent streaming modes as a blanket workaround for weak client logic.

Patterns

Replication-aware remote follow-up

TeamChangedRemote.OnClientEvent:Connect(function()
    local character = player.Character or player.CharacterAdded:Wait()
    local badge = character:WaitForChild("PoliceBadge")
end)

• The event may arrive before the related instance does.
• Wait for the instance explicitly.

Detect stream in and stream out

CollectionService:GetInstanceAddedSignal("Interactable"):Connect(function(instance)
    -- Initialize local behavior when the instance is present.
end)

• Use tags and one local controller instead of assuming a static workspace.

Use model streaming deliberately

• Atomic when descendants must arrive together.
• Persistent only for rare, small always-present requirements.
• Additional replication foci only when the player truly needs multiple active areas.

Examples

Safe teleport flow

player:RequestStreamAroundAsync(targetPosition)

• Request the area before moving the character.
• Still treat completion as best effort, not a hard guarantee.

Streaming-sensitive gameplay caution

• Client-side raycasts can miss distant objects that have not streamed in.
• Critical hit or interaction validation should remain on the server.