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.
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.
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.
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.
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.
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.
|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.|
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.
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.
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.
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.