Two Computers, One Experience
Your obby runs on Roblox's server and on every player's own machine at once, and by default they disagree. Move a part from a LocalScript, watch it move for exactly one person, and see why a killbrick cannot live there.
Read first: Where Code Goes, and Where It Runs
Your obby runs on Roblox's server and on every player's own machine at once, and by default they disagree. Move a part from a LocalScript, watch it move for exactly one person, and see why a killbrick cannot live there.
The server is the copy everybody shares
When six people join your obby, there are seven copies of it running. One on Roblox's server, and one on each player's computer. The server's copy is the real one; each player's copy is a local mirror that exists so the game can draw a frame without asking the server about every brick first.
Everything confusing about Roblox scripting comes from this. Not because it is complicated — because a script never says which copy it is running on, and looks identical either way.
A LocalScript runs on one machine only
A Script runs once, on the server. A LocalScript runs once per player, on that player's machine, and it can only see that player's copy of the world.
So a LocalScript that turns the laser green turns it green for the person running it and for absolutely nobody else. Everyone else keeps seeing red. Neither player can tell anything is wrong, and no error is produced.
-- In a LocalScript. Runs on one machine.workspace.Obby.Laser.BrickColor = BrickColor.new("Lime green") -- That player now sees a green laser.-- Every other player still sees red. The server still says red.Replication flows one way by default
The rule is short and worth memorising exactly.
- 1
Server changes something
It replicates to every client automatically. This is why a server script moving a platform moves it for everyone.
- 2
Client changes something
It stays on that client. Nothing is sent to the server, and nothing reaches the other players.
- 3
Client wants the server to act
It must ask, through a RemoteEvent. The server receives the request and decides whether to honour it.
That third step is where a lot of Roblox architecture lives, and an obby barely needs it — almost everything you build in this track happens on the server, which is one reason an obby is a good first project.
The word to be careful with is "asks". A RemoteEvent is a request from a machine the player controls, so a server that does whatever a RemoteEvent tells it is exactly as exploitable as having no server at all.
Why the killbrick has to be a server Script
Put the killbrick logic in a LocalScript and it will appear to work. You will touch the laser, you will die, and you will conclude it is finished.
It is not. You died on your own machine, and the server was never told. To the server and to every other player you are alive and standing in the laser. Worse, the player owns the machine that decided this, so anyone who wants to can simply not run it.
Server Script
Damage, checkpoints, scoring, spawning, anything that persists. One copy, authoritative, and out of reach of the player.
LocalScript
Camera, input, interface, and effects only that player should see. Assume anything here can be read, changed, or switched off by the person running it.
Test the split before you trust it
Studio can run both sides at once, and this is the feature that turns the client and server split from an abstraction into something you can see.
- 1Test tab → Players → set to 2
Then press Start. Studio opens one server window and two client windows.
- 2Watch the Explorer in each
The server window and each client window show their own copy of the tree. Change something in one and see what the others do.
- 3Use the Client/Server toggle
In the single-player Play mode, this switches which side the command bar and Output are talking to. Most 'my script did nothing' reports are the wrong side being selected.
Two players is also the minimum to catch the class of bug the rest of this track keeps returning to. A killbrick with a single shared debounce, and a one-way platform with a single shared CanCollide, are both perfect with one player and broken with two.
Key takeaways
- Six players means seven running copies of the game: one server, six clients. The server's copy is the real one.
- A Script runs once on the server. A LocalScript runs once per player, on that player's machine.
- A client change stays on that client. Nobody else sees it, and no error tells you so.
- A server change replicates to every client automatically. That is why gameplay logic belongs on the server.
- A client can only ask the server to act, through a RemoteEvent — and the server must treat every such request as untrusted.
- A killbrick in a LocalScript appears to work and is not real: the server never learns you died, and the player can switch it off.
- Anything that persists or affects others goes on the server. Camera, input, and one-player effects go on the client.
- Test with two players. A single shared debounce or a single shared CanCollide is flawless alone and broken in company.
Before you move on
Quick check
Answer these to unlock the next chapter: 3 of 4 to pass. You can retake it anytime.
Make a free account to read on
Every chapter is free — an account lets your course progress follow you from your laptop to your phone. No payment, no trial.