PcoWSkbVqDnWTu_dm2ix
We use cookies on this site to enhance your user experience

Roblox Client-Server Model

Roblox Client-Server Model

Oct 11 2018, 1:43 PM PST 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.

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.

Server-Side Validation

RemoteEvent|RemoteEvents and RemoteFunction|RemoteFunctions are the best option for client-server communication, but they’re not necessarily secure channels. A clever hacker may fake a remote event or change the values that are passed along with it. Because of this, you should use basic server-side validation to confirm that the incoming request is legal.

Consider a game with a shop system. When a player wants to buy an item, he or she will interact with an interface on the client side, for instance a ScreenGui with a “Buy” button. When the button is pressed, the client can send a remote event to the server and request the purchase. However, it’s important that the server — the most reliable manager of the game — checks if that player has enough money to buy the item.


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.