Quick answer: A black screen after “Go to layout” in Construct 3 usually means the target layout’s resources have not loaded, the “On start of layout” trigger has an error, or the layout references non-global objects that do not exist on it. Fix this by checking the browser console for errors, ensuring all referenced objects are placed on the target layout, marking persistent objects as Global, and using a loader layout for resource-heavy transitions.

Here is how to fix the Construct 3 black screen on layout transition. You call “Go to layout” and instead of seeing your menu, level, or cutscene, you get a completely black screen. No errors in the Construct 3 editor, no obvious reason. The game is not crashed — it just shows nothing. This is one of the most frustrating Construct 3 issues because the cause is rarely obvious from the event sheet alone.

The Symptom

You use the “Go to layout” action to transition between layouts — typically from a menu to a game level, or between game levels. The screen goes black and stays black. In some cases, you can still hear audio playing or see the debugger showing that the game loop is running. The layout simply is not rendering anything visible.

Sometimes the black screen only appears on specific transitions. Going from Layout 1 to Layout 2 works fine, but going from Layout 2 to Layout 3 produces the black screen. Or it works in preview mode but fails in an exported build. The inconsistency makes the bug harder to track down.

You might also see a brief flash of the correct layout before it goes black, which indicates that the layout loads initially but something in the “On start of layout” event breaks the rendering.

What Causes This

There are four common causes:

1. “On start of layout” has an error. If any action in the “On start of layout” trigger throws a JavaScript error, the layout initialization halts partway through. Objects may not get positioned, layers may not get configured, and the rendering pipeline stalls. The black screen is actually a layout with no visible objects in their correct positions. The error often appears in the browser console (F12) but not in the Construct 3 editor.

2. Non-global objects referenced but not placed. Each layout has its own set of object instances. If the event sheet for a layout references a non-global object type that has no instances on that layout, the events silently fail. For example, if your event sheet sets the position of a “HUD” sprite on start of layout, but the HUD sprite is not placed on that layout and is not marked as Global, nothing happens. If all your visible objects are set up this way, you see nothing.

3. Resources not loaded in time. When you use “Go to layout”, Construct 3 needs to load the textures, audio, and other assets for the target layout. If the project uses “Load on demand” for images and the target layout has many large textures, there can be a delay. During this delay, the screen appears black because the sprites have no textures to render. In exported builds on slow connections, this delay can be significant.

4. Layer visibility or opacity issues. If a layer on the target layout has its visibility set to invisible or its opacity set to 0, all objects on that layer will not render. This can happen if a previous layout’s event sheet modifies layer properties on a global layer, and those changes persist into the next layout.

The Fix

Step 1: Check the browser console for errors. Press F12 while previewing in the browser. Look for JavaScript errors that fire at the moment of the layout transition. Any error in “On start of layout” will appear here. Fix the error and the layout will render.

// Common error scenario in On Start of Layout:
// Trying to access an object that doesn't exist on this layout

+ System: On start of layout
  -> PlayerHUD: Set position to (100, 50)  // Fails if PlayerHUD not on this layout
  -> ScoreText: Set text to "0"           // Also fails if ScoreText not placed

// FIX: Check if instance exists before accessing it
+ System: On start of layout
  + PlayerHUD: Pick count > 0
    -> PlayerHUD: Set position to (100, 50)
  + ScoreText: Pick count > 0
    -> ScoreText: Set text to "0"

Step 2: Ensure objects exist on the target layout or are marked Global. Open the target layout in the editor. Check that every object type referenced in that layout’s event sheet has at least one instance placed on the layout. For objects that must persist across layout changes (player, HUD, game manager), set them as Global.

// To make an object global:
// 1. Select the object type in the Project Bar
// 2. In Properties, set "Global" to "Yes"

// Alternatively, create instances on start of layout:
+ System: On start of layout
  + PlayerHUD: Pick count = 0
    -> System: Create object PlayerHUD on layer "UI" at (100, 50)

Step 3: Use a loader layout for resource-heavy transitions. Instead of going directly to a layout with many large assets, transition through a lightweight loading screen that preloads the resources.

// Loader Layout event sheet:

+ System: On start of layout
  -> LoadingText: Set text to "Loading..."

+ System: On loader layout complete
  -> System: Go to layout "GameLevel1"

// In Project Settings:
// Set "Use loader layout" to Yes
// Set your loading layout as the loader layout

// Update loading progress bar:
+ System: Every tick
  -> LoadingBar: Set width to (LoadingProgress * 400)

Step 4: Check layer visibility and opacity. If you modify layer properties with events (setting visibility or opacity), ensure those changes do not carry over to the next layout unintentionally.

// Reset layer visibility on start of each layout
+ System: On start of layout
  -> System: Set layer "Game" visible
  -> System: Set layer "Game" opacity to 100
  -> System: Set layer "UI" visible
  -> System: Set layer "UI" opacity to 100

You can also use the scripting API to diagnose layer state:

// JavaScript: Debug layer visibility on layout start
runOnStartup(async runtime => {
    runtime.addEventListener("beforelayoutstart", () => {
        for (const layer of runtime.layout.getAllLayers()) {
            console.log(`Layer "${layer.name}": visible=${layer.isVisible}, opacity=${layer.opacity}`);
        }
    });
});

Why This Works

Each fix targets a different point in the layout transition pipeline:

Fixing “On start of layout” errors allows the layout initialization to complete. The black screen occurs because an error halts execution midway through the setup. Once the error is resolved, all objects get positioned and rendered correctly on the first frame.

Ensuring objects exist on the layout prevents silent failures. Construct 3 does not throw an error when you reference a non-global object type that has no instances — it simply skips the action. By placing instances or creating them dynamically, you guarantee the actions have something to operate on.

Loader layouts solve the timing problem. They give Construct 3 time to load textures and assets into memory before the player sees the layout. Without a loader, the engine tries to render sprites that have no texture data yet, resulting in invisible (black) rendering.

Layer visibility resets ensure a clean state. Since global layers persist across layout transitions, any visibility or opacity changes from the previous layout carry over. Explicitly resetting these properties guarantees a known visual state.

"The browser console is your best friend when debugging black screen issues in Construct 3. If the layout is truly loading and just not rendering, the answer is almost always in the console output."

Related Issues

If objects disappear unexpectedly rather than the whole layout going black, see our guide on Construct 3 ‘Object Not Found’ error after destroying instances. If your audio stops working after a layout transition, Construct 3 audio not playing in browser covers the autoplay policy and audio context issues that commonly appear after layout changes. And if animations break on the new layout, Construct 3 animation not playing or stuck on first frame addresses the common causes.

F12 is the first step. Always check the console.