Scene and Screen Management

What a Scene Is

A scene, sometimes called a screen or a stage, is a self-contained chunk of the game with its own contents and its own behavior. The main menu is a scene: it has its buttons, its background, its update logic for handling clicks, and its rendering. A level is a scene: it has its entities, its physics, its win and lose conditions, and its rendering. The settings screen, the credits, the level select, the shop, each is a scene. Thinking in scenes gives the game a clean top-level structure where each major part is an isolated unit rather than a tangle of shared global state.

This isolation is the point. When the game is showing the main menu, the level's entities should not exist, its timers should not run, and its memory should be free. When the player starts a level, the menu's contents should be gone. A scene encapsulates everything belonging to one part of the game so that activating and deactivating a part is a single clean operation rather than a manual cleanup of scattered state. Scenes are closely tied to the top-level state machine, with each major game state typically corresponding to a scene.

What a Scene Manager Does

The scene manager is the small piece of infrastructure that owns the active scene or scenes and orchestrates transitions between them. Its core job is to run the current scene each frame, calling that scene's update and render, and to handle requests to switch to a different scene. When a switch is requested, the manager tears down the outgoing scene and sets up the incoming one, which is where the practical questions of scene management arise.

Each scene typically exposes lifecycle hooks that the manager calls at the right moments. An enter or load hook runs when the scene becomes active, creating its entities and starting its systems. An exit or unload hook runs when the scene is deactivated, freeing memory, stopping timers, and unsubscribing from events. Update and render hooks run each frame while the scene is active. These hooks give every scene a consistent shape and give the manager a uniform way to drive any scene, whether it is a menu or a complex level.

Good lifecycle handling answers the questions that otherwise become bugs. How do you free a level's memory when the player quits to the menu? The exit hook does it. How do you make sure a level's update timer does not keep running after you leave? The exit hook stops it. How do you guarantee event listeners from one scene do not leak into the next? The exit hook unsubscribes them. Centralizing this in the scene lifecycle, rather than scattering cleanup across the codebase, is what keeps a multi-screen game from slowly accumulating leaks and ghost behavior.

The Scene Stack

A simple scene manager replaces one scene with another, which is fine for moving between the menu and a level. But some situations call for layering scenes rather than replacing them, and for those a stack-based scene manager is the answer. Instead of holding a single active scene, the manager holds a stack, where the top scene is the active one but the scenes beneath it are preserved.

The classic case is the pause menu. When the player pauses, you push a pause scene onto the stack on top of the playing scene. The playing scene stops updating, so the game world freezes exactly where it was, but it remains in memory and can still be rendered underneath the pause overlay, giving the familiar effect of a paused game visible behind a menu. When the player resumes, you pop the pause scene off, and the playing scene becomes active again, continuing from precisely where it stopped with no need to reload or reconstruct anything.

The stack handles other layered cases too. A confirmation dialog can push on top of any scene, a dialogue box can overlay gameplay, and an inventory screen can pause the action without discarding it. The manager can also decide, per scene, whether the scenes below should keep rendering, so a fully opaque menu hides the game while a translucent overlay shows it through. The scene stack is a small extension that handles a surprising range of real game UI needs cleanly.

Transitions and Preloading

Switching scenes is rarely instantaneous in a polished game. A fade to black, a wipe, or a loading animation usually covers the transition, both for visual smoothness and to hide the work of tearing down one scene and building the next. A scene manager that supports transitions runs the outgoing scene's exit, plays the transition effect, and runs the incoming scene's enter, sequencing these so the player sees a clean handoff rather than a jarring cut or a frozen frame while assets load.

Preloading is the related concern of having the next scene's assets ready before the player arrives. Loading a level's textures, sounds, and data the moment the player requests it produces a stall. Loading them during the transition animation, or during idle time on the previous scene, hides the cost. A scene's enter hook can begin asset loading, and the manager can hold the transition until loading completes, so the player experiences a smooth animated handoff instead of a hang. For larger web games where asset sizes matter, coordinating scene transitions with asset loading is a key part of keeping the experience responsive, and it connects scene management to the broader topic of web game performance.

Scene management is the pattern that gives a game coherent structure at the largest scale. Combined with a state machine for flow, object pooling within scenes for performance, and save systems that capture scene state, it forms the backbone that holds a multi-screen game together. Even a modest game benefits from organizing itself into scenes, because the clarity of having each part be a self-contained unit pays off the moment the game has more than one screen to manage.

Sharing State Between Scenes

Scenes are deliberately isolated, which raises an obvious question: how does data get from one scene to the next? When the player finishes a level and the results screen needs to show their score, or when the shop scene needs to know how much currency the player has, the information has to cross the boundary between two otherwise self-contained units. Handling this cleanly is one of the things that separates a tidy scene system from one that leaks global state everywhere.

The simplest case is passing data forward at the moment of transition. When you request a switch to the results scene, you hand it the data it needs as part of the request, so the scene receives its inputs at creation rather than reaching out to find them. This keeps the dependency explicit and one-directional, the outgoing scene provides what the incoming scene needs, and nothing relies on hidden shared variables. For the common case of carrying a result from one screen to the next, this is clean and sufficient.

For data that genuinely outlives any single scene, such as the player's profile, settings, unlocked content, and overall progress, the right home is a persistent service that exists outside the scene system entirely. Rather than storing the player's currency inside the gameplay scene, where it would vanish when the scene unloads, you keep it in a long-lived game-state object that every scene can read and update. The scene manager handles the transient, per-screen content, while these persistent services hold the data that belongs to the whole game session. Drawing this line clearly, transient state in scenes and durable state in services, prevents the slow creep of global variables that otherwise undermines the isolation scenes are meant to provide, and it gives the save system a clear target for what to persist.