Client-Server Model

Roblox experiences run on the client-server model, a common framework for multiplayer experiences. Whenever a player joins a Roblox experience, their personal computer, phone, tablet, or console becomes a new client. All clients in the experience are connected to a powerful Roblox server which is the ultimate authority for maintaining the experience's state, constantly updating its connected clients through replication.

Server with connections to three client devices
Server with connections to three client devices

Data Model

In Studio, the objects you see in the Explorer window represent the data model — the root of Roblox's parent-child hierarchy — containing services and classes such as Workspace and Lighting that act as the fundamental components of a Roblox experience.

Data model in Explorer window

When you play/run an experience, the Roblox engine and various core scripts map contents of the "edit" data model to a "runtime" data model. Each client that connects to the experience is added to the Players service under their Roblox username, and the contents of containers such as StarterGui and StarterPack are cloned to that player's PlayerGui and Backpack, respectively.

Mapping of objects between 'edit' and 'runtime' data models

Client and Server Tasks

Roblox executes code through client-side LocalScripts, server-side Scripts, and ModuleScripts which let you reuse code and share functionality. The following sections outline typical client and server tasks.

Client-side tasks relate specifically to the player's computer, phone, tablet, or console, for example:

  • Detecting user input, as input comes directly from the client in the form of a screen tap/touch, button/key press, or mouse interaction.
  • Anything related to user interface since it applies to what the player sees on their screen.
  • Manipulating the in-experience Camera since it's specific to the client.
  • Handling "superficial" visuals like flickering lights or gem/coin/pickup effects that don't affect gameplay and don't need to be replicated from the server to every client.

Clients can also communicate with the server through remote events and functions. This is typically required when you need to send the server a specific command, or send a specific command from the server to one or more clients.

Object Organization

Proper, intentional object placement is essential to every experience on Roblox. Specific containers in the Explorer hierarchy accommodate client-side purposes and/or server-side purposes, while nested scripts provide custom functionality for portable, reusable objects.

Object Containers

The following services and storage containers each serve a specific purpose for object placement. In the context of scripts, their placement determines whether they run on the client or the server, and when they execute.

Container Description
Workspace The contents of Workspace load immediately into the 3D world around the player's streaming radius. You can organize entire hierarchies of related objects into Folders, or even swap entire maps in/out between Workspace and ServerStorage as needed.
ReplicatedFirst At runtime, the contents of ReplicatedFirst replicate to each client before anything else, making it ideal for custom loading screens. Avoid using this container for anything that does not need prioritized replication; instead use ReplicatedStorage.
ReplicatedStorage Objects in ReplicatedStorage replicate to all connected clients. This container is ideal for ModuleScripts, RemoteEvents, RemoteFunctions, and other objects which need to be accessible to client-side and server-side scripts. Note, however, that ServerStorage is a more appropriate container for objects which only the server needs to access.
ServerScriptService ServerScriptService is a container service for Script, ModuleScript and other script-related assets that are only meant for server use. The contents are never replicated to player clients, making it ideal for secure storage of important logic.
ServerStorage Contents of ServerStorage are only accessible on the server and are never replicated to player clients. This container is convenient for storing in-experience objects until they're required, such as treasures that drop from a defeated enemy, at which time you can Clone() them and parent them to the workspace.
StarterGui The StarterGui container is designed to hold GUI objects such as ScreenGuis. When a player's character spawns, children of this container are copied (along with their descendants) into Players/[UserName]/PlayerGui.
StarterPack Contents of the StarterPack container are copied into Players/[UserName]/Backpack when their character spawns. It's generally used to hold tools.
StarterPlayer When a client connects to the server, each property of StarterPlayer is copied to Players/[UserName]. Additionally, each descendant script of StarterCharacterScripts is cloned to Workspace/[UserName] when the player's character spawns, and each descendant script of StarterPlayerScripts is cloned to Players/[UserName]/PlayerScripts, at which point the cloned scripts run.

Nested Scripts

Alternative to script containers, you can nest scripts inside other instances like Models to form portable and reusable objects with specific functionality, such as a zombie NPC which wanders around aimlessly.

Nested scripts inside an NPC model

Script Communication

Remote Events/Functions

Servers handle replication automatically, but sometimes you'll need to send the server a specific command from the client, or send a specific command from the server to one or more clients. In such scenarios, remote events and functions allow Scripts and LocalScripts to communicate with each other in the following patterns.

ClientServer

Diagram of one client communicating with the server

Communication from any client to the server. For example, a player (client) presses the P key to drink an invisibility potion, then a RemoteEvent tells the server to make that player's character invisible to all other players.

ServerClient

Diagram of the server communicating with one client

Communication from the server to one specific client. For example, a player joins the experience and the server dispatches a RemoteEvent to all of their friends on the same server, displaying an on-screen notification for each.

ServerAll Clients

Diagram of the server communicating with all connected clients

Communication between the server and all connected clients. For example, before a race begins, a sequence of timed remote events (3… 2… 1… GO!) are sent to display a countdown timer to all participants.

Bindable Events/Functions

When you only need to communicate between scripts on the same "side" of the client-server boundary, for example one LocalScript to another LocalScript, you can bind code to custom behavior through bindable events and functions.

Network Ownership

For moving, physically-simulated assemblies, the Roblox engine utilizes network ownership, allocating physical simulation to either the server or a nearby client. For instance, a player's character may take "ownership" of a vehicle by sitting in the driver's seat, but when that character exits the vehicle, the server regains ownership until another character sits in the seat. Ownership typically happens automatically, but you can assign it directly for fine-tuned responsiveness.