Table of Contents
Understanding the Workspace in Roblox
The Workspace is the central 3D world of your Roblox game. It is the place where all visible and physical objects exist during gameplay. When a player joins your game, what they see around them comes from the contents of Workspace.
You will use the Workspace constantly when scripting in Roblox, so learning how it behaves is essential before you build more complex systems.
Where Workspace Lives in the Game Hierarchy
Every Roblox game has a special hierarchy of services at the top level, which you can see in the Explorer window. One of these services is called Workspace.
In the Explorer, you will find it as a top level item named Workspace. Everything that exists in the 3D world during the game is either in Workspace or is a descendant of something in Workspace. When you insert a new Part from the menu, it is usually created as a child of Workspace by default.
From Lua code, you can access it through the global workspace variable, or through the more explicit game.Workspace. Both point to the same service.
Important rule: workspace and game.Workspace refer to the same object. Use one style consistently in your scripts to keep your code clear.
What Belongs in the Workspace
Objects that have a physical presence belong in Workspace. These are objects that have a position, can collide, or can be seen in the 3D view. Examples include Part, Model, MeshPart, SpawnLocation, and many other 3D objects.
If an object should be part of the actual game world that players can touch, stand on, or see around them, it will usually be placed somewhere under Workspace. If you group multiple parts into a Model, that Model will typically also be in Workspace.
On the other hand, some objects are not physical. User interface elements, such as ScreenGui and TextLabel, never go into Workspace. They belong in places like StarterGui or directly in the player’s PlayerGui. Services like Lighting, ReplicatedStorage, and ServerScriptService stay at the top level and do not become children of Workspace.
Accessing Workspace in Scripts
When you script behavior for objects in the world, you frequently start by finding them in Workspace. Lua code can get references to items inside Workspace in several simple ways.
A basic access looks like this.
local workspaceService = workspace
local world = game.Workspace
Both lines refer to the same object. To access a child of Workspace by name, you can write something like this.
local myPart = workspace.MyPart
This assumes there is a child of Workspace named MyPart. If the object is inside a Model, you can chain names together.
local house = workspace.HouseModel
local door = house.Door
If you are not sure that an object exists, or its name might change, you can use FindFirstChild to avoid runtime errors.
local part = workspace:FindFirstChild("SecretPart")
if part then
part.Transparency = 0.5
endThis pattern is common when you are working with objects that might be created later or can be removed during play.
Important rule: Direct access like workspace.PartName will cause an error if the object does not exist, but workspace:FindFirstChild("PartName") will safely return nil instead of crashing your script.
Creating and Parenting Objects into Workspace
When you make new parts with Lua, they do not appear in the world until you give them a parent. To show them in the 3D world, you set their Parent to Workspace or to a descendant of Workspace.
An example of creating a new part looks like this.
local part = Instance.new("Part")
part.Size = Vector3.new(4, 1, 4)
part.Position = Vector3.new(0, 5, 0)
part.Parent = workspace
As soon as you assign part.Parent = workspace, the part becomes part of the world and appears in the 3D environment. If you want to organize your world, you can parent new objects into a Model or Folder that is already inside Workspace.
local folder = Instance.new("Folder")
folder.Name = "Obstacles"
folder.Parent = workspace
local obstacle = Instance.new("Part")
obstacle.Name = "Spike"
obstacle.Parent = folderThis pattern keeps your Explorer organized, which becomes very helpful as your game grows.
Finding and Organizing Objects in Workspace
Workspace can quickly become crowded. Good organization makes scripting easier and reduces mistakes. One simple way to organize is to use Folder and Model objects as containers.
For example, you might create one folder for all checkpoints and another for all platforms. Script access then becomes more readable.
local checkpointsFolder = workspace.Checkpoints
local firstCheckpoint = checkpointsFolder:FindFirstChild("Checkpoint1")
You can also search for objects by type or name pattern using methods like GetChildren and GetDescendants.
local allChildren = workspace:GetChildren()
for _, child in ipairs(allChildren) do
print(child.Name)
end
GetChildren returns the direct children of Workspace, while GetDescendants returns every object inside Workspace at any depth. For a large game world, using these methods wisely helps you find and manage many objects at once.
Important rule: Use folders and models to group related items in Workspace. This keeps your Explorer readable and reduces errors when accessing objects by name in scripts.
Workspace and the Game World during Play
Workspace represents the live state of your game world. When the game starts, objects are copied from various services into Workspace and then can change during play.
If you move or delete a part in Workspace during the game, those changes affect all players in that server. For example, if a script destroys a bridge part in Workspace, every player in the same server will see the bridge disappear.
This is different from objects stored in places like ReplicatedStorage, which usually hold templates or assets that you clone, or ServerStorage, which holds items that are not visible in the world. When you want something to be visible and physically present, it must end up somewhere under Workspace.
Basic Physics and Workspace
Roblox physics, such as gravity and collisions, act on physical objects inside Workspace. Any BasePart that is not anchored and is inside Workspace will fall due to gravity and can bounce, roll, or collide with other objects.
If a part is not inside Workspace, physics does not affect it, because it is not part of the live world. For example, a part stored only in ReplicatedStorage will not fall or collide until you clone it and parent the clone into Workspace.
Scripts often use this behavior to spawn items or temporary obstacles. You might keep a template in a storage service, then clone it and put the clone into Workspace to make it active in the world.
Changing Workspace Properties in Scripts
The Workspace object itself has properties that influence the whole world. Two common examples are gravity and current camera settings.
To change gravity, you can alter the Gravity property.
workspace.Gravity = 50
This changes how fast objects fall for the entire world. You can also adjust how the camera works by altering properties or by setting the CurrentCamera, but the full details of camera control are a more advanced topic.
You can read properties from Workspace in the same way.
local currentGravity = workspace.Gravity
print("Gravity is:", currentGravity)
Remember that changes to Workspace properties usually affect every player in that server, not just a single client, unless they are properties that are intentionally controlled per player, such as some camera behaviors handled by local scripts.
Important rule: Changing workspace properties like Gravity affects the entire game world for all players in that server.
Naming and Referencing Best Practices
Because so much of your game lives in Workspace, clear naming is important. Choose names that describe an object’s role, such as StartPlatform, LavaBlock, or Checkpoint1, instead of vague names like Part or Model.
Scripts that reference workspace.Part will break if someone renames or deletes that part. To reduce problems, try to:
Use descriptive names for important parts and models. Group related items into folders or models and reference the group first. Use FindFirstChild when you are not sure that an object always exists.
A short example of a clear structure might look like this.
local stageFolder = workspace:WaitForChild("Stage1")
local lava = stageFolder:WaitForChild("LavaPool")
WaitForChild pauses the script until the child is found, which is useful when objects are created slightly later, such as when the game is still loading.
Working with Workspace in Local and Server Scripts
Both server scripts and local scripts can access Workspace, but they do so from different perspectives. A server script in a service like ServerScriptService changes the real game world on the server. This affects all players. A local script can read and adjust certain properties from the client side, such as how the camera views the world, but the deeper details of server and client behavior belong to multiplayer scripting.
For now, it is enough to understand that Workspace is shared, and that the main, authoritative version of it lives on the server. When you write scripts that change objects in Workspace, you are usually writing server scripts that control the world for everyone in that game session.
Summary of Workspace Use in Scripting
The Workspace is the live 3D world where all visible and physical objects of your game exist. You access it via workspace or game.Workspace in Lua. You parent new parts into Workspace to make them appear and interact physically. You organize content inside Workspace using folders and models to keep your game manageable. You use FindFirstChild, GetChildren, and related methods to safely find and handle objects. You can adjust world level properties like gravity through workspace properties, which then affect every player and every physical part inside the game world.