Table of Contents
Why ScreenGui Matters
When you build a Roblox game, you are not only creating the world that players walk around in. You also need a way to show information directly on the screen, such as buttons, score, health, or menus. This visible layer that sits on top of the 3D world is called the user interface, or UI. On Roblox, almost every piece of UI you see is placed inside a special object named ScreenGui.
A ScreenGui is the basic container for 2D interface elements that appear on the player’s screen. It collects and organizes all the UI elements that should follow the screen instead of sitting in the 3D world. Without a ScreenGui, your buttons, text labels, and other interface elements will not show to the player.
Understanding ScreenGui is the first step to building any UI in your game. Later chapters will focus on specific elements like buttons and text, but here you will learn how to create and position the container that they live in.
Important: Every interface element that should appear directly on a player’s screen must be a child, or a descendant, of a ScreenGui that is inside the PlayerGui of that player.
Where ScreenGui Lives
UI that appears on the screen is not stored directly in the 3D world. Instead, Roblox uses a special location named PlayerGui for each player. Each player has their own PlayerGui, so they can see their own menus and HUD (heads up display) without affecting other players.
When a player joins the game, Roblox creates a PlayerGui folder for that player. That folder lives under the Player object in Players. Any ScreenGui placed in that PlayerGui will only be visible to that one player.
For building and testing inside Roblox Studio, you will often create ScreenGui objects under a folder named StarterGui. Roblox automatically copies content from StarterGui into each player’s PlayerGui when they spawn.
So the usual path in Studio is:
StarterGui contains ScreenGui.
In a running game, Roblox copies that to:
Players > PlayerName > PlayerGui contains ScreenGui.
This copy happens for each player individually. You do not need to move it yourself for basic UI that should appear for every player.
Creating a ScreenGui
To display any UI, you first need to create a ScreenGui. In Roblox Studio, you can do this through the Explorer window. The exact method can vary, but the basic idea is always the same. You add a ScreenGui as a child of StarterGui.
Once your ScreenGui is created, you can rename it to match its purpose. For example, you might call it MainHUD, MainMenuGui, or ObbyGui. Clear names help you stay organized when your game grows.
Inside that ScreenGui, you will later insert elements such as TextLabel, TextButton, or ImageLabel. The ScreenGui itself controls where and how those elements appear in relation to the player’s screen, not to the 3D world.
You can also create a ScreenGui with a script if you want UI to appear only in some situations. In a LocalScript running on the client, a basic version looks like this:
local player = game.Players.LocalPlayer
local playerGui = player:WaitForChild("PlayerGui")
local screenGui = Instance.new("ScreenGui")
screenGui.Name = "DynamicGui"
screenGui.Parent = playerGui
This script creates a new ScreenGui on the player’s screen at runtime. Everything you add inside screenGui will then show up only for that player.
How ScreenGui Behaves on the Screen
A ScreenGui itself is invisible, but it controls how its child elements are laid out on the screen. Each ScreenGui fills the entire screen area for that player. The elements inside it use a 2D coordinate system that depends on the screen size.
The coordinate system for UI is handled mainly by properties of the child objects, which you will use more in later chapters. What is important now is that the ScreenGui is the frame of reference for those coordinates. Whether a player is on a small screen or a large screen, each ScreenGui still covers that full area.
You can have multiple ScreenGui objects in the same player’s PlayerGui. They all share the screen. Roblox draws them in a certain order, one on top of another. That draw order affects which UI shows in front. For example, a pause menu ScreenGui should appear above a simple HUD ScreenGui.
ScreenGui has properties that help with this layering. One of the most important is the display order.
DisplayOrder and Layering
If you have more than one ScreenGui, Roblox needs to decide which one appears on top when they overlap. This is where the DisplayOrder property of ScreenGui becomes important. Each ScreenGui has a DisplayOrder that is a number. Higher numbers appear above lower numbers.
For example, if your HUD is in a ScreenGui with DisplayOrder = 1 and your pause menu is in a ScreenGui with DisplayOrder = 10, the pause menu will cover the HUD when it is visible.
You can think of it like layers in an image editing program. Each layer has a level. The ones with higher levels are visible on top of those with lower levels.
If you do not set the DisplayOrder, Roblox uses a default value, but it is better to choose values yourself when you have multiple major UI systems. That way you know which ScreenGui will always appear over another.
Rule: A ScreenGui with a higher DisplayOrder value will always render above a ScreenGui with a lower DisplayOrder value when they overlap on the screen.
You can change DisplayOrder both in Studio and through scripts. For example, you might show a temporary warning message by placing it in a ScreenGui with a higher DisplayOrder so players can always see it.
Enabling, Disabling, and Controlling Visibility
Sometimes you want a ScreenGui to be hidden. For example, you may have a main menu that appears when a player first joins and then disappears when they start playing. You can control this behavior with the Enabled property of ScreenGui.
If a ScreenGui has Enabled set to true, all of its child UI elements can be drawn on the screen. If Enabled is false, the entire ScreenGui and everything inside it is hidden.
This is useful for switching between different screens. You might have one ScreenGui for a main menu and another for in game HUD. Enabling one and disabling the other allows you to quickly change what a player sees.
In a LocalScript, you can change this like so:
local player = game.Players.LocalPlayer
local playerGui = player:WaitForChild("PlayerGui")
local mainMenu = playerGui:WaitForChild("MainMenuGui")
local hud = playerGui:WaitForChild("HUDGui")
mainMenu.Enabled = false
hud.Enabled = true
In this simple example, the main menu disappears and the HUD appears. The ScreenGui objects stay in memory, they are just not drawn when Enabled is false.
ScreenGui and LocalScripts
UI is usually handled on the client side because it only needs to affect what the player sees, not the game world itself. ScreenGui is tightly connected to LocalScripts, which run on the client. You do not need the full details of LocalScripts here, but you should understand that most UI behavior, like reacting to button clicks or showing messages, is controlled by scripts that run inside ScreenGui or one of its children.
When you run a LocalScript that manipulates UI, you usually place that LocalScript either in the ScreenGui or its descendants. Roblox automatically allows LocalScripts to run in PlayerGui. That is why ScreenGui is often the root for both visual elements and their controlling scripts.
For example, you might create a LocalScript under your ScreenGui that changes UI text based on the player’s score, or that opens and closes different frames within the ScreenGui.
This connection between ScreenGui, PlayerGui, and LocalScripts keeps UI logic on each player’s machine, which is important for performance and responsiveness.
ScreenGui for HUD vs Menus
There are two common uses of ScreenGui in many games. One use is for HUD elements that stay on the screen while you play. These are things like health bars, coin counters, or checkpoint progress. Another use is for full screen menus, such as the main menu, pause screen, or shop windows.
For HUDs, your ScreenGui usually stays enabled all the time during gameplay. Its child elements might change values or show and hide parts, but the main container is always there.
For menus, sometimes it is more convenient to keep a separate ScreenGui that is only enabled when the menu is open. That way, you can enable a single ScreenGui to show an entire menu system at once and then disable it again when the player closes the menu.
Separating your HUD and menus into different ScreenGui objects also makes it simpler to manage their display order. You can assign the HUD a low display order and menus a higher display order, ensuring menus appear above the HUD when they are visible.
Testing ScreenGui in Play Mode
To see how your ScreenGui behaves for real players, you need to test it while the game is running. In Roblox Studio, you use Play mode for this. When you click Play, Roblox creates a real player character and a PlayerGui for that player. StarterGui contents are then copied into PlayerGui.
If you look at the Explorer during Play mode, you will see that your ScreenGui now appears under PlayerGui instead of only under StarterGui. This lets you confirm that Roblox is copying UI correctly. It also lets you test scripts that depend on LocalPlayer and PlayerGui.
If your ScreenGui does not show in Play mode, the most common issues involve parenting and enabling. Check that your ScreenGui is inside StarterGui before play, or inside PlayerGui at runtime, and that the Enabled property is true. Also remember that a ScreenGui will not show anything unless it contains UI elements, which you will add in later chapters.
Planning Your UI Using ScreenGui
Even before you add actual buttons or text labels, it helps to plan where your different screen interfaces will live. You can decide which ScreenGui objects you need, what they will be named, and which purpose each one will serve.
For example, in a simple obby you might create:
A ScreenGui for the main HUD that displays current stage, time, or a reset button.
A ScreenGui for a main menu that shows before the player starts the course.
A ScreenGui for a win screen that appears when the player reaches the final checkpoint.
Later you can fill each of these containers with the specific UI elements and connect them with scripts. By starting with clear ScreenGui containers, you keep your UI well structured and easier to manage as you add more features to your game.