Scene manager autoload for handling scene changes and UI visibility

Awa · January 29, 2026, 5:04am

Godot Version

4.4

Question

I’m trying to understand how UI is usually structured in Godot when some buttons feel persistent but change depending on the screen.

In many games, buttons (often at the bottom) are always visible and responsive, but their actions change per menu. For example, the main menu might only have a Back button, while the Settings screen adds Apply and Reset — yet the layout stays consistent (see attached images).

What’s the common approach in Godot for this?

Do people usually keep a persistent UI scene and show/hide or reconfigure button panels?
Or instance UI per screen and reuse layouts?
Are buttons always present and driven by UI state, or recreated per menu?

Also, how does the UI typically know which buttons should be active — via an autoload/UI manager, signals, or some kind of UI state?

Here’s an example from Life Is Strange. I’m trying to understand how these buttons are handled. Depending on the scene, some buttons disappear and others appear, even though the placement feels consistent.

What I’m unsure about is how this is set up under the hood. Are these buttons defined separately inside each scene, or is there a single UI layer / manager that stays active and just controls button visibility and behavior?

If it’s the latter, how does each scene communicate what buttons should be shown? And in the last image, you can see the buttons fully change, the previous ones disappear and new ones appear in the same area, which makes me wonder whether they’re being swapped, reconfigured, or replaced entirely.

I’d like to understand the typical approach used for this kind of UI behavior.

festering · January 29, 2026, 5:53pm

Yes.

There probably isn’t a common approach & I suspect most folks do a mixture of everything you mention when doing their UI.

In your examples, the DLC and main menu screens probably use data that’s in an autoload to determine whether to show a “play” or “purchase” button or activate the “choices” button. But, in some cases, one could use a scene’s internal data to enable/disable buttons. (For example, if it’s a UI for upgrading weapons, it could check that the player can afford the upgrades and handle the buttons accordingly.)

The “select / back / exit” buttons in your examples could be done from scratch on each UI screen or they could be done with a reusable panel. The reusable panel could have code that hides “exit” if it’s not possible to exit from a particular screen. (The parent scene would tell the button panel to hide “exit” or rename “select” to “play”.)

The “Do you want to keep your modifications…” window would probably be done with a child scene that’s hidden until it’s needed.