Module 1 · Your first Luau scripts
Script, LocalScript, and ModuleScript
Preview server scripts, player-device scripts, and reusable modules without introducing networking yet.
What you will learn
- Describe the introductory role of each script class
- Choose a sensible location for a server Script
- Script
- Code intended to run on the Roblox server.
- LocalScript
- Code intended to run for one player's client.
- ModuleScript
- Reusable code that returns a value for another script to require.
Loading saved progress…
Understand
Read the idea and follow a worked example.
Why this matters
Coin rewards must eventually be controlled by the server, while a player's HUD belongs on that player's device. Picking the right script type keeps those responsibilities clear.
The mental model
In this course, a Script in ServerScriptService handles shared game behavior on the server. A LocalScript in a supported client location handles one player's input or visuals. A ModuleScript packages code that another script starts by calling require.
The word server inside the example is only a string label. Changing it to client does not turn a Script into a LocalScript; the actual object class, location, and run context determine execution.
This is a preview. For the early exercises, use a Script in ServerScriptService with its default run context. Networking and reusable modules arrive later.
New words and symbols
--!strict asks Studio to check your code for type mistakes. It is an instruction for the editor and produces no Output message.
Matching quotes such as "hello" surround a string: a piece of text. The quotation marks tell Luau where the text starts and ends.
print(...) calls the built-in print function. Put the values to show inside its parentheses; separate multiple values with commas. Read the result in Studio's Output panel.
local is read as “local”: it creates a name that is available only in the current code scope.
= is read as “is assigned”: it evaluates the right side and stores that value in the name on the left.
A tiny example
--!strictlocal scriptKind = "server"print(scriptKind)Line by line
- 3
This local value describes the current script's role.
- 4
The server Script reports its role to Output.
Read the code aloud
Read one statement at a time: name the value being read, what the operation does, and where its result goes. Keep identifiers exactly as written so you can find them again in the code.
Pause at calls, conditions, and loops. Explain when the body runs before moving to the next statement; use the line notes above when a symbol is unfamiliar.
Execution trace
Begin at the first executable statement. Comments and blank lines do not run; a branch chooses which block runs, and a loop may revisit its body.
Line 3: This local value describes the current script's role.
Line 4: The server Script reports its role to Output.
State before and after
Before running, identify the starting values and any existing Studio objects this example needs. List what you expect to change.
After your practice change, check this result: The Script runs during Play and the unused ModuleScript does not run on its own.
Reading or printing a value leaves it unchanged. Look for assignments, calls that change state, and property updates to explain each change you observe.
Predict before running
Where should this shared game-start message run?
Try it
Mark each step after you have tried it.
Common mistake
A ModuleScript is not a background worker. It returns an API when another script calls require; placing print code in one and expecting automatic output builds the wrong mental model.
Checkpoint
Submit once you have considered every question. Retries are unlimited.
Recap
- Scripts run server behavior.
- LocalScripts run supported client behavior.
- ModuleScripts return reusable APIs when required.
Next: Next, you will use print as a small feedback loop while writing code.
Studio Companion
Not connected
Connect once. Compatible challenges will prepare automatically as you reach them.