We use cookies on this site to enhance your user experience

Roblox Client-Server Model

Roblox Client-Server Model

10 min

Roblox uses the client-server model, a common framework for multiplayer games. Whenever you play a Roblox game, your personal computer, phone, tablet, or game console becomes a client. Every other unique player in the game is also a client.

All clients (players) in the game are connected to a powerful Roblox computer known as a server. The server is like the game manager — it makes sure that every player is seeing and experiencing the game world the same as every other player.

Client-Server Communication

During gameplay, the server constantly updates the connected clients. For instance, imagine a game Script that changes the time of day to midnight. A Script can only run on the server, so the server is the first place to see day turn to night. At that point, the server automatically tells all clients to change their game time as well.

Clients can also talk to the server. This typically happens when you press a button/key or other control on your device (client), telling the server to update your game character in the world so every other player sees where you are and what you’re doing.

Testing a Client-Server Simulation

Testing games is critical for success. The Play and Play Here modes in Studio work well for general testing, but they only simulate one client (you) playing the game. When testing in these modes, Studio acts as both a client and a server, so game scripts are allowed to do everything that both clients and servers can do.

Clearly this is not a realistic simulation of a live, published game, so it’s highly recommended that you test with Server/Players from the Test tab. This will launch multiple sessions of Studio, one acting as the server and each other acting as a client.

  1. Select the Test tab in Studio.
  2. In the Clients and Servers section, make sure Local Server is selected in the upper box.
  1. In the next box, select the number of player sessions to test (usually “1 Player” is fine).
  1. Press the Start button to begin the client-server simulation.

Understanding Client and Server Scripts

When writing scripts for a game, it’s important that both clients and servers handle specific tasks as follows:

Client Code

In general, the client should detect player input and display information to that specific player. For instance, Articles/intro to player tools|player tools respond to player input and may trigger changes on the server, but they should first be handled on the client to give players immediate feedback. Likewise, client-side menus, maps, and other GUIs should be managed by client code.

Client code runs inside a LocalScript. This code will only start running if the LocalScript is a descendant of these instances:

  • A player’s Player/Character|Character model
  • A player’s PlayerGui
  • A player’s Backpack
  • A player’s PlayerScripts folder
  • A Tool (only when equipped by a player)
  • The ReplicatedFirst folder

Server Code

The game server should be responsible for game logic, saving player data, updating scores, creating parts, etc. There are several reasons for this, including:

  • If the script code changes the game world (creates or removes parts, for example), the server makes sure that all clients see the same change.
  • If a player’s health or score is controlled by the server, a hacker cannot change these values in a way that will affect other players.

Server code runs inside a Script. This code will only start running if the Script is a descendant of these instances:

  • Workspace
  • ServerScriptService
  • A player’s Backpack

Remote Functions/Events

Servers handle many tasks automatically, but sometimes you’ll need to send the server a specific command unique to your game design. This can be done through Articles/Remote Functions and Events|remote functions and events, objects that both Script|Scripts and LocalScript|LocalScripts can use to communicate with each other.

Exceptions

There are some client-side actions that replicate instantly and don’t require the server’s permission. These are generally linked to things that a player should see right away, while others are for your convenience.

Object Exception
Humanoid The Humanoid/Jump|Humanoid.Jump and Humanoid/Sit|Humanoid.Sit properties will replicate from a client to the server instantly. Note that this only works for the local player's humanoid object — if a LocalScript tries to update another player’s humanoid, the command will be ignored.
Sound The Sound/TimePosition|Sound.TimePosition and Sound/Playing|Sound.Playing properties will replicate from a client to the server, so if a client starts playing a sound, all the other clients will play it too. See the Sound documentation for more details.
AnimationTrack If a client calls AnimationTrack/Play|AnimationTrack:Play() or AnimationTrack/Stop|AnimationTrack:Stop() on an AnimationTrack, the animating model will animate on the client and replicate to the server.
BasePart While part properties do not technically replicate, there are a few exceptions. If the part is created by a client and that client simulates physics (the part falls, hits other objects, moves by constraints, etc.), the resulting changes will get copied to the server.
ClickDetector Most ClickDetector events will fire on both clients and the server, including the input events ClickDetector/MouseClick|MouseClick, ClickDetector/MouseHoverEnter|MouseHoverEnter, ClickDetector/MouseHoverLeave|MouseHoverLeave, and ClickDetector/RightMouseClick|RightMouseClick.