Table of Contents
Why Roblox Uses Server and Client
In Roblox every running game is split into two sides, the server and the client. The server is the authoritative brain of the whole game. It runs once for the entire server instance and controls shared game state that all players see, such as the map, enemies, coins, and leaderboards. The client runs separately for each player and is focused on what that single player sees and controls, such as their camera, their user interface, and immediate input from their keyboard or controller.
This split is what makes Roblox multiplayer work. Instead of every player arguing about what is true, the server decides what is correct and then tells all the connected clients. Each client presents that information to its player in a smooth and responsive way, while also sending the player’s inputs back to the server.
The server is authoritative over the game world. Clients should never be trusted for important decisions about shared game state or valuable data.
What the Server Controls
The Roblox server is where you should handle anything that affects more than one player, anything related to security, and anything that determines the true state of the world.
The server owns the main Workspace and decides what objects exist, where they are, and which scripts affect them. If a new enemy spawns, if a door opens for everyone, or if a round of a match starts or ends, those changes should come from the server. When the server changes something in Workspace, such as moving a part or destroying a model, all clients see the change replicated to them.
Player-related data that has real value also belongs on the server. This includes coins, experience points, wins, and any other statistics you might put into leaderstats or other data containers. The server tracks the real values and is the only place that decides when these values change.
Combat and damage calculations are another responsibility of the server. If a player attacks an enemy or another player, the server should check whether the hit is allowed and then adjust health. This prevents players from cheating by faking hits or inventing extra damage on their own devices.
Data saving with DataStore services must also run on the server. The server can talk to Roblox web services to save and load progress, while clients cannot do this. Since saving and loading are critical, both for fairness and for avoiding data loss, they must run in server scripts.
Finally, global game rules and systems belong on the server. Game modes, matchmaking logic, round timers, and win conditions should be decided there and then broadcast to clients through replication or remote communication.
What the Client Controls
The client focuses on one thing: the experience of a single player. Since each client only needs to care about its own player’s viewpoint, it can react quickly to input and present smooth visuals, even if there is network delay.
All user interface should be handled on the client side. ScreenGuis, menus, health bars that sit on the screen, and interactive buttons live in PlayerGui, which belongs to each player and is controlled by LocalScripts. The server does not need to draw your UI, it only needs to provide the information that the UI uses.
Camera control is another client responsibility. Moving, rotating, or custom scripting of the camera should happen in LocalScripts so that each player has an independent and responsive view of the game world. Aiming, zooming, or special camera effects are managed near the player, not on the server.
Input from keyboard, mouse, or controller is always captured on the client. LocalScripts listen for key presses, mouse clicks, and touch events. These scripts decide which inputs matter to the game and then send the important ones to the server when necessary, such as when firing a weapon or requesting to buy something.
Visual effects that do not affect gameplay can often be client sided. For example, local particle effects, camera shakes, and screen flashes can be created by LocalScripts. The server does not need to track purely cosmetic effects, as long as they do not change shared game state. This keeps the server lighter and improves performance.
Finally, some prediction or smoothing can occur on the client. For example, a LocalScript might start an animation as soon as the player clicks, then tell the server that an attack was attempted. The server confirms whether the attack really happens. The client can hide some of the delay by responding immediately with visual feedback.
How Server and Client Communicate
The server and clients are separated for security and performance, so they cannot just call each other’s functions directly. Instead, they use RemoteEvents and RemoteFunctions to communicate. These are special objects that work across the network.
When the client needs something from the server, it typically fires a RemoteEvent. For example, a LocalScript in a weapon might fire FireWeaponEvent:FireServer() with some information about the shot. The server listens for this event in a Script and decides whether to apply damage, spawn projectiles, or update stats.
When the server wants to tell clients about something, it can fire a RemoteEvent to one client or to all clients. It might broadcast that a round has started, inform everyone that a boss has spawned, or send updated score information so UI can reflect the change. Each client listens in a LocalScript and updates visuals or interface elements.
RemoteFunctions work in a similar way, but they allow the caller to wait for a returned value. For example, a client could ask the server for a list of items the player owns and wait for the server to send back that data. These should be used carefully, since waiting for network responses can cause delays if overused.
It is essential to design the communication carefully. The client should send intent, such as “I want to attack this enemy” or “I clicked buy on this item,” but should not tell the server final results like “I already did 100 damage.” The server receives the intent, checks it, and then decides the true outcome.
Deciding What Runs Where
A useful way to decide where code should run is to ask whether something affects only one player’s view or affects the actual shared game state. If it only changes what a single player sees or how they control their character, then it often belongs on the client. If it changes the world or any shared information, then it generally belongs on the server.
User interface logic, camera changes, and instant reaction to input are almost always done in LocalScripts. For example, a button click that opens a menu can be entirely client side, since it does not change anything for other players.
Game rules, fairness, and persistence belong on the server. Giving currency, applying damage, spawning or destroying shared objects, and determining winners should be performed in server Scripts. The server also guards the game against cheating by ignoring client requests that do not make sense.
Some features involve both sides. A shop system, for instance, might show a menu and item previews on the client, let the player choose an item, then send a purchase request to the server. The server validates the purchase and changes the player’s currency and inventory. Then it informs the client that the purchase succeeded so the UI can update.
By keeping this separation clear, your game stays consistent, resistant to exploits, and smoother for each player. Server and client are partners, but they have different jobs. Designing your systems with that in mind is a core skill for robust multiplayer game mechanics.