UI and HUD

The UI workspace is for in-game interface: menus, HUD counters, buttons, labels, panels, health bars, and overlays. UI is part of the game, not the editor chrome.

UI vs scene objects

Use scene objects for	Use UI for
World characters	Score counters
Platforms and props	Menus
Physics objects	Buttons
Pickups and hazards	Dialog panels
World-space signs	Health bars and progress displays

World objects live on the scene canvas. UI elements live in interface layers that should remain readable across screen sizes.

Common UI elements

Element	Use
Panel	Grouping surface for menu or HUD content
Label	Score, timer, prompt text
Button	Menu action, retry, start, pause
Image	Icon, portrait, decorative game art
Progress bar	Health, cooldown, loading, stamina
Slider	Settings, volume, adjustable runtime values

The UI palette adds elements such as Panel, Text, Button, Bar, Slider, and Image.

Inspector sections

Selecting a UI element shows sections based on that element type.

Section	Edits
Element	Name, visibility, input blocking
Placement	Anchor and offsets when the parent is not laying out children
Sizing	Fixed, fill, or hug sizing inside layout parents
Layout	Row, column, grid, spacing, padding, alignment
Style	Background, corner radius, text color, font size
Content	Text, button event name, bar value, image asset, slider variable
World anchor	Pin the UI element to a world object's screen position

Keep HUD UI compact. A player should understand the important state while still seeing the game.

Binding UI to game state

UI becomes useful when it reflects runtime data.

Common bindings:

UI	Data
Score label	Project variable score, bound as self.score
Lives label	Project variable lives, bound as self.lives
Health bar	Player Health component
Objective text	self.currentQuest (or self.GameState.currentQuest)
Button enabled state	A bool variable or component condition

Use GameState for values shared across scenes. Use object or component fields for values tied to one object.

UI bindings use expression strings. Project variables are available through self, and objects can be looked up with get(id).

Examples:

props.text = `Score ${self.score}`
props.value = self.hp
props.max = self.maxHp
visible = self.hasKey

For object-specific values, use an object lookup when you know the id:

props.value = get("player").hp

Bindings run after gameplay logic each frame so the HUD catches up immediately after Flow or components change state.

UI buttons and Flow

Buttons can trigger Object Flow or Scene Flow.

Examples:

Button	Graph action
Start	Go To Scene: Level 1
Retry	Reset GameState, reload current scene
Pause	Show pause panel, stop gameplay timer
Shop item	Check currency, subtract cost, add item
Close	Hide panel

Put global navigation in Scene Flow when possible. Put button-specific feedback, sounds, and visual state on the button object.

Buttons expose an Event field. At runtime, pressing the button emits that custom event into the rule system. Listen for the same event name in Scene Flow or Object Flow.

Previewing over the scene

In the UI workspace, the stagebar Show scene toggle lays out the UI at the same stage bounds used in Play and Preview, composited over the arrange-mode scene (edit camera — not a live Play session). Leave it off to edit on the letterboxed artboard.

Responsive layout

Players may run the game on desktop, tablet, or phone-sized screens.

Good layout habits:

• Anchor HUD elements to predictable corners or edges.
• Keep tap targets large enough for touch.
• Avoid long labels inside small buttons.
• Test fullscreen play.
• Leave room for browser UI on mobile Safari.

UI organization

Name UI roots clearly:

UI
  HUD
    ScoreLabel
    LivesLabel
  PauseMenu
    Panel
    ResumeButton
    RetryButton
  Dialog
    Portrait
    Text
    ContinueButton

Keep menus hidden until needed. Use flow graphs to toggle visibility.

Related docs

• Projects and scenes
• Visual scripting
• Components and properties
• Testing and debugging