Scenes

Summary

A scene is a self-contained collection of game objects representing one loadable piece of a game — a level, a menu, a loading screen. Only one (or, in more advanced setups, a deliberately-managed few) scene is active at a time, and loading a different scene replaces or adds to what currently exists in the world. Scenes are how engines let a game be built and organized in separate, manageable pieces instead of one impossibly large world file.

Why This Matters

A game with a main menu, ten levels, and a credits screen cannot reasonably keep every single game object from all twelve of those in memory and active simultaneously — that wastes memory, complicates logic ("is the player currently in the menu or in a level?"), and makes each piece harder to work on independently. Scenes solve this by giving each self-contained piece of the game its own file, loaded only when needed and unloaded when not — a designer builds and tests "Level 3" in isolation without every other level's objects cluttering the same workspace.

Mental Model

A scene is one chapter of a book on its own page, not the entire story crammed onto one sheet. A book is organized into chapters precisely so a reader (and the author) can focus on one self-contained section at a time, flipping to a different chapter when the story moves on, without the entire book's content needing to be visible at once. Loading a new scene is like turning to a new chapter — what was on the previous page isn't necessarily gone forever, just not currently in view.

Core Explanation

• A scene holds a set of game objects and their initial configuration. Everything placed in the scene editor — the terrain, the enemies, the lighting — is saved as part of that scene's data, ready to be instantiated when the scene loads.
• Loading a scene can replace or add to the current world. A "single" load unloads everything from the previous scene and loads the new one in its place (a full level transition); an "additive" load loads a new scene's contents alongside what's already active (useful for streaming in a section of a large open world, or loading a persistent UI overlay separately from gameplay).
• Scenes are the natural boundary for organizing large projects. Splitting a game into a MainMenu scene, a Level01 scene, and a Level02 scene lets each be authored, tested, and loaded independently — none of them need to know the others exist.
• Objects that must survive a scene change need explicit handling. By default, everything in a scene is destroyed when that scene unloads — an object meant to persist across scenes (a GameManager, background music) needs to be explicitly marked or moved to avoid being destroyed along with the rest.

Syntax / Theory

C# (Unity)

using UnityEngine.SceneManagement;

SceneManager.LoadScene("Level02");                          // Replaces the current scene.
SceneManager.LoadScene("HUD", LoadSceneMode.Additive);       // Loads alongside the current one.

public class GameManager : MonoBehaviour
{
    void Awake() => DontDestroyOnLoad(gameObject); // Survives scene loads.
}

C++ (Unreal — Levels)

UGameplayStatics::OpenLevel(this, FName("Level02")); // Unreal calls the equivalent a "Level."

Unreal uses "Level" for the same concept Unity calls a "Scene" — a self-contained, independently loadable collection of Actors. Unreal also supports "Streaming Levels," its equivalent of additive scene loading, for loading and unloading sections of a world without a full level transition.

Unreal Blueprint

The Open Level node in Blueprint calls the same level-loading functionality directly from visual scripting, matching SceneManager.LoadScene in intent and effect.

Practical Example

A game with a main menu and gameplay uses separate scenes so the two are never active — and never accidentally interacting — at the same time.

public class MainMenuController : MonoBehaviour
{
    public void OnPlayButtonPressed()
    {
        SceneManager.LoadScene("Gameplay");
    }
}

public class PauseMenu : MonoBehaviour
{
    public void OnQuitToMenu()
    {
        SceneManager.LoadScene("MainMenu");
    }
}

Neither scene needs to know anything about what game objects exist in the other — loading fully replaces the active world, avoiding leftover state from the previous context.

Common Mistakes

• Assuming an object persists across a scene load without explicitly marking it to. A script tracking player score in a normal scene object loses that data the instant a new scene loads and destroys it, unless it's been made to survive (DontDestroyOnLoad or an equivalent persistence pattern).
• Loading scenes synchronously when a loading screen or smooth transition is needed. A large scene loaded with a blocking call freezes the game until it finishes — an asynchronous load, shown behind a loading screen, avoids that stall.
• Duplicating persistent objects (like a GameManager) by having every scene spawn its own copy. Without a check for "does one already exist," reloading or additively loading a scene can spawn duplicate managers that conflict with each other — a common pattern guards against this with a check-and-destroy-duplicate step.
• Overloading a single scene with everything instead of splitting logically. Cramming an entire game's levels into one giant scene defeats the organizational and memory benefits scenes exist to provide.

Game Development Example

An open-world game streams in only the scenes (or streaming levels) near the player, rather than keeping the entire world loaded at once.

public class RegionLoader : MonoBehaviour
{
    void OnPlayerEnteredRegion(string regionSceneName)
    {
        SceneManager.LoadScene(regionSceneName, LoadSceneMode.Additive);
    }

    void OnPlayerLeftRegion(string regionSceneName)
    {
        SceneManager.UnloadSceneAsync(regionSceneName);
    }
}

Only the regions actually near the player are loaded into memory at any given moment — a direct, practical payoff of treating the world as separate, independently loadable scenes rather than one monolithic space.

Best Practices

• Split a project into scenes along natural boundaries (menus, individual levels, persistent UI) rather than keeping everything in one scene.
• Explicitly handle anything that needs to survive a scene change, and guard against duplicate persistent objects when scenes reload.
• Prefer asynchronous scene loading behind a loading screen for anything large enough to cause a noticeable stall.
• Keep each scene focused on one self-contained purpose, mirroring the same single-responsibility thinking applied to components.

Exercises

1. Create a MainMenu scene and a Gameplay scene, and wire up a button in the menu that loads the gameplay scene, and a pause-menu button in gameplay that loads back to the main menu.
2. Add a GameManager object to the MainMenu scene that uses DontDestroyOnLoad, then load into Gameplay and confirm it still exists — then reload MainMenu and explain why a duplicate GameManager might now exist unless guarded against.
3. You're building a large open-world game. Decide between one massive scene containing the entire world versus many smaller scenes streamed in additively based on player position, and justify the trade-off in terms of memory and iteration speed for the team.
4. Research the difference between synchronous and asynchronous scene loading, and explain why a loading screen typically needs the asynchronous version to display progress and remain responsive.

Related Concepts

• Game Objects — a scene is fundamentally a saved collection of game objects and their configuration; understanding what a game object is comes first.
• Prefabs — prefabs are frequently instantiated into a scene at runtime, complementing scenes' pre-placed, saved content with dynamically-created content.
• Game State — persisting state (like score or inventory) across scene transitions is one of the main reasons a dedicated game state management approach is needed.

Further Reading

• KNOWLEDGE_SCHEMA.md — GDKB's concept maturity ladder and cross-linking rules, which this document follows.
• Unity documentation — Introduction to Scenes: https://docs.unity3d.com/Manual/CreatingScenes.html
• Unreal Engine documentation — Levels: https://dev.epicgames.com/documentation/en-us/unreal-engine/levels-in-unreal-engine