GS_Core

1 - Managers System

The Managers system is how GS_Play starts your game. The Game Manager spawns all other managers in a guaranteed order, coordinates their initialization stages, and then broadcasts events that signal when each stage is complete and when the game is fully ready to run.

This gives you the ability to ensure startup happens as expected, can create your own managers of any type, and can toggle full-game standby.

For architecture details, component properties, and extending the system in C++, see the GS_Managers API.

Contents

• Startup Sequence
• Headless Managers
• Responding to Startup
• Game Navigation
• Standby Mode
• Debug Mode
• Quick Reference
• Glossary
• See Also

Startup Sequence

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.

Headless Managers

There are two ways to run a manager, and the startup sequence above is only one of them.

Under a Game Manager, managers are spawned and coordinated as a stack. Headless is the alternative: tick the checkbox on a manager and it drives its own startup instead — no Game Manager anywhere in the project, no startup sequence to join.

1. Add the manager component to an entity in your level.
2. Tick Headless in the Entity Inspector.
3. Press play. The manager sets itself up and reaches startup-complete on its own.

This is how you deploy a single GS feature into a project that is not built on GS_Play. A project that wants GS_Audio’s audio system and nothing else adds the Audio Manager, ticks Headless, and has working audio — no manager stack, no game-flow layer, no dependency on the Game Manager’s startup. The same applies to a project that already has its own lifecycle, title flow and save system: those stay where they are, and the GS manager simply runs.

It also covers adopting the framework in stages — take one manager headless now, and switch it onto a Game Manager later if the project grows into the full lifecycle.

A headless manager does not report to the Game Manager, so it stays out of the startup count entirely. You can run one alongside a Game Manager that is coordinating everything else without the two interfering.

Two things to know when you go headless. A headless manager starts as soon as it activates, so the guarantee that every manager is initialized before any manager reaches setup does not apply — if you run several headless managers that depend on each other, that sequencing is yours to arrange, and a Game Manager is usually the better answer. And OnBeginGame is never self-fired: reaching startup-complete says the manager is ready, while saying the game has begun stays your project’s call.

Responding to Startup

ScriptCanvas

Connect to GameManagerNotificationBus and handle OnStartupComplete to know when the game is fully ready:

To check at any point whether the game has already finished starting, use the IsStarted request:

Game Navigation

The Game Manager owns the top-level game flow. Call these from title screens, pause menus, and end-game sequences. They coordinate the Save Manager and Stage Manager automatically.

Standby Mode

Standby is a global pause. The Game Manager enters standby automatically during level transitions and other blocking operations. It broadcasts OnEnterStandby to halt all gameplay systems, and OnExitStandby when the operation completes.

Listen to these in any script that drives continuous logic — timers, ticks, or animation sequences:

Both events are on GameManagerNotificationBus.

Debug Mode

When Debug Mode is enabled on the Game Manager component in the editor, the game starts in the current level instead of navigating to your title stage. This allows rapid iteration on any level without going through the full boot flow.

Debug Mode only changes startup navigation. All manager initialization and event broadcasting proceed normally.

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

For the full API, component properties, and C++ extension guide:

• Framework API: Game Manager
• Framework API: GS_Managers Overview
• Framework API: Manager

For step-by-step project setup:

• Simple Project Setup: Prepare Managers

Get GS_Core

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

2 - Save System

The Save system handles all persistence in a GS_Play project. The Save Manager coordinates file operations, Savers serialize per-entity state, and the Record Keeper tracks flat progression data. Together they give you a complete save/load pipeline that works out of the box and extends cleanly for custom data.

For architecture details, component properties, and extending the system in C++, see the Framework API reference.

Contents

• How Saving Works
• Responding to Save Events
• Triggering Saves and Loads
• Record Keeper
• Built-In Savers
• Quick Reference
• Glossary
• See Also

How Saving Works

Breakdown

When a save is triggered, the Save Manager broadcasts OnSaveAll to every Saver component in the scene. Each Saver serializes its entity’s relevant state into the save file. When loading, the Save Manager broadcasts OnLoadAll, and each Saver restores its entity from the save data.

The Save Manager also maintains a list of all save files with metadata (timestamps, names), so you can present a save/load UI to the player.

Operation	What Happens
New save	Creates a new save file, broadcasts OnSaveAll to all Savers.
Load save	Reads save file, broadcasts OnLoadAll to all Savers.
Save data	Writes current game state to the active save file.
Load data	Reads data from the active save file into memory.

E Indicates extensible classes and methods.

Patterns - Complete list of system patterns used in GS_Play.

Responding to Save Events

ScriptCanvas

Connect to SaveManagerNotificationBus to know when save or load operations occur:

Triggering Saves and Loads

These methods are available on SaveManagerRequestBus:

Record Keeper

The Record Keeper is a lightweight key-value store for tracking game-wide progression — quest flags, counters, unlock states, completion markers. It lives on the Save Manager prefab and is automatically persisted with the save system.

Unlike Savers (which are per-entity), the Record Keeper is a global singleton. Any script or component can read and write records by name.

Responding to Record Changes

Listen on RecordKeeperNotificationBus for the RecordChanged event. This fires whenever any record is created, updated, or deleted — useful for UI that displays progression state.

Built-In Savers

Two Savers ship with GS_Core for the most common use cases:

Add these components to any entity that needs to persist its position across save/load cycles. They handle serialization and restoration automatically.

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

For the full API, component properties, and C++ extension guide:

• Framework API: GS_Save
• Framework API: Save Manager
• Framework API: Record Keeper
• Framework API: Savers

For step-by-step project setup:

• Simple Project Setup: Prepare Managers

Get GS_Core

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

3 - Stage Management

The Stage Manager handles all level-to-level navigation in a GS_Play project. It owns the master list of stages, processes transition requests, and coordinates with the Game Manager’s standby mode to ensure clean load/unload cycles. Stage Data components in each level control how that level initializes.

For architecture details, component properties, and extension patterns, see the Framework API reference.

Contents

• How Stage Transitions Work
• Stage Data
• Triggering Stage Changes
• Exit Points
• Responding to Stage Events
• Entity Level Configuration
• Quick Reference
• Glossary
• See Also

How Stage Transitions Work

Breakdown

When you request a stage change, the system follows this sequence:

Step	What Happens
1 — Standby	The Game Manager enters standby, pausing all gameplay systems.
2 — Unload	The current stage’s entities are torn down.
3 — Spawn	The target stage’s prefab is instantiated.
4 — Set Up	The Stage Data component in the new level runs its layered startup sequence.
5 — Complete	The Stage Manager broadcasts LoadStageComplete. Standby exits.

The Stage Data startup is layered — SetUpStage, ActivateByPriority, then Complete — so heavy levels can initialize incrementally without causing frame-time spikes.

E Indicates extensible classes and methods.

Patterns - Complete list of system patterns used in GS_Play.

Stage Data

Each level should have a Stage Data component as its root entity. Using a start inactive child “Level” entity, the Stage Data system controls the initialization sequence for that new level. Stage Data holds level-specific configuration, and scripts.

Listen to these on StageDataNotificationBus in any script that needs to react to level lifecycle.

Triggering Stage Changes

ScriptCanvas

The exitPointName parameter is optional. If provided, the system will position the player at the named exit point in the target level.

Exit Points

Exit Points are named position markers placed in a level. They define where entities spawn when arriving from another stage. A door in Level A can specify that when transitioning to Level B, the player should appear at Exit Point “DoorB_Entry”.

Exit Points are registered and unregistered with the Stage Manager automatically when they activate and deactivate.

Responding to Stage Events

ScriptCanvas

Entity Level Configuration

The Stage Data entity must live outside of the levels Game Manager prefab. It is left active.

Inside, it has a secondary level “wrapper” entity that you set to “Start Inactive” by default. This enables the Stage Data to control exactly when the level begins loading.

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

For the full API, component properties, and C++ extension guide:

• Framework API: GS_StageManager
• Framework API: Stage Manager
• Framework API: Stage Data

For related systems:

• The Basics: GS_Managers

Get GS_Core

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

4 - Options & Input

The Options system covers two things a project needs and rarely wants to write itself:

• Settings — the options a player changes: volume, graphics, resolution, accessibility. You declare them as data and the framework applies, saves and restores them.
• Input — group-based input binding that can be rebound and toggled at runtime without code changes.

For architecture details, component properties, and extension patterns, see the Framework API reference.

Contents

• Options Manager
• Settings
• Input Profiles
• Enabling and Disabling Input Groups
• How Input Flows
• Quick Reference
• Glossary
• See Also

Options Manager

The Options Manager is the singleton that owns both halves of this system. It holds your option profiles and presets, and the active Input Profile. It responds to the Game Manager lifecycle automatically.

Assign three things to it: your option profiles, any presets, and your input profile.

Settings

Settings are the options a player changes — volume, graphics, resolution, accessibility. You declare them as data in an Options Profile asset, and the framework applies, saves and restores them.

Settings API

Input Profiles

An Input Profile is a data asset created in the O3DE Asset Editor. It contains named input groups, each holding a set of event mappings. Each event mapping binds a gameplay event name to one or more raw input bindings (key presses, axis movements, button presses) with configurable deadzones.

The key advantage over raw O3DE input bindings is the group system. Groups can be enabled and disabled independently at runtime — a pause menu can suppress gameplay input by disabling the “Gameplay” group, without tearing down and rebuilding bindings.

Enabling and Disabling Input Groups

ScriptCanvas

How Input Flows

Input Readers filter by group — if a group is disabled, none of its event mappings fire.

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

For the full API, component properties, and C++ extension guide:

• Framework API: GS_Options
• Framework API: Options Manager
• Framework API: Input Profiles

Get GS_Core

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

4.1 - Settings

Settings are the options a player changes — volume, graphics quality, resolution, accessibility choices. GS_Play lets you declare them as data and handles the rest: applying each one to the engine, saving them, and restoring them next launch.

You do not write loading code, saving code, or apply code. You author what the options are and what each one drives.

For architecture details and the full API, see the Framework API reference.

Contents

• Declaring Settings
• Reading and Writing Settings
• Presets
• Quick Reference
• Glossary
• See Also

Declaring Settings

Settings are authored as data, not code. Create an Options Profile asset and add an option for each thing your game exposes.

Every option carries:

Pick the option kind for the widget you want — a toggle, a slider with min/max/step, a dropdown with labelled entries, or a colour picker.

The apply target is the part worth pausing on. It is what connects the option to the engine: a console variable, the window mode, the resolution, an audio channel’s volume — or nothing at all, if the value is just something your own game code reads.

You can assign more than one profile. They merge by key, so a project can layer its own options over a supplied set.

Reading and Writing Settings

Setting a value applies it, saves it and notifies listeners in one call. You never have to apply or save separately.

GetOptionsByCategory is how you build a settings screen without hard-coding it — ask for the Graphics options and build a row per key.

A tip worth taking: the ImGui debug menu renders your entire option catalog live, with the right widget for each option. Author an option, press play, and drive it before you build any UI for it.

Presets

A preset is a named set of values — Low, Medium, High. Create a preset asset, list the keys it sets and the values it sets them to, and assign it to the Options Manager.

Applying a preset overwrites those options, applies and saves in one action.

Presets have no state of their own. A preset counts as active only while every value it names still matches, so the moment a player nudges one slider, the active preset becomes Custom. That is the familiar behaviour, and it happens for free.

Quick Reference

Glossary

See Also

For the full API:

• Framework API: Settings
• Framework API: Display & Window Modes

For related systems:

• The Basics: Options & Input — the input half of GS_Options
• The Basics: Debugging — the live options editor

Get GS_Core

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

5 - Systems

GS_Core provides a growing number of standalone systems that are used across multiple gems. Currently, the GS_Motion track-based animation engine powers UIAnimation and Juice Feedback playback.

For architecture details, component properties, and C++ extension guides, see the Framework API: Systems.

Contents

• GS_Motion
• See Also

GS_Motion

Provides tween-style Motion Track components for animating transforms, colors, and values over time. Multiple tracks on the same entity run in parallel; chains are configured by setting an On Complete motion name.

GS_Motion API

See Also

For the full API, component properties, and C++ extension guides:

• Framework API: Systems

For related systems:

• The Basics: Utilities
• The Basics: UI Animation
• The Basics: Juice

Get GS_Core

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

5.1 - Actions System

The Actions system provides a universal pattern for attaching discrete, reusable behaviors to entities and triggering them from any source — ScriptCanvas, World Triggers, UI buttons, or C++ code. Actions are data-driven components that fire on named channels, enabling composition without custom scripting.

For architecture details, component properties, and creating custom actions in C++, see the Framework API reference.

Contents

• How Actions Work
• Triggering Actions
• Built-In Actions
• Common Patterns
• Quick Reference
• Glossary
• See Also

How Actions Work

An Action is a component you attach to an entity. Each Action has a channel name. When something calls DoAction(channelName) on that entity’s bus, every Action component whose channel matches the name will execute.

This decoupling is the core value — the system that fires DoAction does not need to know what kind of action is attached. You can change, add, or remove action components on an entity without modifying any calling code.

Triggering Actions

ScriptCanvas

[ActionRequestBus → DoAction(channelName)]
    └─► All Action components on this entity with matching channel execute

To know when an action completes:

[ActionNotificationBus → OnActionComplete]
    └─► Action has finished executing

Built-In Actions

GS_Core ships with these ready-to-use actions:

Additional actions are available in other gems (e.g., World Trigger actions in GS_Interaction, dialogue effects in GS_Cinematics).

Common Patterns

World Trigger → Action

A World Trigger detects a collision or interaction event and fires DoAction on its entity. Action components on the same entity respond — one might play a sound, another might set a record, another might toggle an entity.

UI Button → Action

A UI button press fires DoAction with a channel name. Actions handle the response — navigate to a different UI page, start a new game, or toggle the pause menu.

Chaining Actions

Set an action’s “Chain Channel” property to fire a different channel when it completes:

Channel "OpenDoor" → [ToggleEntity action] → chains to "PlayDoorSound" → [AudioEvent action]

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

For the full API, component properties, and C++ extension guide:

• Framework API: GS_Actions
• Framework API: Core Actions

For related systems:

• The Basics: World Triggers

Get GS_Core

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

5.2 - Motion System

GS_Motion is a track-based animation engine built into GS_Core. It drives timed property changes — position, rotation, scale, color, opacity — through authored data assets rather than hand-coded interpolation scripts. Domain gems extend GS_Motion with their own track types: GS_UI adds 8 LyShine-specific tracks for UI animation, and GS_Juice adds transform and material tracks for game feel feedback.

For architecture details, the domain extension pattern, and all track types, see the Framework API reference.

Contents

• Key Concepts
• How It Works
• Domain Extensions
• Easing Curves
• Proxy Targeting
• Quick Reference
• Glossary
• See Also

Key Concepts

How It Works

1. Author a motion asset in the Asset Editor. Each domain has its own asset type (.uiam for UI, .feedbackmotion for Juice).
2. Assign the asset to a component or embed it in a serialized field (e.g., a page’s show/hide transitions).
3. Play the motion from ScriptCanvas or C++. The system initializes a runtime composite, resolves proxies, and ticks all tracks.
4. Each track receives an eased progress value (0 → 1) every frame and applies its property change to the target entity.
5. When all tracks complete, the motion fires its OnComplete callback.

Easing Curves

Every track can use any of the 40+ easing curves from the GS_Core curves library. Curves are configured per-track in the asset editor.

Available families: Linear, Quad, Cubic, Sine, Expo, Circ, Back, Elastic, Bounce — each with In, Out, and InOut variants.

Proxy Targeting

When a motion asset has tracks with identifiers (named labels), those tracks appear in the proxy list on the component. Proxies let you redirect a track to a different entity in the hierarchy — for example, a page show animation might animate the background separately from the content panel.

Each proxy entry maps a track label to a target entity. If no proxy is set, the track targets the motion’s owner entity.

Domain Extensions

GS_Motion is not used directly — it provides the base system that domain gems extend with concrete track types.

UI Animation (GS_UI)

Eight tracks for LyShine UI elements (position, scale, rotation, alpha, color, text). Asset extension: .uiam. Used for page transitions, button hover/select effects, and standalone UI animation.

UI Animation API

Feedback Motions (GS_Juice)

Two tracks for game feel effects — transform (position, scale, rotation) and material (opacity, emissive, color tint). Asset extension: .feedbackmotion. Used for screen shake, hit flash, and visual feedback.

Feedback Motions API

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

For the full API, component properties, and C++ extension guide:

• Framework API: GS_Motion

For related systems:

• The Basics: UI Animation
• The Basics: Juice
• The Basics: Utilities

Get GS_Core

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

6 - Utilities

GS_Core includes a library of general-purpose components and math helpers available to every system in the framework. These utilities handle common game development tasks — physics overlap detection, value interpolation, animation curves, gradient sampling, and spatial math — so you can focus on gameplay logic rather than reimplementing fundamental patterns.

For full API details and code examples, see the Framework API reference.

Contents

• Physics Trigger Volume
• Easing Curves
• Spring Dampers
• Gradients
• Entity Helpers
• Weighted Random
• Angle Helpers
• Spline Helpers
• Serialization Helpers
• Common Enums
• Glossary
• See Also

Physics Trigger Volume

A reusable physics overlap detector. Handles trigger enter, stay, and exit events with filtering and callback support. Used internally by Pulsors, Targeting Fields, and World Triggers — and available for your own components.

Physics Trigger Volume API

Easing Curves

40+ easing functions organized into families. Every GS_Motion track, spring, and interpolation system in the framework can reference these curves by enum.

Select a curve type via the CurveType enum in component properties, asset fields, or C++ code.

Curves API

Spring Dampers

15+ spring functions for physically-grounded value interpolation. Springs produce natural-feeling motion that reacts to velocity and acceleration, making them ideal for camera smoothing, UI follow, and any value that should “settle” rather than snap.

Springs API

Gradients

Multi-stop gradient types for sampling values over a range. Used extensively by GS_Motion tracks and GS_Juice feedback tracks to define animation curves.

Gradients are editable in the Inspector with visual marker placement.

Gradients API

Entity Helpers

Utility functions for finding entities in the scene by name.

Entity Helper API

Weighted Random

Template-based weighted random selection. Given a collection of items with weights, returns a randomly selected item biased by weight. Useful for loot tables, dialogue variation, and procedural placement.

GS_Random API

Angle Helpers

Functions for angle and orientation math, plus 22 preset section configurations for direction classification.

Section presets range from 2-section (left/right) to 16-section (compass-style), plus diagonal and cardinal configurations. Useful for animation direction selection and 2D-style facing.

Angle Helper API

Spline Helpers

Utility functions for working with O3DE spline components.

Spline Helper API

Serialization Helpers

Utility functions for common O3DE serialization patterns. Simplifies working with SerializeContext and EditContext in component reflection.

Serialization Helper API

Common Enums

Shared enumeration types used across the framework.

Common Enums API

Glossary

For full definitions, see the Glossary.

See Also

For the full API, component properties, and code examples:

• Framework API: Utilities

For related systems:

• The Basics: GS_Motion
• The Basics: Juice

Get GS_Core

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

7 - Debugging

Two things make working on a GS_Play project faster: Debug Mode, which lets you press play on the level you are editing instead of booting the whole game, and the in-game GS_Play menu, which lets you see and change what the framework is doing while it runs.

For architecture details and the extension guide, see the Framework API reference.

Contents

• Debug Mode
• The In-Game Menu
• Making a Manager Talk
• Quick Reference
• Glossary
• See Also

Debug Mode

Tick Debug Mode on your Game Manager and pressing play runs this level, right now.

Without it, a project boots the way a shipped game does: it starts up, waits for the game to be begun, then loads the configured starting stage and navigates away from whatever you were editing.

With it, three things change:

The net effect is that you get a running, playable level without a title screen or a stage transition.

The In-Game Menu

Run the game with ImGui enabled and there is a GS_Play entry in the menu bar. Each gem contributes its own section.

The Options window is the fastest way to test a new setting. Author the option, press play, and drive it from the menu — before writing any menu UI of your own. Every edit goes through the same bus your UI will use, so if it works there it will work in your game.

The Audio Mixer is similarly useful for balancing: run the game, play the sounds, and move the channel sliders until the mix is right.

Making a Manager Talk

Every manager has a Logging Depth property. Set it above zero and that manager reports its lifecycle as it activates, sets up and shuts down.

This is per-manager on purpose. When you are diagnosing one system’s startup, turn it up on that manager rather than making the whole framework verbose.

Quick Reference

Glossary

See Also

For the full API and the extension guide:

• Framework API: Debug Mode
• Framework API: ImGui Debug Menu

For related systems:

• The Basics: GS_Managers — where Debug Mode and Logging Depth live
• The Basics: Settings — what the Options window edits

Get GS_Core

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