How to script in Roblox Studio: a beginner's guide

Before you start: Studio, a Baseplate and the Output window

You need Roblox Studio and a Roblox account, and nothing else: no code editor and no plugin. Every script in this guide is typed into Studio's own Script Editor.

1. Install Roblox Studio, Roblox's free app for Windows and Mac, and sign in with your Roblox account.
2. Open Studio. Its start page lists templates: pick Baseplate. You get a floor with a 4x4 grid texture and a SpawnLocation, the spot where your avatar appears when you play.
3. If the Explorer and Properties windows are not showing, open them from the Window menu or the Home tab. The Explorer lists every object in your place; Properties shows the settings of whatever you select.
4. Open Output from the Window menu or the Script tab. This is where your scripts' messages and errors appear.
5. In the Output window's display options, turn on Show Context, which labels each message Client or Server, and Show Source, which shows the script and line number that produced it.

Workspace
  Baseplate Part
  SpawnLocation SpawnLocation
  Part Part new
    ColourChanger Script new
  Pad Part new
    TouchPad Script new
ServerScriptService
  FirstScript Script new
StarterPlayer
  StarterPlayerScripts
    MyFirstLocalScript LocalScript new

Step 1: Write your first script

1. In the Explorer, hover over ServerScriptService, click the + button and pick Script (the shortcut is Ctrl+I, or ⌘I on Mac). Studio creates the script and opens it in the Script Editor.
2. Right-click the new script, choose Rename and name it FirstScript. The name does not change what the script does, but it tells you which script printed what.
3. New scripts start with one line, print("Hello world!"). Delete it and paste in the code below.
4. Press Play (F5), with Test chosen in the dropdown to its left. Studio starts a playtest and puts your avatar at the SpawnLocation.
5. Read the lines in Output, then press Stop (Shift+F5). Stop also puts every object back the way it was before you pressed Play, so anything you moved or recoloured while playing goes back.

-- Script in ServerScriptService named FirstScript.
-- Your first Luau: variables, a function, an if statement, a loop and a table.
-- Press Play (F5) and read the results in the Output window.

-- A variable is a name that holds a value
local gameName = "Coin Run"
local coinsToWin = 3

-- A function is a named block of code you can run as often as you like.
-- name and goal are its parameters; return hands a value back to the caller.
local function describe(name: string, goal: number): string
	return `{name}: collect {goal} coins to win`
end

print(describe(gameName, coinsToWin)) --> Coin Run: collect 3 coins to win

-- An if statement runs code only when its condition is true
if coinsToWin > 5 then
	print("That is a long game")
elseif coinsToWin > 1 then
	print("That is a short game")
else
	print("One coin and you win")
end

-- A for loop repeats code a set number of times
for count = 1, coinsToWin do
	print("Coin number", count)
end

-- A table holds a list of values; this loop visits each one in order
local colours = { "Red", "Green", "Blue" }
for position, colour in colours do
	print(position, colour) --> 1 Red, then 2 Green, then 3 Blue
end

Output should show these eight lines, mixed in with any messages from Studio itself. When print gets more than one value, it puts a space between them. With Show Context and Show Source on, each line is also labelled Server and FirstScript with a line number.

Coin Run: collect 3 coins to win
That is a short game
Coin number 1
Coin number 2
Coin number 3
1 Red
2 Green
3 Blue

Match each line to the code that printed it. You will do the same with error messages later, so it is worth the habit now.

Every block that opens with function, if, for or while closes with end. One missing end stops the whole script from running; reading errors shows the message you get.

Step 2: Change a part from a script

Scripts become useful when they change things in the world. The settings you see in the Properties window, such as a part's Color, Transparency or Anchored, are properties, and a script can set them too.

1. On the Home tab, click Part. Studio adds a block to the Workspace. Its name does not matter.
2. In the Explorer, hover over the new part, click + and insert a Script. Rename it ColourChanger and replace its contents with the code below.
3. Press Play. The part turns red, then blue, then green, changing once a second, and starts again.

-- Script inside a Part in Workspace, named ColourChanger.
-- Scripts change the same properties you see in the Properties window.
-- This one gives its part a new colour every second, for every player.

local part = script.Parent :: BasePart -- the part this script sits inside

local colours = {
	Color3.fromRGB(255, 85, 85), -- red
	Color3.fromRGB(85, 170, 255), -- blue
	Color3.fromRGB(85, 255, 127), -- green
}

part.Anchored = true -- an anchored part stays where you put it

local index = 1
while true do
	part.Color = colours[index]
	index = index % #colours + 1 -- 1, 2, 3, then back to 1
	task.wait(1) -- pause for one second (the old wait() is deprecated)
end

• script.Parent is the object the script sits inside, here the part. Drag the script into another part and it changes that part instead.
• :: BasePart is a type cast. It tells the Script Editor that the parent is a part, so it can check the properties you use on it. Luau uses types only for warnings and suggestions, so the cast does not change what the line does.
• part.Color and part.Anchored are the same properties you see in the Properties window, with the same names. Roblox uses American spelling, so the property is Color even though this script is called ColourChanger.
• Anchored = true keeps the part still: Roblox's reference says an anchored part never moves because of gravity, collisions or any other physics.
• colours[index] reads one item from the list. #colours is the length of the list, 3, and % gives the remainder after dividing, so index % #colours + 1 counts 1, 2, 3, 1, 2, 3.
• while true do repeats forever, which is why the task.wait(1) inside it matters. Roblox's docs say to always put a delay such as task.wait() in an infinite loop: without one, the game freezes and Studio crashes.

ColourChanger is a Script, so it runs on the server, and every player in the game sees the same colour at the same time. Step 4 shows the other kind of script.

Step 3: React to a player with an event

Most game code waits for something to happen: a player joins, a part is touched, a button is clicked. Roblox calls these events. To run code when one fires, you connect a function to it.

1. Insert another Part and rename it exactly Pad, with a capital P. Leave it directly in the Workspace, not inside a folder or a model, because the LocalScript in Step 4 looks for it there.
2. Make it a flat pad you can walk onto, for example by setting its Size to 6, 1, 6 in the Properties window. Move it onto the floor near the SpawnLocation and tick Anchored so it stays put.
3. Hover over Pad, click +, insert a Script, rename it TouchPad and paste in the code below.
4. Press Play and walk onto the pad. It turns yellow for 2 seconds, and Output names you.

-- Script inside a Part in Workspace named Pad, script named TouchPad.
-- Events: when a player steps on the pad, it glows yellow and Output says who it was.
-- A debounce stops it running many times a second while they stand on it.

local Players = game:GetService("Players")

local pad = script.Parent :: BasePart
local COOLDOWN_SECONDS = 2

local normalColour = pad.Color
local busy = false

local function onTouched(otherPart: BasePart)
	if busy then
		return -- still cooling down from the last touch
	end
	-- The character is the Model that holds the body part (or hat) that touched the pad
	local character = otherPart:FindFirstAncestorOfClass("Model")
	local player = character and Players:GetPlayerFromCharacter(character)
	if not player then
		return -- a loose part or an NPC touched it, not a player
	end

	busy = true
	print(`{player.Name} stepped on the pad`)
	pad.Color = Color3.fromRGB(255, 220, 0)
	task.wait(COOLDOWN_SECONDS)
	pad.Color = normalColour
	busy = false
end

pad.Touched:Connect(onTouched)

Why the pad needs a debounce

Roblox's debounce page warns that Touched "fires multiple times in quick succession" as parts make contact, and a walking character has several body parts. Without a check, one step onto the pad could print many lines and restart the yellow glow again and again.

The busy variable is the debounce. The first touch sets it to true, and every touch during the next 2 seconds reaches if busy then return end and stops. After task.wait(COOLDOWN_SECONDS) the pad changes back and busy returns to false. COOLDOWN_SECONDS is written in capitals because it is a setting that does not change while the game runs, the naming Roblox suggests for constants.

This pad has one debounce for everyone, so a second player who steps on within those 2 seconds is ignored. That is fine for a pad that glows. A pad that gives rewards should keep a cooldown for each player instead, as the coin pad in the leaderboard guide does.

Step 4: Your first LocalScript, and why it is different

A running game is one server plus one client for each player. Everything so far was a Script, which runs on the server, so its changes reach every player. A LocalScript runs on one player's device instead. Key presses, the camera and on-screen menus are handled there, because only that device knows about them.

1. In the Explorer, expand StarterPlayer, hover over StarterPlayerScripts, click + and insert a LocalScript. Rename it MyFirstLocalScript and paste in the code below.
2. Press Play. Output shows Hello, and your name, labelled Client.
3. Click into the game view and press E. The pad fades. Press E again to bring it back.
4. While the playtest is still running, click the Client/Server toggle in Studio's testing controls to switch to the server's copy of the game. The pad is solid there: the server never heard about the change.

-- LocalScript in StarterPlayer > StarterPlayerScripts named MyFirstLocalScript.
-- A LocalScript runs on one player's own device. Press E: the Pad fades on your
-- screen only, because a change to a part made here does not reach the server or anyone else.

local Players = game:GetService("Players")
local UserInputService = game:GetService("UserInputService")

local player = Players.LocalPlayer
print(`Hello, {player.Name}`) -- shows in Output, marked as Client

UserInputService.InputBegan:Connect(function(input: InputObject, gameProcessed: boolean)
	if gameProcessed then
		return -- the key was used for something else, such as typing in chat
	end
	if input.KeyCode == Enum.KeyCode.E then
		local pad = workspace:FindFirstChild("Pad")
		if pad and pad:IsA("BasePart") then
			pad.Transparency = if pad.Transparency == 0 then 0.6 else 0
		end
	end
end)

• Players.LocalPlayer is the player whose device is running the script. Roblox defines it only for LocalScripts and the ModuleScripts they require, so server code cannot use it.
• UserInputService.InputBegan fires when the player starts a key press, a click or a touch. gameProcessed is true when the engine has already used that input, for example a click on a button or a key typed into the chat bar, so the script ignores it.
• workspace:FindFirstChild("Pad") returns the child named Pad, or nil if there is none. pad:IsA("BasePart") checks that it really is a part before the script changes its Transparency.
• if pad.Transparency == 0 then 0.6 else 0 is an if-expression: it picks one of two values. A Transparency of 0 is fully visible and 1 is invisible.

What a cheater can change

Assume a cheater controls everything on their own device. They can run their own LocalScripts and change yours, so they can fade the pad, or anything else, on their own screen. Here that is harmless: the fade is only for show and stays on their device. It is also the reason anything that matters is decided by a Script on the server.

A server Script is not automatically safe either. TouchPad runs on the server, but each player's device controls the physics of its own character, and Roblox's security docs list manipulating when Touched fires, or stopping it firing at all, among the things a client can do with the parts it controls. For a pad that glows, that does not matter. For a pad that pays out, also check something the server keeps track of itself, like the obby guide's rule that checkpoints only count in order.

Step 5: Test all four scripts together

1. Clear Output with Ctrl+K (⌘K on Mac) and press Play (F5). Output shows FirstScript's eight lines labelled Server, and your Hello line labelled Client. The ColourChanger part changes colour every second.
2. Walk onto the pad. It turns yellow for 2 seconds and Output shows your name and "stepped on the pad" once. Keep walking around on it: a new line appears at most once every 2 seconds, not every time Touched fires.
3. Press E. The pad fades to a Transparency of 0.6. Press E again and it is solid.
4. Press Stop. In the testing dropdown choose Server & Clients, set 2 clients and press Play (or F7). Studio opens a server window and two client windows. In one client, press E: the pad fades there, while the other client and the server still show it solid. Press End Session when you are done.
5. Break something on purpose. Rename Pad to Pad2 and play. Walking onto it still turns it yellow, because TouchPad finds its part with script.Parent, not by name. Pressing E now does nothing, and there is no error: FindFirstChild("Pad") returned nil, and the if pad and ... check quietly skipped the rest. Add print(pad) on the line after FindFirstChild, play and press E: Output shows nil. A print like that is the quickest way to find out why a script does nothing. Stop, delete the print line and rename the part back to Pad.

Where scripts go

Where a script sits decides whether it runs at all, and Studio does not warn you when it never will. For the scripts you will write next:

Roblox's script locations page recommends not putting scripts directly inside parts in Workspace at all: tag the parts instead and work with them from a single ModuleScript using CollectionService. A script inside a part is still the easiest way to start, and it is fine for one or two objects while you learn. The door guide shows the tagged pattern, with one script for every door, and the client and server guide has the full table of which containers run which scripts.

When something goes wrong: read the Output

Errors show in Output in red. Each one starts with where it happened, the script's full name and the line number, and then says what went wrong. Click the error and Studio opens that script at that line. For example, if you deleted the if not player check from TouchPad and a loose part landed on the pad, Output would show:

Workspace.Pad.TouchPad:22: attempt to index nil with 'Name'

Mistakes in how the code is written, such as a missing end, show up before you press Play: the Script Editor underlines them in red, and the Script Analysis window (the Analysis button on the Script tab) lists them. A script with one of these mistakes does not run at all, not even the lines above it.

When a script does nothing and Output shows nothing either, it is usually somewhere it never runs, or waiting for an event that never fires. The script errors guide has a checklist for silent scripts, and goes deeper into reading Output.

What older scripting tutorials do differently

If you also learn from videos and forum posts, you will meet older patterns. These are the ones that matter, with the reason each one is a problem.

Practice: three changes to try

Changing code teaches more than reading it. Try these in your own place, one at a time, and press Play after each.

• Make the pad give a point. Add the Leaderstats script from Step 1 of the leaderboard guide. Then in TouchPad, after busy = true, find the player's leaderstats folder and add 1 to its Coins value. Hint: player:FindFirstChild("leaderstats"), then leaderstats:FindFirstChild("Coins"), then coins.Value += 1. The leaderboard guide's coin pad is a finished version, with a cooldown for each player.
• Fade the colour changer too. Make ColourChanger change the part's Transparency every second as well. Hint: add a second table of numbers between 0 and 1, such as { 0, 0.3, 0.6 }, and set part.Transparency from it on the line after part.Color, using the same index.
• Print the pad's colour. Make MyFirstLocalScript print the pad's Color when you press E. Hint: print(pad.Color) inside the if pad and pad:IsA("BasePart") block. Press E while the pad is yellow: the client sees the colour the server set, because changes made on the server reach every client.

What to learn next

You have now used the pieces most game scripts are built from. A good order for what comes next:

1. LocalScript vs Script vs ModuleScript: where each script type runs and what it can change, in more depth than Step 4.
2. RemoteEvents: how a LocalScript asks the server to do something, and how the server checks the request.
3. A leaderboard: your first stats, created and changed on the server.
4. Your first game: a short coin course with lava, coins and a finish pad, run by two server scripts, then published.
5. Then pick a system to add: a shop GUI, a round system or obby checkpoints. When something breaks, the script errors guide helps you read the message.

Roblox's own Coding fundamentals tutorials make a good companion: six series that go from variables and functions through conditionals, loops, and arrays and dictionaries to organising code with ModuleScripts, with small projects to build in Studio.

Common errors and fixes

Most first-script problems are a name that does not match, a script in the wrong place, or a loop with no wait. Keep Output open while you test.

Getting unstuck with RoCode

If you get stuck on a script in your own place, RoCode can read it with you. RoCode is an independent AI agent for Roblox Studio, not made by Roblox: you type in a web chat, and its Studio plugin creates and edits the scripts in your Explorer.

While you are learning, Ask mode is the useful one: you still write the scripts, and RoCode reads what is already there and answers your questions about it.

In Build mode with plugin 3.9 or newer, RoCode can run a short playtest and read the errors, but it does not move a character or take screenshots, so you still walk onto the pad yourself. How RoCode connects to Studio.

Questions

Sources and further reading

• Roblox Creator Docs: Luau. what Luau is and where it comes from
• Roblox Creator Docs: Roblox Studio setup. Windows and Mac, and the system requirements
• Roblox Creator Docs: Output. opening Output, filters, Show Context and Show Source
• Roblox Creator Docs: Studio testing modes. Play, Run, Stop, the Client/Server toggle and Server & Clients
• Roblox Creator Docs: Script Editor. where new scripts open, and Script Analysis
• Roblox Creator Docs: Script types and locations. where each script type runs, and tagging parts instead of putting scripts in them
• Roblox Creator Docs: Script. when a Script starts running
• Roblox Creator Docs: Control structures. if statements, loops, and why an infinite loop needs a wait
• Roblox Creator Docs: Events. Connect, and what Touched passes to your function
• Roblox Creator Docs: Debounce patterns. why Touched fires several times for one contact
• Roblox Creator Docs: wait. the global wait() and task.wait()
• Roblox Creator Docs: Network ownership, movement validation and physics exploits. what a client can do with its own character
• Roblox Creator Docs: Coding fundamentals. Roblox's own beginner series

How the code was checked: every script on this page passes Luau's strict type checker against Roblox's API definitions (luau-lsp, 15 October 2026). A type check catches misspelt APIs and wrong types, not game logic, so playtest in Studio before you publish.