Scene Manager Architecture for Game States

Hello! Welcome to the first lesson of Module 3.

In our last lesson, we brought your game world to life by adding NPCs with their own simple AI. You now have a map where the player and other characters can move around, creating a dynamic environment. However, our game is currently "stuck" in this single map exploration mode. A real JRPG seamlessly transitions between exploring a town, engaging in a battle, navigating menus, and watching cutscenes.

This lesson focuses on the architectural foundation that makes this possible. We will address the learning outcome: Design a scene manager architecture to handle transitions between game states (e.g., map, menu, battle). This is a critical step in building the skeleton of your game, upon which all other systems will be built.

By the end of this lesson, you will have designed a robust system for managing the overall flow of your game, inspired by patterns used in professional game development.

1. The Problem: Managing Game Modes

As a front-end developer, you're familiar with managing application states. You might show a loading spinner, then display data, or switch to an edit form. You wouldn't put the logic for all these views into one massive if/else block; you'd use components, routing, and state management libraries.

Game development faces the exact same challenge, but the "views" are entire game modes, which we often call scenes or states:

• A TitleScreenScene
• A MapScene
• A BattleScene
• A MenuScene
• A ShopScene

Trying to manage these with simple boolean flags (isInBattle, isMenuOpen, etc.) quickly leads to what is often called "spaghetti code"—a tangled mess that is hard to debug and even harder to extend.

The solution, as in many software architecture problems, is to create a formal system for managing state. In game development, this is most commonly achieved with a State Machine.

2. The State Pattern: An Architectural Blueprint

You've already implemented a very simple state machine for our NPCs (switching between WAITING and MOVING). We're now going to elevate that concept to manage the entire game. The architectural pattern we will use is the State Pattern.

The core idea is to encapsulate the behavior of each game mode into its own object. Our main game loop doesn't need to know if we're in a battle or on the map; it simply tells the current state to update itself and draw itself.

This architecture consists of two main components:

1. A Scene Manager (the "context") that holds the current scene and orchestrates transitions.
2. A Scene Interface (the "state") that defines a common contract for all scenes, ensuring the Scene Manager can work with any scene without knowing its specific details.

This is a classic example of abstraction that will be very familiar from your software engineering experience.

Let's break down the design proposed in that article.

The Scene Interface

Every scene in our game must perform a few key actions. We can define these in a base class or an interface that all scenes will implement.

• enter(params): Called once when the scene becomes active. This is where you'd initialize the scene, load necessary assets, create characters, etc. The params allow you to pass data during the transition (e.g., which map to load).
• exit(): Called once when the scene is left. This is for cleanup, like stopping music or releasing memory.
• update(deltaTime): Called every frame by the game loop. Contains the scene's core logic (e.g., handling input, moving characters).
• draw(context): Called every frame after update. Contains all rendering logic for the scene.

The Scene Manager

The SceneManager is the conductor of our orchestra. Its job is simple but crucial:

1. It keeps track of the currentScene.
2. In the main game loop, it calls currentScene.update() and currentScene.draw().
3. It provides a method, let's call it changeScene(sceneName, params), to transition between scenes. This method would:
   • Call currentScene.exit().
   • Find the new scene by its sceneName.
   • Set it as the currentScene.
   • Call the new currentScene.enter(params).

This design cleanly separates the what (the logic inside each scene) from the how (the transition logic in the Scene Manager).

3. An Improvement: The State Stack

The changeScene model works well, but it has a limitation. Imagine this flow:

1. You are on the MapScene at coordinates (50, 32).
2. You press a button to open the MenuScene.
3. You close the menu.

If we use changeScene("MapScene"), we would create a new instance of the map, losing our position. We want to resume the previous scene exactly where we left off.

This is where a State Stack comes in. Instead of just replacing the current state, we can push new states on top of a stack.

• push(sceneName, params): Pauses the current scene and pushes a new one onto the stack. The new scene becomes active.
• pop(): Exits and removes the top scene from the stack, resuming the one underneath it.

This model is perfect for JRPGs:

• Map -> Menu: push("MenuScene"). The map is paused underneath.
• Menu -> Map: pop(). The menu is destroyed, and the map resumes.
• Map -> Battle: push("BattleScene"). The map is paused.
• Battle -> Map: pop(). The battle is destroyed, and the map resumes with the player standing on the same tile.

The stack-based approach also lets you decide if underlying scenes should be rendered. When the menu is open, you might want to render the paused map behind it (perhaps with a dark overlay or blur effect). When a battle starts, you typically want a full-screen transition, so you would only render the top-most scene. Our Scene Manager's draw method can be designed to handle this flexibility.

4. Advanced Architecture: Persistent Core Systems

One final piece of the puzzle. Where does the SceneManager itself live? What about other global systems like the AudioManager or SaveManager that need to persist across all scenes?

A common and robust solution is to use a multi-scene architecture.

1. You have a single, persistent Core Scene that is loaded when the game starts and is never unloaded.
2. This CoreScene contains all your global managers: the SceneManager, AudioManager, InputManager, etc.
3. The SceneManager then loads and unloads the other game scenes (MainMenuScene, MapScene, etc.) additively.

This ensures your core systems are always available and their state persists, while the game-specific scenes can come and go as needed.

Test your understanding!

Using the state stack architecture, describe the sequence of push and pop calls for the following user journey:

1. Starts game, landing on the MapScene.
2. Opens the main menu.
3. From the main menu, selects "Equipment".
4. Goes back from "Equipment" to the main menu.
5. Closes the main menu and returns to the map.

Show answer

1. Game starts: sceneManager.push("MapScene")
   • Stack: [MapScene]
2. Opens menu: sceneManager.push("MenuScene")
   • Stack: [MapScene, MenuScene]
3. Selects equipment: sceneManager.push("EquipmentScene")
   • Stack: [MapScene, MenuScene, EquipmentScene]
4. Goes back: sceneManager.pop()
   • Stack: [MapScene, MenuScene]
5. Closes menu: sceneManager.pop()
   • Stack: [MapScene]

Conclusion

In this lesson, we've focused purely on high-level design, which is the essential first step to building a complex system. By planning our architecture now, we'll save ourselves countless headaches during implementation.

Your key takeaways on scene manager design are:

• The State Pattern: Encapsulate each game mode (map, menu, battle) into its own Scene object to keep code organized and decoupled.
• The Scene Interface: Define a standard contract (enter, exit, update, draw) that all Scene objects must follow, allowing the manager to control them without knowing their internal details.
• The State Stack: Use a stack (push, pop) instead of a simple change method to handle nested states like menus and to easily resume a previous state, which is crucial for JRPGs.
• Persistent Core: House global systems like the SceneManager itself in a persistent 'core' layer that is always active, while game scenes are loaded and unloaded on top of it.

You've now designed a clean, scalable, and professional architecture for managing your game's flow.

Preview of the next lesson:

With the blueprint complete, it's time to build. In our next lesson, "Implement the scene manager to transition between the map, a main menu, and back," we will translate these architectural designs into concrete JavaScript code and get our first scene transition working.