Everything Is an Instance in a Tree
The Explorer looks like a list of folders and is really your running game, live, with every object in it. Click down through the tree and watch the path assemble itself exactly as a script would have to write it.
The Explorer looks like a list of folders and is really your running game, live, with every object in it. Click down through the tree and watch the path assemble itself exactly as a script would have to write it.
The Explorer is the game, not a file list
A file browser shows you things that are sitting on a disk. The Explorer shows you things that exist right now, in memory, in the game. Delete a row from it while the game is running and that object is gone from the world in the same frame.
This one idea explains most of Roblox. There is no separate scene format, no build step, and no compile. The tree you are looking at is the game, the whole game, and a script changing it is changing what players can see.
The root of that tree is called game, and Roblox's documentation calls the whole structure the data model. Both names refer to the same thing you are clicking on.
Every object is an instance with a class
Every row in that tree is an Instance. A brick, a script, a sound, a player, a light — all instances, all with a Name you chose and a ClassName you did not.
The distinction matters more than it looks. The name is a label you can change freely and duplicate carelessly. The class is what the object is, and it decides which properties exist on it — a Part has CanCollide, a Script does not, and no amount of renaming changes that.
local laser = workspace.Obby.Laser print(laser.Name) --> Laserprint(laser.ClassName) --> Partprint(laser:IsA("BasePart")) --> trueThat last line is the useful one. IsA asks whether an object is a class or anything descended from it, so a Part answers true to BasePart. Checking with IsA rather than comparing ClassName to a string is what makes a script keep working when somebody swaps a Part for a MeshPart.
local target = game.Workspace.Obby.Laser
local target = workspace.Obby.Laser -- the same object, shorter
target.ClassName → "Part"
Each dot is one step down the tree, and each step is a lookup that can fail. If anything above Laser is renamed, this whole line stops working — which is why the next chapter is about the safer ways to write it.
Parenting is what makes a thing exist
An instance is not in the world because you created it. It is in the world because its Parent points somewhere the world can reach.
local part = Instance.new("Part")part.Size = Vector3.new(8, 1, 8)-- Nothing is visible yet. The part exists, and it is nowhere. part.Parent = workspace-- Now it is in the game.Setting Parent last is a real convention and not a stylistic one. The moment a part enters the workspace, physics and replication begin acting on it, so configuring it first means players never see a half-built object flicker into place.
Services are the branches you never create
Directly under game sit a fixed set of top-level objects called services. You cannot make one, delete one, or have two. Each is a department with a job.
Everything with a physical presence. If a player can see it or bump into it, it is in here.
One Player object per person connected. Not their character — the account behind it.
Server code. Never replicated to any client, so players cannot read what is in it.
A shelf both sides can reach. Shared modules and things you intend to clone live here.
The template for each player: the scripts and gear they get a copy of when they join.
The correct way to reach one from a script is game:GetService("Players") rather than game.Players. Both usually work; only the first still works if the service has not been created yet, which is a real situation in an empty place.
local Players = game:GetService("Players")local ReplicatedStorage = game:GetService("ReplicatedStorage") -- workspace is the one exception: it has its own global, all lowercase.local baseplate = workspace.BaseplateNaming things is load-bearing here
In most languages a variable name is for humans. In Roblox an object's name is how code finds it, which means renaming a part in the Explorer can break a script across the game and produce no warning anywhere.
Worse, names are not unique. Nothing stops you having four parts called Part inside one model, and model.Part will return one of them without telling you there were others. It is not random, but it is not something you should rely on either.
And when a name is simply wrong, a dot lookup does not quietly hand back nothing. It stops the script with an error that names exactly what it could not find and where it looked — which is the next thing to learn to read.
local laser = workspace.Obby.Lazer -- typo--> Lazer is not a valid member of Model "Workspace.Obby"Key takeaways
- The Explorer is the live game, not a file list. Deleting a row deletes the object from the world in that frame.
- Every object is an Instance with a Name you chose and a ClassName you did not. The class decides which properties exist.
- Use :IsA() rather than comparing ClassName, so a script keeps working when a Part becomes a MeshPart.
- An object exists in the world because its Parent points somewhere reachable — not because you created it.
- Configure an instance fully, then set Parent last, so players never see a half-built object appear.
- Parent = nil removes an object but keeps it usable; :Destroy() removes it permanently. Prefer Destroy.
- Services are the fixed top-level branches. Reach them with game:GetService("Name"); workspace is the one with its own global.
- Object names are how code finds things, and they are not unique. Renaming a part can silently break scripts across the game.
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.