GS_Managers

The Managers system is the backbone of every GS_Play project. It provides a controlled startup sequence that initializes game systems in the correct order, global access to those systems via EBus, and systemic navigation (New Game, Load Game, Quit) from a single point of control.

Every GS_Play gem that has a manager component (Save, Stage, UI, Unit, Camera, Audio, etc.) plugs into this system automatically.

For usage guides and setup examples, see The Basics: GS_Core.

 

Contents

• Architecture
• Components
• Quick Start
• See Also

---

Architecture

Breakdown

When the project starts, the Game Manager runs three stages before the game is considered ready:

Stage	Broadcast Event	What It Means
1 — Initialize	(internal)	Each manager is spawned. They activate, then report ready.
2 — Setup	OnSetupManagers	Setup stage. Now safe to query other managers.
3 — Complete	OnStartupComplete	Last stage. Everything is ready. Do any last minute things. Now safe to begin gameplay.

For most scripts, you only need OnStartupComplete. Wait for this event before doing anything that depends on managers to be completely setup.

E Indicates extensible classes and methods.

Patterns - Complete list of system patterns used in GS_Play.

---

Components

Component	Purpose	Reference
GS_GameManagerComponent	Top-level lifecycle controller. Spawns managers, handles New Game / Load / Quit / Standby.	Game Manager
GS_ManagerComponent	Base class for all game system managers. Handles the two-stage init pattern automatically.	Manager

---

Quick Start

For step-by-step setup, see Game Manager — Setup and Manager — Setup.

For creating custom managers, see Manager — Extending the Manager Class.

---

See Also

For conceptual overviews and usage guides:

• The Basics: GS_Managers

For component references:

• Game Manager
• Manager

For related resources:

• Templates

---

Get GS_Core

GS_Core — Explore this gem on the product page and add it to your project.

1 - Game Manager

The Game Manager is the root component of every GS_Play project. It controls the game lifecycle from startup through shutdown: spawning and initializing all Manager components in the correct order, providing systemic navigation (New Game, Load Game, Return to Title, Quit), and coordinating standby mode for pausing gameplay during level transitions or other blocking operations.

Every level in your project should contain the same Game Manager prefab. In debug mode it stays in the current level on start; in release mode it navigates to your title stage.

For usage guides and setup examples, see The Basics: GS_Core.

The Game Manager component in the Entity Inspector, with added manager prefabs in the Startup Managers list.

Contents

• Design Intent
• Dependencies & Interactions
• Setup
• Core Concepts
• Inspector Properties
• API Reference
• SC ↔ C++ Quick Reference
• Usage Examples
• Extending the Game Manager
• See Also

Design Intent

Extend the Game Manager when you need project-wide changes to startup ordering, custom post-startup logic (analytics sessions, online service initialization), or additional global lifecycle events. For most projects, the built-in component is sufficient as-is. Do not move gameplay logic here — the Game Manager orchestrates systems, it does not run game rules.

Dependencies & Interactions

Setup

Game Manager Entity

The Game Manager wrapper entity set as Editor-Only inside Prefab Edit Mode.

1. Create an entity and attach the GS_GameManagerComponent (or your extended version).
2. Turn the entity into a prefab.
3. Enter prefab edit mode. Set the wrapper entity (the parent of your Game Manager entity) to Editor Only. Save the prefab.
4. Create Manager prefabs for the systems you need (Save, Stage, Options, or custom managers).
5. Add each Manager .spawnable to the Game Manager’s Startup Managers list in the Entity Inspector.
6. Push your overrides into the prefab to propagate across all levels.

Place your Game Manager prefab at the top of every level in the Entity Outliner.

The premade manager prefabs for each GS_Play gem are located in that gem’s Assets/Prefabs directory.

Core Concepts

Startup Sequence

When the project starts, the Game Manager executes a three-stage startup:

1. Spawn Managers — The Game Manager instantiates every prefab in its Startup Managers list. Each manager component runs its Activate() and reports back via OnRegisterManagerInit().
2. Setup Managers — Once all managers report initialized, the Game Manager broadcasts OnSetupManagers(). Managers now connect to each other and report back via OnRegisterManagerSetup().
3. Startup Complete — Once all managers report setup, the Game Manager broadcasts OnStartupComplete(). The framework is fully initialized and ready to run.

At each stage, the Game Manager counts reports and only proceeds when every spawned manager has reported. This guarantees safe cross-referencing between managers in Stage 2.

Shutdown mirrors the same shape: OnShutdownManagers() is broadcast, and each manager reports back via OnRegisterManagerShutdown().

OnBeginGame() sits outside this sequence. Startup completing means the framework is ready; beginning the game is a separate cue your project fires when play actually starts.

A project can also be configured without a Game Manager at all — headless managers drive their own startup, so the Game Manager can be skipped altogether.

Systemic Navigation

The Game Manager provides the high-level game flow methods that drive your project:

• NewGame / NewGame(saveName) — Starts a new game, optionally with a named save file.
• ContinueGame — Loads the most recent save and continues.
• LoadGame(saveName) — Loads a specific save file.
• ReturnToTitle — Returns to the title stage, tearing down the current game session.
• SaveAndExitGame / ExitGame — Saves and/or exits the application.

These methods coordinate with the Save Manager and Stage Manager automatically.

Standby Mode

Standby is a global pause mechanism. When the Game Manager enters standby, it broadcasts OnEnterStandby() to all managers, which propagate the signal to their subsystems. This halts timers, physics, gameplay ticks, and other simulation while a blocking operation (like a stage change) completes. Calling ExitStandby reverses the process.

Debug Mode

When Debug Mode is enabled in the Inspector, the Game Manager skips navigating to the title stage and remains in the current level. This allows rapid iteration — you can start the game from any level without going through the full title-to-gameplay flow. If save data and unit management are enabled, it loads default save data but overrides position data with the current level’s default spawn point.

Inspector Properties

API Reference

Request Bus: GameManagerRequestBus

Commands sent to the Game Manager. Singleton bus — single address, single handler.

Notification Bus: GameManagerNotificationBus

Events broadcast by the Game Manager. Multiple handler bus — any number of components can subscribe.

ScriptCanvas Nodes

These methods and events are available as ScriptCanvas nodes.

Request Nodes

Notification Nodes

Listen for these events on GameManagerNotificationBus.

Virtual Methods

Override these when extending the Game Manager. Always call the base implementation.

SC ↔ C++ Quick Reference

Usage Examples

ScriptCanvas: Title Screen Workflow

Calling new or load game proceedes to start the gameplay and systems. Begin Game event fires to start all systems across the game.

Debug Mode automatically begins the game.

ScriptCanvas: Standby Logic

C++: Reacting to Events

A gameplay component that listens to the full startup and standby lifecycle:

#include <GS_Core/GS_CoreBus.h>

class MyGameplayComponent
    : public AZ::Component
    , protected GS_Core::GameManagerNotificationBus::Handler
{
protected:
    void Activate() override
    {
        GS_Core::GameManagerNotificationBus::Handler::BusConnect();
    }

    void Deactivate() override
    {
        GS_Core::GameManagerNotificationBus::Handler::BusDisconnect();
    }

    void OnStartupComplete() override
    {
        // Safe to access all managers and begin gameplay logic
    }

    void OnEnterStandby() override
    {
        // Pause your gameplay systems
    }

    void OnExitStandby() override
    {
        // Resume your gameplay systems
    }
};

C++: Custom Manager Integration

A manager that receives the startup handshake from the Game Manager. Add this class’s prefab to the Game Manager’s Startup Managers list:

#include <GS_Core/GS_CoreBus.h>
#include <Source/Managers/GS_ManagerComponent.h>

class MySystemManager
    : public GS_Core::GS_ManagerComponent
    , protected GS_Core::GameManagerNotificationBus::Handler
{
public:
    AZ_COMPONENT_DECL(MySystemManager);
    static void Reflect(AZ::ReflectContext* context);

protected:
    void Activate() override
    {
        GS_Core::GS_ManagerComponent::Activate();                        // Required: registers with Game Manager
        GS_Core::GameManagerNotificationBus::Handler::BusConnect();
    }

    void Deactivate() override
    {
        GS_Core::GameManagerNotificationBus::Handler::BusDisconnect();
        GS_Core::GS_ManagerComponent::Deactivate();                      // Required: deregisters from Game Manager
    }

    // Called during Stage 2 — safe to reference other managers here
    void OnSetupManagers() override
    {
        // Connect to other managers, set up cross-system references
    }

    // Called when the full startup sequence completes — safe to begin gameplay
    void OnStartupComplete() override
    {
        // Initialize systems that depend on all managers being ready
    }

    void OnEnterStandby() override { /* pause your systems */ }
    void OnExitStandby()  override { /* resume your systems */ }
};

Extending the Game Manager

Extend the Game Manager to add custom startup logic, additional lifecycle events, or project-specific behavior. Extension is done in C++.

Header (.h)

#pragma once
#include <GS_Core/GS_CoreBus.h>
#include <Source/Managers/GS_GameManagerComponent.h>

namespace MyProject
{
    class MyGameManager : public GS_Core::GS_GameManagerComponent
    {
    public:
        AZ_COMPONENT_DECL(MyGameManager);

        static void Reflect(AZ::ReflectContext* context);

    protected:
        void InitializeManagers() override;
        void StartupManagers() override;
        void CompleteStartup() override;
        void BeginGame() override;
    };
}

Implementation (.cpp)

#include "MyGameManager.h"
#include <AzCore/Serialization/SerializeContext.h>

namespace MyProject
{
    AZ_COMPONENT_IMPL(MyGameManager, "MyGameManager", "{YOUR-UUID-HERE}");

    void MyGameManager::Reflect(AZ::ReflectContext* context)
    {
        if (auto serializeContext = azrtti_cast<AZ::SerializeContext*>(context))
        {
            serializeContext->Class<MyGameManager, GS_Core::GS_GameManagerComponent>()
                ->Version(0);

            if (AZ::EditContext* editContext = serializeContext->GetEditContext())
            {
                editContext->Class<MyGameManager>("My Game Manager", "Custom game manager for MyProject")
                    ->ClassElement(AZ::Edit::ClassElements::EditorData, "")
                        ->Attribute(AZ::Edit::Attributes::Category, "MyProject")
                        ->Attribute(AZ::Edit::Attributes::AppearsInAddComponentMenu, AZ_CRC_CE("Game"));
            }
        }
    }

    void MyGameManager::InitializeManagers()
    {
        // Call base to spawn the standard manager list
        GS_GameManagerComponent::InitializeManagers();
        // Custom initialization logic here
    }

    void MyGameManager::StartupManagers()
    {
        // Call base to handle standard startup
        GS_GameManagerComponent::StartupManagers();
    }

    void MyGameManager::CompleteStartup()
    {
        // Call base to broadcast OnStartupComplete
        GS_GameManagerComponent::CompleteStartup();
        // Post-startup logic here (e.g. connect to analytics, initialize online services)
    }

    void MyGameManager::BeginGame()
    {
        GS_GameManagerComponent::BeginGame();
        // Custom game start logic
    }
}

See Also

For scripting patterns and SC-first usage:

• The Basics: GS_Managers

For related components:

• Manager Base Class
• GS_Managers Overview
• Save Manager
• Stage Manager
• Templates

Get GS_Core

GS_Core — Explore this gem on the product page and add it to your project.

2 - Manager

For usage guides and setup examples, see The Basics: GS_Core.

A Manager prefab with the wrapper entity set as Editor-Only inside Prefab Edit Mode.

GS_GameManager
  └── (spawns) GS_ManagerComponent ◄ you are here — and all other managers extend this

The GS_ManagerComponent is the base class that all game system managers inherit from. It handles the two-stage initialization pattern with the Game Manager automatically, so you can focus on your system’s logic without worrying about startup ordering.

Every built-in GS_Play manager (Save, Stage, Options, UI, Unit, Camera, Audio, Performer) extends this class. When you need a custom game system manager, you extend it too.

Contents

• How It Works
• Headless Managers
• Setup
• Inspector Properties
• API Reference
• Usage Examples
• Extending the Manager Class
• See Also

How It Works

The Game Manager drives startup in stages. At each stage it calls out to every manager over GameManagerNotificationBus, each manager performs its own logic, and each reports back over GameManagerRequestBus when it is done. The Game Manager counts those reports and only advances to the next stage once every manager has answered.

That counting handshake is the point of the system: no manager advances until every manager has registered, which is what makes cross-manager dependencies safe without you having to specify an order.

1. Activate — The component initializes itself (connects to buses, sets up internal state). When done it broadcasts OnRegisterManagerInit() to tell the Game Manager it is ready.

2. OnSetupManagers — Called by the Game Manager once every manager has reported initialized. Connect to other managers and set up cross-references here. When done it broadcasts OnRegisterManagerSetup().

3. OnStartupComplete — Broadcast by the Game Manager once every manager has reported setup. The framework is fully ready. The base implementation is empty — override it to begin runtime operation.

4. OnBeginGame — Broadcast when the game itself begins. This is a cue, not a state: it is fired when your project decides play has actually started, which is a separate question from whether the managers finished starting up.

5. OnEnterStandby / OnExitStandby — Called when the Game Manager enters or exits standby mode. Pause and resume your subsystem here.

6. OnShutdownManagers — Called when the game is shutting down. Clean up resources and disconnect buses. When done it broadcasts OnRegisterManagerShutdown().

The base class handles the registration side of steps 1, 2 and 6 for you. Override the hooks to add your logic, then call the base implementation to complete the handshake.

Headless Managers

Headless is the second way to run a manager, and it is a full alternative to the Game Manager — not a reduced one.

Every manager carries a Headless checkbox. Tick it and that manager takes responsibility for its own startup instead of being driven by a Game Manager:

Activate()
  └── calls OnSetupManagers() itself
        └── calls OnStartupComplete() itself

Deactivate()
  └── calls OnShutdownManagers() itself, then disconnects

The registration calls are skipped entirely — there is no Game Manager to report to, so the manager simply advances itself through each stage.

It reaches startup-complete under its own power, with no Game Manager in the project and no startup sequence to participate in. Everything the manager does after that point behaves exactly as it does under the Game Manager.

Why you would use it

The Game Manager path exists because a GS_Play game wants one coordinated startup across a stack of managers. A project that only wants one feature does not need any of that.

Headless is how a GS feature gem is deployed into a project that is not built on GS_Play:

• Deploying a single feature manager. A project that wants GS_Audio’s audio system — and nothing else — adds the Audio Manager, ticks Headless, and has a working audio system. No Game Manager, no manager stack, no game-flow layer, no dependency on the GS_Play startup sequence.
• Adding GS features to an existing project that already has its own game lifecycle, title flow and save system. Those responsibilities stay where they are; the GS manager simply starts itself and does its job.
• Adopting the framework in stages. Take one manager now, headless. Add a Game Manager later and switch it over when the project is ready for the full lifecycle.
• Runtimes with no game session at all — servers, tools, editor-side scenes.

Both routes are supported deployments. Use the Game Manager when you want the coordinated startup it provides; use Headless when a manager should simply run.

What you take on

The Game Manager’s counting handshake is what guarantees that no manager reaches setup until every manager has initialized. A headless manager has no such barrier — it drives straight through its own chain the moment it activates, independently of anything else in the level.

For a single deployed manager that is exactly what you want. If you run several headless managers that depend on each other, sequencing between them becomes your project’s responsibility. At that point, consider a Game Manager instead — coordinating a manager stack is the problem it exists to solve.

OnBeginGame is never self-fired. Setup and startup are infrastructure a manager can honestly resolve alone, but “the game has begun” is a cue rather than a state — it stays a signal the host project fires when it decides play has started. A headless manager reaches startup-complete and waits.

A headless manager does not report to the Game Manager at all — it self-drives instead of registering, so it takes no part in the counting handshake and cannot disturb one that is running. A project is free to have a Game Manager coordinating a manager stack and a headless manager running alongside it.

The flag lives on the base class, so it is inherited by every manager — Audio, Options, Cam, Save, Stage and any custom manager you write. One uniform mechanism, no per-gem variation.

A subclass that overrides OnSetupManagers, OnStartupComplete or OnShutdownManagers must still chain to the base implementation exactly as before. Headless changes who calls the hooks, not the contract.

Setup

The Manager wrapper entity set as Editor-Only inside Prefab Edit Mode.

1. Create an entity. Attach your Manager component (built-in or custom) to it.
2. Configure any properties needed in the Entity Inspector.
3. Turn the entity into a prefab.
4. Enter prefab edit mode. Set the wrapper entity (parent of your Manager entity) to Editor Only. Save.
5. Delete the Manager entity from the level (it will be spawned by the Game Manager at runtime).
6. In the Game Manager prefab, add your Manager .spawnable to the Startup Managers list.

The premade manager prefabs for each GS_Play gem are located in that gem’s Assets/Prefabs directory.

Inspector Properties

The base GS_ManagerComponent contributes two properties to every manager that inherits it. All other properties are defined by the inheriting component (e.g. the Save Manager exposes a Save System Version Number, the Stage Manager exposes a Stages list).

API Reference

Lifecycle Events: GameManagerNotificationBus

The Manager base class automatically subscribes to these events from the Game Manager:

Registration Methods

Called by the Manager base class to report back to the Game Manager over GameManagerRequestBus. Do not call these manually — call the base class method instead and it reports for you.

Manager Base Buses

Separate from the Game Manager handshake, GS_ManagerBus.h declares a small pair of buses that let non-manager components react to their gem’s manager without participating in the startup count.

ManagerBaseNotifications:

ManagerBaseRequests:

Usage Examples

C++ — Checking if the Game Manager Is Ready

#include <GS_Core/GS_CoreBus.h>

bool isStarted = false;
GS_Core::GameManagerRequestBus::BroadcastResult(
    isStarted,
    &GS_Core::GameManagerRequestBus::Events::IsStarted
);

if (isStarted)
{
    // Safe to access all managers
}

Extending the Manager Class

Create a custom manager whenever you need a singleton game system that initializes with the rest of the framework. Extension is done in C++.

Header (.h)

#pragma once
#include <GS_Core/GS_Manager/GS_ManagerComponent.h>

// Define your EBus interface for other systems to call your manager
class MyManagerRequests
{
public:
    AZ_RTTI(MyManagerRequests, "{YOUR-UUID-HERE}");
    virtual ~MyManagerRequests() = default;

    virtual int GetSomeValue() = 0;
    virtual void DoSomething() = 0;
};

class MyManagerBusTraits : public AZ::EBusTraits
{
public:
    static constexpr AZ::EBusHandlerPolicy HandlerPolicy = AZ::EBusHandlerPolicy::Single;
    static constexpr AZ::EBusAddressPolicy AddressPolicy = AZ::EBusAddressPolicy::Single;
};

using MyManagerRequestBus = AZ::EBus<MyManagerRequests, MyManagerBusTraits>;

namespace MyProject
{
    class MyManagerComponent
        : public GS_Core::GS_ManagerComponent
        , protected MyManagerRequestBus::Handler
    {
    public:
        AZ_COMPONENT_DECL(MyManagerComponent);

        static void Reflect(AZ::ReflectContext* context);

    protected:
        // Manager lifecycle
        void Activate() override;
        void Deactivate() override;
        void OnSetupManagers() override;
        void OnEnterStandby() override;
        void OnExitStandby() override;

        // Your bus implementation
        int GetSomeValue() override;
        void DoSomething() override;

    private:
        int m_someValue = 0;
    };
}

Implementation (.cpp)

#include "MyManagerComponent.h"
#include <AzCore/Serialization/SerializeContext.h>

namespace MyProject
{
    AZ_COMPONENT_IMPL(MyManagerComponent, "MyManagerComponent", "{YOUR-UUID-HERE}");

    void MyManagerComponent::Reflect(AZ::ReflectContext* context)
    {
        if (auto serializeContext = azrtti_cast<AZ::SerializeContext*>(context))
        {
            serializeContext->Class<MyManagerComponent, GS_Core::GS_ManagerComponent>()
                ->Version(0)
                ->Field("SomeValue", &MyManagerComponent::m_someValue);

            if (AZ::EditContext* editContext = serializeContext->GetEditContext())
            {
                editContext->Class<MyManagerComponent>("My Manager", "A custom game system manager")
                    ->ClassElement(AZ::Edit::ClassElements::EditorData, "")
                        ->Attribute(AZ::Edit::Attributes::Category, "MyProject")
                        ->Attribute(AZ::Edit::Attributes::AppearsInAddComponentMenu, AZ_CRC_CE("Game"))
                    ->DataElement(AZ::Edit::UIHandlers::Default,
                        &MyManagerComponent::m_someValue, "Some Value", "Description of this property");
            }
        }
    }

    void MyManagerComponent::Activate()
    {
        MyManagerRequestBus::Handler::BusConnect();

        // IMPORTANT: Call base Activate last — it reports OnRegisterManagerInit()
        GS_ManagerComponent::Activate();
    }

    void MyManagerComponent::Deactivate()
    {
        MyManagerRequestBus::Handler::BusDisconnect();
        GS_ManagerComponent::Deactivate();
    }

    void MyManagerComponent::OnSetupManagers()
    {
        // Access other managers here — they are all initialized by now

        // IMPORTANT: Call base last — it reports OnRegisterManagerSetup()
        GS_ManagerComponent::OnSetupManagers();
    }

    void MyManagerComponent::OnEnterStandby()
    {
        // Pause your subsystem
    }

    void MyManagerComponent::OnExitStandby()
    {
        // Resume your subsystem
    }

    int MyManagerComponent::GetSomeValue()
    {
        return m_someValue;
    }

    void MyManagerComponent::DoSomething()
    {
        // Your game system logic
    }
}

Module Registration

m_descriptors.insert(m_descriptors.end(), {
    MyProject::MyManagerComponent::CreateDescriptor(),
});

Then create a prefab for your manager and add it to the Game Manager’s Startup Managers list.

See Also

For conceptual overviews and usage guides:

• The Basics: GS_Managers
• GS_Managers Overview

For component references:

• Game Manager
• Save Manager
• Stage Manager

For related resources:

• Templates

Get GS_Core

GS_Core — Explore this gem on the product page and add it to your project.