GS_Play Gameplay Framework for O3DE

1 - Get Started

GS_Play is an intermediate-to-advanced gameplay framework for O3DE. It is a modular, production-ready set of feature gems you enable individually — bring in only what your project needs. Every feature set is built on simple, consistent patterns so you can reason about what the system can do and extend it precisely, without having to understand every internal detail first.

This section covers the essentials: what GS_Play is designed for, how to get a project running, and the conventions that will help you work with the framework effectively.

How This Section Is Organized

Understanding GS_Play — What GS_Play is, what genres and use cases it targets, and how to think about its modularity and pattern-first design. A good first read if you are new to the framework or evaluating whether it suits your project.

Project Quick Start — A step-by-step lesson covering the minimum setup for a working GS_Play project: gem installation, manager configuration, camera setup, and startup sequence. Follow this to get from a blank O3DE project to a running game loop.

Best Practices — Conventions and instincts worth developing early. Covers prefab wrapper structure, how to orient yourself using the Patterns index, and other framework-level habits that prevent common friction points.

Sections

1.1 - Understanding GS_Play

1.2 - Project Quick Start

1.3 - Best Practices

A short list of habits worth building early. None of these are gatekept by the framework, but skipping them tends to create friction that is annoying to untangle later.

Follow the Feature Patterns

Every GS_Play feature set has a defined pattern — a simple, consistent way to think about how its pieces connect. Before diving into a new feature, spend a few minutes with its pattern diagram. Once the pattern clicks, the rest of the documentation becomes much easier to navigate and the editor setup becomes obvious.

The Patterns Index has diagrams and breakdowns for every major feature. If you are ever confused about why something is structured the way it is, the pattern page is the first place to look.

Configure Every Level the Same Way

Every level in your project should follow the same base configuration as established in the Simple Project Setup guide:

• A Game Manager prefab placed in the level.
• A StageData component configured for the level.
• An inactive child Level entity holding the level’s content, activated by the Stage Manager startup sequence.

This is the standard GS_Play level structure. Deviating from it will cause the startup sequence, stage transitions, and manager initialization to behave unexpectedly.

Leave Debug Mode on in the Game Manager prefab during development. Debug Mode bypasses the normal startup sequence and drops you directly into the level in a pre-started state, which is far faster for iteration. Disable it only when you need to test the full startup flow.

Use the Class Creation Wizard and Templates

GS_Play extension types — custom conditions, effects, performances, pulse types, trigger sensors, and more — should always be generated using the O3DE Class Creation Wizard with the GS_Play templates, not written from scratch.

The wizard handles UUID generation, cmake file-list registration, and module descriptor injection automatically. Hand-written extension classes frequently miss one of these steps, causing hard-to-diagnose startup failures.

The full template list is in the Templates Index.

Seed LLM Agents with the Agentic Guidelines

If you are using an LLM coding agent to work with GS_Play code, provide it with the Agentic Guidelines document as a bootstrap seed at the start of the session.

The document is structured for agent parsing — it establishes the GS_Play domain model, hard invariants that override general O3DE knowledge, and context anchors for specific subsystems. An agent working without it will frequently make plausible-but-wrong assumptions about how GS_Play components and EBuses are structured.

Ask for Help

If you are blocked on anything — setup, a framework concept, a bug, or something the documentation does not cover clearly — reach out. We want to make sure you are never stuck long enough for it to derail your project.

The fastest route is the #support channel on Discord. You will get a real response, not a bot. No question is too small.

Prefab Wrappers Are Editor Only

Whenever GS_Play documentation refers to a Prefab, it is implied that the Prefab wrapper entity (the blue root entity in the O3DE editor) is set to Editor Only.

This applies universally — and is especially important for GS_Managers. The wrapper entity is for editor organization and prefab identity. It should never be a live runtime entity.

Set this in the Entity Inspector: Entity Status → Editor Only.

1.4 - Agentic Guidelines

BOOTSTRAP PROTOCOL

On first load of this document, execute in order:

1. Read all [INVARIANT] entries. Hard constraints. Load before any code generation.
2. Read SYSTEM ONTOLOGY and GEM INDEX to establish the domain model.
3. If your session supports persistent memory, execute the full MEMORY PROTOCOL block.
4. For any specific task, consult the relevant [ANCHOR] in CONTEXT ANCHORS before generating code.

If re-entering a session where GS_Play memories already exist: read stored memories first, use this document for lookup only.

INVARIANTS

Non-negotiable. Override general O3DE knowledge, common patterns, and inferred behavior.

[INVARIANT] No Unicode. Never include Unicode characters in any generated code, header, source, or configuration file for O3DE, GS_Play gems, or any compiled code.

[INVARIANT] Polymorphic containers require raw pointers. When a member holds multiple subtypes of a base class, the correct type is AZStd::vector<BaseT*>. Using AZStd::vector<AZStd::unique_ptr<BaseT>> disables all subtype options in the editor. No exceptions.

[INVARIANT] EnableForAssetEditor lives only in SerializeContext. It must appear directly under ->Version() in the SerializeContext block. Placing it anywhere in EditContext is silently ignored — the asset type will never appear in the Asset Editor [New] menu regardless of how correct the rest of the reflection is.

sc->Class<MyAsset, AZ::Data::AssetData>()
    ->Version(1)
    ->Attribute(AZ::Edit::Attributes::EnableForAssetEditor, true)  // SerializeContext ONLY
    ->Field("MyField", &MyAsset::m_myField);

[INVARIANT] Use the O3DE Class Creation Wizard for new components. Generate skeleton from wizard, then use find-and-replace to customize. Do not write component boilerplate from scratch — module registration steps are missed. Unnecessary tokens are spent.

[INVARIANT] EBus interface names are exact. Never infer or guess an EBus name. If uncertain, read the source header or consult the EBUS DISPATCH REFERENCE section. Wrong names fail silently at runtime.

[INVARIANT] Namespace all GS_Play code. Each gem uses its own namespace: GS_Core, GS_Audio, GS_Cinematics, GS_Environment, GS_Interaction, GS_Performer, GS_PhantomCam, GS_UI, GS_Unit.

[INVARIANT] Using O3DE code sensibilities. Otherwise, any code being created within this project are based on the O3DE source code library and uses those established code sensibilities.

[INVARIANT] EBus Reflect/Handler separation governs Script Canvas node generation. In Script Canvas: reflected EBus events become caller nodes (invoke the bus). Handler class declarations become notification nodes (listen for events). Apply the minimum necessary:

• Respond-only — Inherit from {BusName}::Handler, override virtual methods. Do NOT reflect caller events. No SC caller node is generated or needed.
• Call-only — Reflect the EBus events in Reflect(). Do NOT inherit Handler in the component. No SC notification node is generated or needed.
• Both — Inherit Handler (generates notification nodes) AND reflect events (generates caller nodes).

Generating both when only one is needed pollutes the SC node palette and signals incorrect intent to maintainers.

MEMORY PROTOCOL

[MEMORY] If your system supports persistent memory, create or verify these entries at session start:

At session end: If you discovered or confirmed any EBus method signatures, component property names, or TypeIds, ask the user: “Should I save what I learned about [topic] to memory?”

Memory freshness rule: If a stored memory conflicts with source code you have read during a session, source code is authoritative. Update the memory.

If no memory system is available: Re-read this document at the start of every new GS_Play session before generating any code.

SYSTEM ONTOLOGY

What this system is: gs_play_gems is a modular O3DE gameplay framework in C++17. It provides game systems as base classes for developer extension. It is a framework, not a library — the expected pattern is: extend base classes, override virtual methods, communicate exclusively via EBus.

Core architectural rules:

• Each Gem is a self-contained feature module. GS_Complete is the framework’s reference integration layer demonstrating cross-gem patterns — it is not a required home for your project code.
• Runtime cross-gem communication between GS_Play framework components uses EBus. Your own project code may include and combine gem headers as needed.
• All game systems are singleton Manager Components responding to GameManagerNotificationBus lifecycle events.
• Extensible type systems (dialogue effects, pulse types, motion tracks) use polymorphic base classes. Extend the base class and reflect it — types are discovered automatically through O3DE serialization at startup.
• All user-facing data must be reflected via SerializeContext + EditContext.

CLASS WIZARD PROTOCOL

[INVARIANT] Always use the Class Creation Wizard CLI for new component, asset, and system class generation. The wizard handles file scaffolding, CMake registration, module descriptor insertion, and system component wiring. Manual boilerplate misses registration steps and wastes tokens.

CLI invocation (agents use CLI mode only)

python ClassWizard.py \
  --engine-path  <engine-path> \
  --project-path <project-path> \
  --template     <template_name> \
  --component-name <Name> \
  --namespace      <GemNamespace> \
  --automatic-register \
  [<template-specific flags>]

--automatic-register is required for build integration (CMake file lists, module descriptors, system component entries). Omitting it generates files only.

Available templates — O3DE base

Available templates — GS_Play extensions

GS_Play provides gem-specific templates that extend the above. These handle GS_ base class wiring, EBus interface generation, and framework-specific registration steps automatically. Full reference: Templates List.

[ANCHOR] Registration requirements per template (some require a manual Reflect() call after generation) → Templates List: Registration Quick Reference

What the wizard generates

The wizard output for --template default_component --component-name PlayerHealth --namespace GS_Core produces:

• Source/PlayerHealthComponent.h / .cpp — component with Reflect(), Activate(), Deactivate(), AZ_COMPONENT_IMPL
• Include/GS_Core/PlayerHealthInterface.h — EBus interface header (unless --skip-interface)
• CMake file list entries, module descriptor registration (with --automatic-register)

Post-wizard agent workflow

After the wizard runs:

1. Add GS_ base class to the inheritance list alongside AZ::Component.
2. Add EBus handler inheritance for any buses this component listens to.
3. Wire BusConnect() / BusDisconnect() in Activate() / Deactivate().
4. Override virtual methods from the GS_ base class.
5. Add reflected fields in SerializeContext → EditContext.
6. Add gem dependency if the component depends on another GS_ gem: add_gem_dependency is automatic for some templates (e.g., LyShine), but cross-GS-gem dependencies must be added manually to CMake.

[ANCHOR] Before customizing wizard output → read the target base class API at /docs/framework/{gem}/.

Discovery commands

--list-templates                   # Print all available templates
--template-help <template_name>    # Print full command shape, all flags, and command list

Use --template-help to discover template-specific flags before invoking.

GEM INDEX

EBUS DISPATCH REFERENCE

Dispatch syntax

// Broadcast (no address, singleton bus)
GS_Core::GameManagerRequestBus::Broadcast(
    &GS_Core::GameManagerRequestBus::Events::NewGame);

// Entity-addressed
GS_Unit::UnitRequestBus::Event(
    entityId, &GS_Unit::UnitRequestBus::Events::Possess, controllerEntityId);

// Broadcast with return value
bool isStarted = false;
GS_Core::GameManagerRequestBus::BroadcastResult(
    isStarted, &GS_Core::GameManagerRequestBus::Events::IsStarted);

Bus naming convention

GS_Core buses

GS_Cinematics buses

GS_Interaction buses

GS_PhantomCam buses

GS_UI buses

Removed / Deprecated (do not use): GS_UIHubComponent, GS_UIHubBus, GS_UIWindowComponent — these were part of a removed three-tier Hub/Window/Page hierarchy. The current architecture is single-tier: Manager → Page.

GS_Unit buses

GS_Environment buses

GS_Audio buses

HOT PATHS

Canonical patterns for the most common agent tasks. Follow exactly.

HOT PATH 1 — Create a component extending a GS_ base

(Incorrect - Templates satisfy much of this.)

1. Identify target gem namespace and base class.
2. Generate skeleton via O3DE Class Creation Wizard.
3. Replace generated names. Add GS_ base class alongside AZ::Component in inheritance list.
4. In Activate(): call BusConnect() for all buses this component handles.
5. In Deactivate(): call BusDisconnect() for all buses.
6. In Reflect(): SerializeContext first, EditContext nested inside it. EnableForAssetEditor in SerializeContext only, directly under ->Version().

[ANCHOR] For any specific gem’s base class API → read /docs/framework/{gem}/ before writing the override body.

HOT PATH 2 — Dispatch an EBus command

(Incorrect - BusInterfaceName)

// Fire and forget, singleton bus
GS_{Gem}::{BusName}::Broadcast(
    &GS_{Gem}::{BusName}::Events::{MethodName},
    arg1, arg2);

// Entity-addressed bus
GS_{Gem}::{BusName}::Event(
    targetEntityId, &GS_{Gem}::{BusName}::Events::{MethodName}, arg1);

// With return value
ReturnType result{};
GS_{Gem}::{BusName}::BroadcastResult(
    result, &GS_{Gem}::{BusName}::Events::{MethodName});

HOT PATH 3 — Listen to an EBus notification

1. Inherit from {BusName}::Handler (protected inheritance).
2. In Activate(): {BusName}::Handler::BusConnect();
   • For entity-addressed buses: {BusName}::Handler::BusConnect(GetEntityId());
3. In Deactivate(): {BusName}::Handler::BusDisconnect();
4. Override the virtual notification methods.

HOT PATH 4 — Create a new Manager Component

1. Inherit from GS_Core::GS_ManagerComponent.
2. Connect to GameManagerNotificationBus in Activate().
3. Implement lifecycle hooks: OnSetupManagers, OnShutdownManagers, OnEnterStandby, OnExitStandby.
4. Define {Name}RequestBus (Single/Single policy) for commands.
5. Define {Name}NotificationBus (Multiple policy) for notifications.
6. Register descriptor in your gem’s module constructor.

[ANCHOR] Manager lifecycle and initialization order → /docs/framework/core/gs_managers/manager/

HOT PATH 5 — Create a Generic Data Asset

1. Inherit from AZ::Data::AssetData.
2. Include GS_Core Utility: GS_AssetReflectionIncludes.h
3. In Reflect(), SerializeContext block:

   sc->Class<MyAsset, AZ::Data::AssetData>()
       ->Version(1)
       ->Attribute(AZ::Edit::Attributes::EnableForAssetEditor, true)
       ->Field("Field", &MyAsset::m_field);
   

4. Register asset type in a system component’s Reflect().
5. EnableForAssetEditor goes only in SerializeContext. Never in EditContext.

HOT PATH 6 — Polymorphic container of subtypes

// CORRECT — all subtypes selectable in editor
AZStd::vector<BaseClass*> m_items;

// WRONG — disables all subtype options in editor
AZStd::vector<AZStd::unique_ptr<BaseClass>> m_items;

Reflect with ->Field("Items", &MyClass::m_items). O3DE handles subtype selection automatically with raw pointers.

HOT PATH 7 — Create a custom Trigger Sensor or World Trigger

Two distinct extension points. Choose the correct base:

Custom Trigger Sensor (condition side — detects when to fire):

1. Inherit from GS_Interaction::TriggerSensorComponent.
2. Override EvaluateSensor() — call Trigger() on all WorldTriggerRequestBus handlers on the same entity when your condition is met.
3. Reflect with SerializeContext and EditContext.
4. Register descriptor in your gem’s module.

Custom World Trigger (response side — what happens when fired):

1. Inherit from GS_Interaction::WorldTriggerComponent.
2. Override DoTrigger() — implement the response behavior.
3. Override DoReset() if the trigger should re-arm.
4. Reflect with SerializeContext and EditContext.
5. Register descriptor in your gem’s module.

[ANCHOR] Full WorldTrigger architecture → /docs/framework/interaction/world_triggers/

HOT PATH 8 — Add a custom Dialogue type (effect, condition, performance)

1. Inherit from the appropriate base: DialogueEffect, DialogueCondition, or DialoguePerformance.
2. Reflect the class using SerializeContext and EditContext. The system discovers it automatically at startup — no manual registration step.
3. GS_Complete demonstrates this pattern for cross-gem types (e.g., a dialogue effect controlling a PhantomCam). Use it as a reference, not a required location.

[ANCHOR] Dialogue type system → /docs/framework/cinematics/dialogue_system/

ANTIPATTERN CATALOG

[ANTIPATTERN] EnableForAssetEditor in EditContext. Silent failure — asset never appears in Asset Editor [New] menu. See INVARIANTS.

[ANTIPATTERN] unique_ptr in polymorphic AZStd containers. Disables all subtype selection in the editor. Use BaseT*. See INVARIANTS.

[ANTIPATTERN] Guessing EBus method names. O3DE EBus dispatches fail silently on wrong method names. Always verify against source headers or the EBUS DISPATCH REFERENCE in this document.

[ANTIPATTERN] Dispatching to entity-addressed buses before target entity is active. Buses are not connected before Activate() or after Deactivate(). Sending events before activation is silently dropped.

[ANTIPATTERN] Omitting AZ_COMPONENT_IMPL in the .cpp file. Component will not be reflectable. Causes subtle reflection failures that appear unrelated to the missing macro.

[ANTIPATTERN] Using "Editor" service in AppearsInAddComponentMenu. GS_Play components use AZ_CRC_CE("Game"). The "Editor" category makes components invisible in standard game entity contexts.

[ANTIPATTERN] Writing component boilerplate manually. Module registration steps are reliably missed. Always start from the O3DE Class Creation Wizard output.

CONFIDENCE THRESHOLDS

Proceed without reading source or docs:

• Standard O3DE component lifecycle: Init, Activate, Deactivate, BusConnect, BusDisconnect
• AZStd container usage (with the raw pointer rule applied for polymorphic types)
• CMake target aliases: Gem::{Name}.API, Gem::{Name}.Private.Object, Gem::{Name}.Clients
• SerializeContext → EditContext nesting order in Reflect()
• AZ_CRC_CE() for compile-time CRC values
• azrtti_cast<> for safe type casting in reflection code

Stop and read documentation or ask the user before proceeding:

• Any EBus method signature you are not 100% certain of
• Any virtual method signature on a GS_ base class
• Whether a specific GS_ gem is present in the target project
• Initialization order requirements for a new Manager component
• Any TypeId UUID value — never generate a UUID, ask the user or read the TypeIds header

CONTEXT ANCHORS

Conditions that require reading deeper documentation before generating code.

[ANCHOR] Before writing any unit movement or controller code: → Read /docs/framework/unit/ for mover types (3DFree, Strafe, Grid, SideScroller, Slide, Physics), grounder types, and controller hierarchy (Player vs AI). → [ASK] Which mover type does this movement context require?

[ANCHOR] Before configuring any virtual camera: → Read /docs/framework/phantomcam/ for camera types (PhantomCamera, StaticOrbit, Track, ClampedLook) and influence field setup.

[ANCHOR] Before wiring any dialogue sequence: → Read /docs/framework/cinematics/dialogue_system/ for the full chain: Sequencer → UIBridge → DialogueUI component.

[ANCHOR] Before implementing targeting or interaction: → Read /docs/framework/interaction/targeting/ for the TargetingHandler, Target, TargetField setup order and registration timing.

[ANCHOR] Before building any UI screen or menu: → Read /docs/framework/ui/ for the Manager → Page architecture, navigation return policies, companion component pattern, and UIManager registration sequence. The Hub/Window layer has been removed — do not use GS_UIHubComponent or GS_UIWindowComponent.

[ANCHOR] Before integrating save or persistence: → Read /docs/framework/core/gs_save/ for the SaveManager, RecordKeeper, and Saver component chain.

[ANCHOR] Before setting up project physics layers or collision groups: → Read /docs/get_started/configure_project/setup_environment/ for required engine-level physics configuration.

[ANCHOR] Before implementing behavior that combines two or more GS_ gems: → Review GS_Complete — it provides reference implementations of common cross-gem patterns. Reuse or adapt them rather than reimplementing from scratch.

CLARIFICATION TRIGGERS

[ASK] At the start of any GS_Play session, identify the user context:

• Designer / Scripter — Working in the O3DE editor with components, Script Canvas, or Lua. No C++ generation needed.

  • Guidance: component configuration, property setup, EBus Script Canvas nodes.
  • Documentation: The Basics → /docs/the_basics/
  • Gem-specific: /docs/the_basics/{gem}/ (e.g., /docs/the_basics/unit/ for unit questions)

• Engineer — Writing C++ to extend the framework with new components, gems, or systems.

  • Guidance: follows HOT PATHS and code patterns in this document.
  • Documentation: Framework API → /docs/framework/
  • Gem-specific: /docs/framework/{gem}/ (e.g., /docs/framework/unit/ for unit questions)

Both sections cover identical gem featuresets. The Basics covers component usage and scripting; Framework API covers C++ interfaces, EBus signatures, and base class architecture. Available gems in both: core, audio, cinematics, environment, interaction, juice, performer, phantomcam, ui, unit.

When answering any gem-specific question, include a link to the appropriate documentation section alongside your response. If the context is not stated, ask before generating any code or providing documentation links.

[ASK] Before creating any new component: Confirm which gem’s namespace and base class this component should use.

[ASK] Before generating any TypeId UUID: Always request the UUID from the user or confirm they want one generated. Never silently generate a UUID.

[ASK] If the task references a system with no memory or documentation coverage: Ask before inferring behavior. GS_Play base class APIs are not reliably guessable from generic O3DE patterns.

[ASK] If a Manager initialization order is being modified: The sequence of OnSetupManagers calls is load-order dependent. Confirm the intended position in the sequence before writing.

[ASK] If asked to implement a new Dialogue type: Extend the appropriate base class (DialogueEffect, DialogueCondition, or DialoguePerformance) and reflect it. Confirm which gem or module owns the new class before writing.

UPCOMING: AGENTIC SITE FEATURES (Post v1)

The GS_Play documentation site will implement formal agent-friendly features after the v1 documentation release. These are not yet live.

Planned additions follow the emerging specifications at:

• Making a Hugo Site Agent-Friendly — structured metadata, machine-readable page indexes, and LLM-optimized content formatting for Hugo-based docs sites.
• Agent Docs Spec — emerging open specification for agent-accessible documentation.

What this means for agents using this document now:

Until those features are live, this bootstrap document (/docs/get_started/agentic_guidelines/) is the primary machine-readable entry point. Treat it as authoritative. Do not rely on inferred site structure or navigated page discovery — navigate the docs via explicit paths from the GEM INDEX and CONTEXT ANCHORS sections above.

When the agent-friendly site features are released, this section will be updated with the new entry points and structured access patterns.

2 - Index

Quick-access references for the GS_Play documentation. Use this section when you know what you are looking for and need a fast lookup — a term definition, the right template name, a feature comparison, or the changelog for a specific gem.

How This Section Is Organized

Change Log — Version history for GS_Play gems and the documentation itself.

Feature List — A complete index of every GS_Play feature, with links to both its Basics usage guide and Framework API reference.

Patterns — Diagrams and explanations of the core structural patterns used across GS_Play feature sets. A useful orientation before diving into a new gem.

Templates List — All ClassWizard extension templates for generating new conditions, effects, performances, trigger types, and other polymorphic extension classes across GS_Play gems.

Powerful Utilities — Cross-cutting utilities available across multiple feature gems.

Glossary — Definitions for GS_Play-specific terminology and commonly used O3DE concepts in the framework context.

Links — External links to community resources, the asset store, and Genome Studios.

Sections

2.1 - Change Logs

Logs

• GS_Audio
• GS_AudioPro
• GS_Cinematics
• GS_Core
• GS_Environment
• GS_Interaction
• GS_Juice
• GS_Performer
• GS_PhantomCam
• GS_UI
• GS_Unit
• Documentation

GS_Audio

Latest version: 0.7.0

Change Summary

The free tier of the audio system — polymorphic audio events with procedural sources, SFXR sound profiles, the 22-effect mix layer, and Steam Audio spatialization with a split listener.

GS_Audio Logs

GS_AudioPro

Latest version: 0.7.0

Change Summary

First release of the premium audio tier — the visual Audio Event Graph, procedural scoring, Klatt voice synthesis, and geometry-driven occlusion and reflections.

GS_AudioPro Logs

GS_Cinematics

Latest version: 0.6.0

Change Summary

Dialogue Editor rebuilt on the gs_graphcanvas framework with container database model, visual graph authoring, and runtime graph execution.

GS_Cinematics Logs

GS_Core

Latest version: 0.6.0

Change Summary

The GS_Options settings system, headless managers, the extensible ImGui debug menu, the input reactor mechanism, new noise/envelope/orbital utilities, and the project and component templates.

GS_Core Logs

GS_Environment

Latest version: 0.5.0

Change Summary

First official base release. Time of day management, time passage speed, day/night cycle notifications, and sky color configuration assets.

GS_Environment Logs

GS_Interaction

Latest version: 0.5.0

Change Summary

First official base release. Physics pulse emitters and reactors, proximity targeting and cursor, and composable world trigger sensors.

GS_Interaction Logs

GS_Juice

Latest version: 0.5.0

Change Summary

First official base release (Early Development). Feedback motion system with transform and material tracks for screen shake, bounce, flash, and glow effects.

GS_Juice Logs

GS_Performer

Latest version: 0.5.0

Change Summary

First official base release (Early Development). Performer manager, skin slot swapping, paper billboard rendering, velocity locomotion, head tracking, and babble.

GS_Performer Logs

GS_PhantomCam

Latest version: 0.5.0

Change Summary

First official base release. Priority-based camera system with follow/look-at behaviors, blend profiles, and spatial influence fields.

GS_PhantomCam Logs

GS_UI

Latest version: 0.5.0

Change Summary

First official base release. Single-tier page navigation, GS_Motion UI animation, enhanced buttons, input interception, load screen, and pause menu.

GS_UI Logs

GS_Unit

Latest version: 0.6.0

Change Summary

Unit Action Graph (under construction) — HFSM editor with parallel layers, perimeter connections, transition conditions, and tick-based state evaluation.

GS_Unit Logs

Documentation

Latest version: 1.1.0

Change Summary

GS_GraphCanvas framework reference, Audio Event Graph docs, Dialogue Editor rewrite, Unit Action Graph docs, Building a Graph Tool tutorial, and Dialogue System Setup tutorial.

Docs Logs

2.1.1 - Audio Change Log

Logs

• 0.7.0
• 0.6.0
• 0.5.0

Audio 0.7.0

GS_Audio is now the free tier of the audio system. The visual authoring, music, voice and geometric acoustics features moved to GS_AudioPro; everything below is what the free gem carries.

Audio Events

• GS_AudioEvent is now an abstract base, and event libraries hold a polymorphic list — the type dropdown offers every registered event kind.
• GS_AudioEvent_Pool — a pool of sound assets, one picked at random per fire.
• GS_AudioEvent_Noise — procedural noise with selectable colour and duration.
• GS_AudioEvent_Sfxr — procedural chiptone driven by a pool of .sfxrprofile assets.
• Shared machinery on the base: pooling, concurrency limits, re-fire suppression, distance settings, 3D tracking and spatialization back-end resolution.
• Extension hooks for writing a new event source, with the asset hooks optional so generators need only three methods.
• RerouteSounds re-points pooled and future instances when a mix target registers late.

SFXR Sound Profiles

• New .sfxrprofile asset — 24 parameters describing one procedural sound.
• Import from sfxr.me / jsfxr by pasting the Serialize JSON.
• 27 profiles ship with the gem: 7 canonical presets and 20 named custom sounds.

Mixing and Mix Effects

• MixEffectComponent — an ordered effect chain registered under a name, with a configurable output target.
• 22 mix effect types: 7 biquad filters, Echo, Reverb, Binaural, 8 character and modulation effects, and 4 utility effects.
• Named routing shared with volume channels, so a source targets either by name.
• Order-independent wiring — a chain pointing at a target that does not exist yet resolves when it registers.
• Runtime control: RerouteMixEffect, SetMixEffectParam, SetMixEffectParamOn, plus manual registration and wiring.

Spatialization

• Steam Audio integration, vendored and loaded at runtime.
• Per-voice HRTF binaural placement, recomputed each frame, replacing the built-in spatializer rather than stacking with it.
• Distance attenuation and air absorption via Steam’s direct effect.
• Bounded distance curve — the direct signal reaches true silence at max distance, and the reverb send eases to zero over the last quarter of the range.
• HRTF interpolation modes, HRTF volume, and frame-size mode with an automatic match to the device period.

Audio Manager

• GS_AudioProjectSettings reflected on the manager, making the component panel the configuration surface.
• The authoritative listener now supports split targets — position from one entity, facing from another, for third-person games.
• Listener target defaults to the manager entity with a warning when unset.
• Accessor surface for GS_AudioPro: engine, node graph, endpoint, mixing buses, Steam Audio context, HRTF and frame size.
• Spatial-simulator registration and reverb send, null in a base-only install.
• Options apply targets for master volume and named volume channels.
• The base manager no longer ticks.

Debug

• GS_AudioImGuiDebugComponent — an Audio Mixer window with master and per-channel sliders.

Audio 0.6.0

Audio Event Graph

• Visual node-based editor for authoring complex sound events using the gs_graphcanvas framework (DataFlowGraph topology).
• Entry nodes (Start/Loop/Finish) for phase-gated audio lifecycle.
• Source nodes: Aud_SoundNode, Aud_AudioPoolNode — single and pooled audio playback with volume, pitch, delay, looping, and 3D spatialization.
• Filter nodes: LowPass, HighPass, BandPass, Notch, PeakingEQ, LowShelf, HighShelf — miniaudio filter processing.
• Effect nodes: Aud_EchoNode, Aud_DelayNode.
• Routing via gs_graphcanvas built-in IfNode and SwitchNode for conditional audio paths.
• Aud_OutputNode terminal wiring to mixing bus.
• Variable-driven sound control — runtime variable API for filter parameters, routing, and source selection.
• AudioGraphTemplateCache — graph instance pooling and caching per asset path.
• AudioSoundPool — ma_sound pooling with claim/release pattern, configurable pad and trim thresholds.
• AudioFilterPool — filter node pooling by type.
• Phase lifecycle management (Start/Loop/Finish) with TransitionToPhase().
• Runtime API: PlayAudioGraph, AcquireAudioGraph, FireAudioGraph, StopAudioGraph, FinishAudioGraph, SetAudioGraphVariable*, SetAudioGraphLooping, SetAudioGraphEntity, SetAudioGraphPosition, StopAudioGraphFade.
• 3D spatialization per-instance via AudioGraphSpatialMode (None, Position, Entity).

Audio 0.5.0

First official base release of GS_Audio.

Audio Manager

• GS_AudioManagerComponent — audio engine lifecycle management, event library loading
• AudioManagerRequestBus / AudioManagerNotificationBus
• Master volume control and engine-level audio settings

Audio Events

• AudioEventLibrary asset — pools of named audio events
• GS_AudioEvent — pool selection, concurrent instance limiting, and 3D spatialization
• AudioManagerRequestBus playback interface

Mixing & Effects

• GS_MixingBus — mixing bus component with configurable effects chain
• Filters, EQ, and environmental influence effects per bus

Score Arrangement

• ScoreArrangementTrack — multi-layer music system
• ScoreLayer — individual music layers toggled by gameplay state
• TimeSignatures enum for bar-aligned transitions

Klatt Voice Synthesis

• KlattVoiceSystemComponent — shared SoLoud engine, 3D listener management
• KlattVoiceComponent — per-entity text-to-speech with phoneme mapping and segment queue
• KlattVoiceRequestBus / KlattVoiceNotificationBus / KlattVoiceSystemRequestBus
• Full 3D spatial voice audio with configurable voice parameters

2.1.2 - AudioPro Change Log

Logs

• 0.7.0

AudioPro 0.7.0

First release of GS_AudioPro, the premium half of the audio system. It requires GS_Audio and extends it.

Gem Architecture

• GS_ProAudioManagerComponent subclasses the base Audio Manager and declares itself incompatible with it, so a project runs one or the other.
• Pro attaches through the base gem’s accessor surface — engine, node graph, endpoint, mixing buses, shared Steam Audio context and HRTF — rather than reaching into internals.
• GS_ProAudioSettings adds the geometry configuration alongside the base project settings.
• Separate buses: AudioGraphRequestBus, AudioGraphPlayerRequestBus, AudioScoreRequestBus and the Klatt voice buses.
• ScriptCanvas nodes under the GS_Play/GS_AudioPro category.

Audio Event Graph

• The .audiograph visual editor, built on the gs_graphcanvas framework with a data-flow topology.
• 31 node types: 4 sources, 7 filters, Echo and Reverb, 7 character and modulation effects, 4 utility effects, Mix and Split, three phase gates and the Output terminal.
• AudioGraphLibrary (.agl) — named access to graphs, with a source-file picker.
• AudioGraphPlayerComponent — drop-on playback with auto-play, spatialization and looping, and no handles to manage.
• Preserve-until-release instance lifecycle: an owned instance quiesces to idle on stop and keeps its variables and configuration until explicitly released.
• Full transport, variable, spatialization and state surface on AudioGraphRequestBus.
• Node registration pinned against unity-build symbol stripping, so the launcher deserializes graphs.

Procedural Scoring

• ScoreArrangementTrack — multi-layer scores with time signature, tempo and fade control.
• AudioScoreRequestBus: play a score with a chosen layer set, and bring individual layers in and out at runtime.

Klatt Voice Synthesis

• Formant text-to-speech with 3D spatial audio, backed by SoLoud and relayed into the audio graph through a custom node.
• Voice profiles and phoneme maps as assets, with per-word pronunciation overrides.
• Inline KTT tags for changing pitch, speed and waveform partway through a line.
• Per-entity voice components with a segment queue and completion notifications.

Geometric Acoustics

• Steam Audio scene and simulator integration, off by default behind a master switch.
• Occlusion in raycast and volumetric modes, the latter giving partial occlusion at edges.
• Listener-centric reflections with configurable wet mix, order and smoothing between rooms.
• Reverb as a distance-independent send, so a room sounds consistent across its volume while the dry signal falls off.
• Acoustic geometry components for authored volumes and O3DE Shapes.
• 15 acoustic material presets plus a custom material, including soft barriers that transmit rather than block.
• Parametric reverb on a worker thread with lock-free direct and occlusion values.

See Also

• GS_Audio Change Log — the free tier this builds on
• Audio Pro documentation

2.1.3 - Cinematics Change Log

Logs

• 0.6.0
• 0.5.0

Cinematics 0.6.0

Dialogue Editor — gs_graphcanvas Integration

• Dialogue Editor rebuilt on the gs_graphcanvas framework (FlowGraph topology).
• DialogueDatabaseEditorWindow — container editor with sequence sidebar, performer page, and system page via the full-window page system.
• DialogueGraphDescriptor — systemId = "dialogue", variablesEnabled = true, fileExtension = ".dialogue".
• DialogueGraphContext — dialogue-specific data type registration.
• Editor nodes: Dlg_StartNode, Dlg_TextNode, Dlg_SelectionNode, Dlg_RandomNode, Dlg_EffectsNode, Dlg_PerformanceNode, Dlg_EndNode.
• Container save model — multiple sequences in a single .dialoguedatabase file with OpenGraphFromAsset / CaptureGraphToAsset / ClearAllDocumentDirty.
• Graph variable support for dialogue state tracking (flags, counters).
• Runtime graph execution via GraphInstance and FlowGraphEvaluator in DialogueSequencerComponent.

Cinematics 0.5.0

First official base release of GS_Cinematics.

Cinematics Manager

• GS_CinematicsManagerComponent — cinematic mode lifecycle (BeginCinematic / EndCinematic)
• CinematicsManagerRequestBus / CinematicsManagerNotificationBus (EnterCinematic / ExitCinematic)
• CinematicStageMarkerComponent — named world-space anchor, self-registers on activate

Dialogue Manager

• GS_DialogueManagerComponent — active .dialoguedb asset ownership and performer registry
• DialogueManagerRequestBus — StartDialogueSequenceByName, ChangeDialogueDatabase, RegisterPerformerMarker, GetPerformer
• DialoguePerformerMarkerComponent — named NPC world anchor, PerformerMarkerRequestBus

Dialogue Sequencer

• DialogueSequencerComponent — node graph traversal, runtime token management
• DialogueUIBridgeComponent — routes active dialogue to whichever UI is registered, decouples sequencer from presentation
• DialogueSequencerNotificationBus — OnDialogueTextBegin, OnDialogueSequenceComplete

Data Structure

• DialogueDatabase (.dialoguedb) — named actors and sequences asset
• DialogueSequence — directed node graph with startNodeId
• ActorDefinition — actor name, portrait, and metadata
• Node types: TextNodeData, SelectionNodeData, RandomNodeData, EffectsNodeData, PerformanceNodeData
• SelectionOption — per-choice text, conditions, and connections

Conditions

• DialogueCondition (abstract base) — EvaluateCondition()
• Boolean_DialogueCondition — base boolean comparison
• Record_DialogueCondition — checks GS_Save records with comparison operators
• Polymorphic discovery: extend base class, no manual registration

Effects

• DialogueEffect (abstract base) — DoEffect() / ReverseEffect()
• SetRecords_DialogueEffect — sets GS_Save records during dialogue
• ToggleEntitiesActive_DialogueEffect — activates or deactivates entities in the level
• Polymorphic discovery: extend base class, no manual registration

Performances

• DialoguePerformance (abstract base, AZ::TickBus::Handler) — DoPerformance() / ExecutePerformance() / FinishPerformance()
• MoveTo_DialoguePerformance — interpolated movement to stage marker
• PathTo_DialoguePerformance — navmesh path navigation to stage marker (requires RecastNavigation)
• RepositionPerformer_DialoguePerformance — instant teleport to stage marker
• Polymorphic discovery: extend base class, no manual registration

Dialogue UI

• DialogueUIComponent — screen-space dialogue text, speaker name, and portrait display
• WorldDialogueUIComponent — world-space speech bubble display
• DialogueUISelectionComponent — screen-space player choice menu
• WorldDialogueUISelectionComponent — world-space selection display
• TypewriterComponent — character-by-character text reveal, configurable speed, OnTypeFired / OnTypewriterComplete
• BabbleComponent — procedural audio babble synchronized to typewriter output

Localization

• LocalizedStringId — key + default fallback text, Resolve() method
• LocalizedStringTable — runtime key-value string lookup table

Dialogue Editor

• Node-based in-engine GUI for authoring .dialoguedb assets and sequence graphs

Type Registry

• DialogueTypeRegistry — factory registration for conditions, effects, and performances
• DialogueTypeDiscoveryBus — external gems register custom types without modifying GS_Cinematics

2.1.4 - Environment Change Log

Logs

• 0.5.0

Environment 0.5.0

First official base release of GS_Environment.

Time Manager

• GS_TimeManagerComponent — world time ownership, time of day control
• TimeManagerRequestBus — SetTimeOfDay, SetTimePassageSpeed, GetTimeOfDay, GetWorldTime, IsDay
• TimeManagerNotificationBus — WorldTick (per-frame), DayNightChanged (on threshold cross)
• GS_EnvironmentSystemComponent — system-level environment registration

Sky Configuration

• SkyColourConfiguration — data asset defining sky color at different times of day
• Authored as an asset and assigned to the environment for day/night color blending

2.1.5 - Core Change Log

Logs

• 0.6.0
• 0.5.0

Core 0.6.0

GS_Options – Settings System

• New settings framework: option profiles declare a catalog, and the Options Manager merges, applies, persists and restores it.
• .optionsprofile asset holding a polymorphic option list; multiple profiles stack and merge by key.
• Four option types: toggle, slider, dropdown and colour picker.
• OptionApplyTarget composition — an option’s widget and its engine effect vary independently.
• Shipped apply targets: data flag, console variable, window mode, window resolution, fullscreen, vsync, and a display gamma target in the private module layer.
• .optionspreset asset holding values only, with automatic Custom resolution when values diverge.
• Full bus surface: generic and typed value access, catalog queries by category, apply and save, preset control, and an option-changed notification.
• SettingsRegistry persistence, flushed on save and shutdown rather than per change.
• Launch-time apply path — console-expressible settings are written to a startup command file and executed before the window is created, so the game opens correctly rather than switching after launch.
• Apply deferred by a few ticks after startup, because display and render settings applied at startup-complete precede window and pipeline readiness.
• Accessibility fonts shipped with the gem.

GS_Options – Input Reactors

• The reactor mechanism now lives in GS_Core: a reactor component driven by a reactor profile asset holding authored reaction types.
• Reactors are cloned per component, so a reaction type can hold per-entity state.
• Input events are classified into pressed, held, released and analog phases before dispatch.
• InputReactorRequestBus for feeding events, clearing state and querying values.
• InputReactorNotificationBus emits in parallel with dispatch, so scripts can react without writing a reaction type.

Managers

• Headless mode — a manager can drive its own startup with no Game Manager present, for deploying a single feature into a project not built on GS_Play.
• Headless managers do not register with the Game Manager, so they take no part in its startup count.
• OnBeginGame is never self-fired: startup completing is infrastructure, beginning the game is a cue the project owns.
• Per-manager logging depth for lifecycle diagnostics.

Debug

• GS_ImGuiMenuComponent — a content-free GS_Play menu anchor that any gem contributes to, with deterministic ordering by sort key.
• Core menu shipping a live Options editor and a Game Manager window.

Utilities

• New Noise utility: Perlin 1D/2D/3D, fractal multi-octave, and reflected layered noise stacks.
• New Envelope utility: a reflected ADSR envelope with evaluation, duration and completion helpers.
• New orbital solver: pivot-aware position and pose blending in linear, cylindrical and spherical shapes.
• New comparison helpers for data-authored boolean conditions.
• DebugLoggingHelper mix-in for per-component logging depth.
• Utility headers reorganised into Math, Gradients, Physics, Random and Reflection folders.
• The type registry subsystem was removed. Extensible type sets now use the polymorphic array convention, where the serializer supplies the type picker.

Templates

• GS_Core Project template — a working project with Game, Options, Save and Stage managers already wired into a manager collection, on the shared starter level.
• Component templates for managers, savers, input readers, input reactors and physics triggers.
• Editor-Only Environment prefab for authoring-time lighting and reference setup.

Interfaces

• FeedbackExchangeBus added to the contract layer.

Core 0.5.0

• COOOOREEEEE

2.1.6 - Interaction Change Log

Logs

• 0.5.0

Interaction 0.5.0

First official base release of GS_Interaction.

Pulsors

• PulsorComponent — physics trigger volume that broadcasts typed pulse events
• PulseReactorComponent — receives pulses and executes reactor types
• PulseType (abstract base) — extensible pulse payload type
• Built-in types: Debug_Pulse, Destruct_Pulse
• PulseTypeRegistry — auto-discovery of all reflected pulse types

Targeting

• GS_TargetComponent — marks an entity as a targetable object
• GS_InteractTargetComponent — marks an entity as interactable
• GS_CursorComponent — world-space cursor and proximity scan
• GS_TargetingHandlerComponent — finds and locks the best interactable in range
• GS_TargetingHandlerRequestBus / GS_TargetingHandlerNotificationBus

World Triggers

• TriggerSensorComponent — base for all condition-side trigger sensors
• WorldTriggerComponent — base for all response-side world triggers
• Built-in sensors: InteractTriggerSensorComponent, PlayerInteractTriggerSensorComponent, ColliderTriggerSensorComponent, RecordTriggerSensorComponent
• WorldTriggerRequestBus — trigger enable/disable interface
• Sensors renamed from TriggerAction to TriggerSensor (2026-03)
• 22 components total across all subsystems

2.1.7 - Juice Change Log

Logs

• 0.5.0

Juice 0.5.0

First official base release of GS_Juice. Early Development — full support planned 2026.

Feedback System

• FeedbackEmitter — component that plays authored feedback motions on its entity
• FeedbackMotionAsset — data asset containing one or more feedback tracks
• FeedbackMotion — runtime instance wrapper for a FeedbackMotionAsset
• FeedbackMotionTrack — domain base class extending GS_Core’s GS_Motion system

Feedback Tracks

• FeedbackTransformTrack — drives position, scale, and rotation offsets (screen shake, bounce)
• FeedbackMaterialTrack — drives opacity, emissive intensity, and color (flash, glow, pulse)

PostProcessing

• Planned for future release. Not yet implemented.

2.1.8 - Performer Change Log

Logs

• 0.5.0

Performer 0.5.0

First official base release of GS_Performer. Early Development — full support planned 2026.

Performer Manager

• GS_PerformerManagerComponent — performer registration and name-based lookup
• PerformerManagerRequestBus
• GS_PerformerSystemComponent — system-level lifecycle component

Skin Slots

• PerformerSkinSlotComponent — manages a named visual slot on a character entity
• SkinSlotHandlerComponent — handles asset swapping for a given slot
• PerformerSkinSlotsConfigProfile — asset class defining slot configurations
• SkinSlotData / SkinSlotNameDataPair — slot data types

Paper Performer

• PaperFacingHandlerBaseComponent — base for billboard-style rendering handlers
• PaperFacingHandlerComponent — orients a 2.5D billboard character to face the camera correctly

Locomotion

• VelocityLocomotionHookComponent — reads entity velocity and drives animation blend tree parameters automatically

Head Tracking

• Procedural head bone orientation toward a world-space look-at target

Babble

• BabbleComponent — generates procedural vocalisation tones synchronized to GS_Cinematics typewriter output
• BabbleToneEvent / SpeakerBabbleEvents — tone data structures per speaker identity

2.1.9 - PhantomCam Change Log

Logs

• 1.0.0
• 0.5.0

PhantomCam 1.0.0

Major refactor. The “pick one of N subclass cams” model is replaced by a single GS_PhantomCameraComponent that hosts a composable Body → Aim → Reposition additives → Noise additives stage pipeline. A new channel system scales projects from single-cam through 4-player split-screen co-op without changing the per-cam authoring surface.

Stage pipeline (replaces subclass cams)

• New IBodyStage / IAimStage / IAdditiveStage interfaces — stages are reflected polymorphic types picked from the editor’s type-picker.
• Body variants: DefaultFollowBody, OrbitBody, DynamicOrbitBody, LeadingFollowBody, TrackBody.
• Aim variants: DefaultLookAtAim, ClampedLookAim (plus extensions from gs_performer).
• Additive variants: CollisionReposition, OcclusionReposition (stub), TugAimListener, TugBodyListener, PerlinNoise, ImpulseNoise.
• Three staged pose snapshots — m_desiredPose (pre-Reposition), m_stablePose (post-Reposition pre-Noise), m_finalPose (committed).

Retired components

• ClampedLook_PhantomCamComponent → replaced by ClampedLookAim aim stage variant.
• StaticOrbit_PhantomCamComponent → replaced by OrbitBody body stage variant.
• Track_PhantomCamComponent → replaced by TrackBody body stage variant.
• Their legacy doc URLs redirect to the new stage variant pages via Hugo aliases.
• AlwaysFaceCameraComponent is unchanged.

Channels and instancing

• m_enableInstancedChannels master gate on GS_CamManagerComponent. Three authoring tiers (single cam → single-player rig → multi-channel).
• New CamChannelScope enum (Local / AllChannels / TrueUnique) authored per phantom cam.
• ChannelStampComponent — runtime plumbing for stamp-walk channel resolution. Author never sees it.
• Per-channel rig spawning, per-channel target binding via SetChannelTarget(channelId, entity).
• Cross-channel cinematic dispatch via DispatchCamToCamCore / ReleaseCamCoreDispatch.
• Active main-view selection via SetActiveChannel / SetActiveCamCore.
• Channel-aware SettingNewCamOnChannel notification replaces legacy SettingNewCam when instancing is on.

Blend Profiles

• New asset extension .camblendprofile (registered through PhantomCamDataAssetsSystemComponent).
• Three new fields on PhantomBlend entries:
  • BlendShape — Linear / Cylindrical / Spherical (powered by the new Orbital Solver).
  • PivotSource — Source / Destination / Shared for cross-cam blend pivot resolution.
  • InheritState — opt-in cam-to-cam pose handoff.
• PhantomBlend reflected at Version 4 with version converter for pre-v3 and pre-v4 assets.

State Inheritance

• Universal CamPoseSnapshot pose-handoff struct.
• Per-body Get / Adopt implementations — Orbit Get-only, DynamicOrbit full ANGULAR+POSITION, LeadingFollow facing-seeded standoff, Track path-project with rejection threshold.
• Handoff runs before StartBlend so the destination’s body adopts the seed pose before the blend captures source / destination poses.

Mid-blend Interrupt Correction

• New m_interruptCorrection field on Cam Core (default 0.03).
• Y-blend correction window between the cam’s snapshot-at-interrupt and the new blend’s natural pose at the velocity-matched curve point.
• Replaces the legacy BlendFromCore hard-anchor approach.

Group Targets

• New GroupTargetComponent — weighted-centroid focal entity. Cams point at it like any other target.
• Centroid modes: WeightedMean / BoundingBoxCenter / BoundingSphereCenter with m_weightBias blend.
• Orientation modes: Identity / SpreadAxis / WeightedAverageForward.
• Registered globally via Cam Manager (RegisterGroupTarget / FindGroupTargetByName).
• Pair with shared TrueUnique cams to trigger OnAllChannelsActivatedSharedCam on collapse.

Tug Fields

• Three-component decoupled spatial reposition system — CameraTugVolumeComponent, CameraTugSourceComponent, TugFieldProxyComponent.
• PhysX layer-gated (TugProxy ↔ TugField collision-group pair). No central registry.
• Listener stages TugAimListener and TugBodyListener consume engagements in the Reposition phase.

Noise & Impulse

• New asset extension .camnoiseprofile — six-axis layered Perlin noise stacks. Starter Telephoto_Mild and Telephoto_Intense profiles ship in gs_phantomcam/Assets/Noise Profiles/.
• PerlinNoise additive — continuous handheld feel.
• ImpulseNoise additive — event-triggered burst, ADSR-gated. Fire via TriggerCameraImpulse(strength) on the cam.

Orbit Profiles

• New asset extension .camorbit — CameraOrbitShape with three bands (low / mid / high) and a Roundness power-bulge family slider (diamond → sphere → cube). Arc-length reparameterization for constant spatial speed.
• Consumed by DynamicOrbitBody.

Camera Input Reader

• New GS_CameraInputReaderComponent implementing the OrbitInputProvider bus.
• Per-axis Axis vs Delta style for joystick / mouse handling.
• ResetPendingInput invariant prevents accumulated mouse delta “bursts” after dormancy.

Influence Fields

• AddCameraInfluence signature changed — now (sourceEntity, targetEntity, camName, influence). Influences are routed to the channel that owns the target entity; influences whose target isn’t channel-bound are silently dropped.

Orbital Solver (GS_Core)

• New GS_Core::Math utility — BlendPositionAroundPivot, BlendPoseAroundPivot, ResolveCrossCamPivot. Powers the new blend shapes, DynamicOrbitBody damping, and LeadingFollowBody band response. See Orbital Solver.

PhantomCam 0.5.0

First official base release of GS_PhantomCam.

Cam Manager

• GS_CamManagerComponent — camera system lifecycle, active camera tracking
• CamManagerRequestBus / CamManagerNotificationBus
• GS_PhantomCamSystemComponent — system-level registration

Phantom Cameras

• GS_PhantomCameraComponent — virtual camera with follow target, look-at, FOV, and priority
• PhantomCameraRequestBus
• PhantomCamData — camera configuration data structure
• Priority-based switching: highest priority active phantom camera drives the real camera

Cam Core

• GS_CamCoreComponent — reads from the active phantom camera each frame and applies to the engine camera
• CamCoreRequestBus / CamCoreNotificationBus

Camera Behaviors

• ClampedLook_PhantomCamComponent — look-at with clamped angle limits
• StaticOrbitPhantomCamComponent — fixed-distance orbit around a target
• Track_PhantomCamComponent — follows a spline or path track
• AlwaysFaceCameraComponent — keeps an entity billboard-facing the active camera

Blend Profiles

• GS_PhantomCamBlendProfile — asset defining camera transition easing and duration
• Smooth interpolation between camera positions on priority switch

Influence Fields

• GlobalCameraInfluenceComponent — global persistent camera modifier
• CameraInfluenceFieldComponent — spatial zone that modifies camera behavior on entry
• CamInfluenceData — influence configuration data (offset, FOV shift, tilt)

2.1.10 - UI Change Log

Logs

• 0.5.0

UI 0.5.0

First official base release of GS_UI.

UI Manager

• GS_UIManagerComponent — canvas lifecycle management, focus stack, startup focus assignment
• UIManagerRequestBus
• Single-tier page navigation: Manager → Page (no hub layer)

Page Navigation

• GS_UIPageComponent — root canvas registration, nested page management
• NavigationReturnPolicy — RestoreLast or AlwaysDefault back navigation behavior
• FocusEntry — focus state data for page transitions
• Cross-canvas boundary navigation support
• Companion Component Pattern: domain-specific page logic lives on companion components that react to page bus events

UI Interaction

• GS_ButtonComponent — enhanced button with hover and select UiAnimationMotion support
• GS_UIInputInterceptorComponent — input capture and blocking for UI canvases
• GS_UIInputProfile — input mapping configuration for UI contexts

UI Animation

• UiMotionTrack (domain base) — extends GS_Core’s GS_Motion system
• 8 concrete tracks: UiPositionTrack, UiScaleTrack, UiRotationTrack, UiElementAlphaTrack, UiImageAlphaTrack, UiImageColorTrack, UiTextColorTrack, UiTextSizeTrack
• UiAnimationMotionAsset — authored animation asset
• UiAnimationMotion — runtime instance wrapper

Load Screen

• GS_LoadScreenComponent — manages load screen display during level transitions

Pause Menu

• PauseMenuComponent — pause state management and pause menu page coordination

Removed

• GS_UIWindowComponent — removed entirely
• GS_UIHubComponent / GS_UIHubBus — deprecated legacy layer

2.1.11 - Unit Change Log

Logs

• 0.6.0
• 0.5.0

Unit 0.6.0

Unit Action Graph (Under Construction)

• HFSM editor built on the gs_graphcanvas framework (StateMachineGraph topology).
• UnitActionGraphDescriptor — topology = StateMachineGraph, variablesEnabled = true, transitionConditions = true, parallelLayers = true.
• UnitActionEditorWindow — multi-layer container editor with layer sidebar and priority configuration.
• Perimeter connection rendering — engine-level ConnectionCurveType::Perimeter for state machine arrow visuals.
• Node types: UAG_EntryNode, UAG_StateNode, UAG_CompoundStateNode (nested sub-state-machine).
• TransitionDescriptor — per-connection priority and polymorphic condition list, auto-managed on connection add/remove.
• TransitionCondition base class with built-in conditions: VariableCompareCondition, TimeElapsedCondition, VariableTrueCondition.
• Transition inspector — click connections to edit priority and conditions; node selection shows outgoing transition summary.
• StateMachineEvaluator — tick-based runtime with OnEnter/OnTick/OnExit lifecycle and __stateTime auto-variable.
• ParallelLayerEvaluator — wraps multiple evaluators with shared variable context for simultaneous layer evaluation.
• Not yet implemented: GS_UnitContext integration, compound state sub-graph editing, tag-based transitions, GS_CharacterActionComponent bridge.

Unit 0.5.0

First official base release of GS_Unit.

Unit Manager

• GS_UnitManagerComponent — unit registration and lifecycle tracking
• UnitManagerRequestBus

Unit Component

• GS_UnitComponent — unit identity and state component
• UnitRequestBus

Controllers

• GS_UnitControllerComponent — abstract controller base, possess/release pattern
• GS_PlayerControllerComponent — human player possession
• GS_AIControllerComponent — AI-driven possession
• GS_PlayerControllerInputReaderComponent — reads hardware input and routes to the possessed unit

Input Pipeline

• 3-stage architecture: controller entity reads hardware → routes to InputDataComponent on the unit → reactor components act on the structured state
• InputDataRequestBus / InputDataNotificationBus
• GS_InputReactorComponent — reacts to binary input states (button/action)
• GS_InputAxisReactorComponent — reacts to axis input values (sticks, triggers)

MoverContext

• GS_MoverContextComponent — transforms raw input into movement intent, manages active mode and profiles
• MoverContextRequestBus / MoverContextNotificationBus
• Mode-driven movement: one named mode active at a time; only the mover and grounder matching that mode run

Movers

• GS_MoverComponent — mode-aware mover base class
• GS_PhysicsMoverComponent — physics-driven movement via PhysX
• GS_3DFreeMoverComponent — unconstrained 3D free movement
• GS_3DSlideMoverComponent — slide-and-collide surface movement

Grounders

• GS_PhysicsRayGrounderComponent — raycast-based grounding for the “Free” movement mode

Movement Influence

• MovementInfluenceFieldComponent — spatial zone that modifies unit movement within its bounds
• GlobalMovementRequestBus — global movement modifier interface

Profiles

• GS_UnitMovementProfile — per-mode speed, acceleration, and movement parameter configuration

2.1.12 - Docs Change Log

Logs

• 1.1.0
• 1.0.0
• 0.9.0

Docs 1.1.0

New: GS_GraphCanvas Framework Reference

• Added framework/graphcanvas/ section — full reference for the gs_graphcanvas visual graph editor framework.
• Descriptor & Topology — GraphSystemDescriptor fields, topology decision matrix, GraphContext data types.
• Nodes — BaseNode, slot macros, auto-registration, rapid creation macro, built-in nodes.
• Editor Window — MainWindow features, virtual hooks, page system, container editor pattern.
• Variables — Variable panel, Get/Set nodes, convert-to-reference, drag-to-canvas.
• Execution Engines — FlowGraphEvaluator, DataFlowGraphEvaluator, StateMachineEvaluator, GraphExecutionContext, GraphInstance.

New: Audio Event Graph

• Added framework/audio/audio_event_graph/ — usage docs for the visual sound event editor.
• Node catalog, phase lifecycle, variable control, extending with custom nodes, runtime API reference.
• Updated GS_Audio index page with Audio Event Graph section.

Updated: Dialogue Editor

• Rewrote framework/cinematics/dialogue_system/dialogue_editor/ from skeleton to full usage documentation.
• Database model, editor layout, sequences, performers, node catalog, conditions, extending, variables.

New: Unit Action Graph (Under Construction)

• Added framework/unit/unit_action_graph/ — HFSM editor docs marked under construction.
• Multi-layer model, perimeter connections, nodes, transitions, conditions, parallel layers, current status.
• Updated GS_Unit index page with Unit Action Graph section.

New: Building a Graph Tool Tutorial

• Added learn/lessons/building_a_graph_tool/ — step-by-step guide for creating a custom graph editor.
• Covers topology selection, descriptor, context, nodes, editor window, system component, runtime, and pitfalls checklist.

New: Dialogue System Setup Tutorial

• Added learn/lessons/dialogue_setup_tutorial/ — 6-step tutorial for setting up a complete dialogue pipeline.
• Covers database creation, conversation authoring, runtime wiring, UI display, player choices, conditions and effects.

Removed

• Removed learn/lessons/audio_event_graph_tutorial/ — replaced by Dialogue System Setup tutorial.

Site

• Added SVG light/dark theme support.

Docs 1.0.0

• Welcome page finalized.

• Get Started and Index sections finalized.

• No missing pages. Final organization.

• Patterns Complete.

• Feature List, Glossary fully updated.

• Get Started T1 page filled.

• Index T1 page filled.

• Final Logs format and arrangement.

• Print page + print section links.

• Homepage complete.

• About Us complete.

• Product pages complete.

Docs 0.9.0

Full first implementation of direct documentation formatting and content. With this release we have our first fully working catalogue of featuresets, functionality, and API.

Feature Roots are called “Tier 2”. They are overviews with quick indexes for their subsystems. Content Pages are called “Tier 3”. They carry the body and substance of any given feature or subfeature. Nested pages below these tiers are combinations of both T2, and T3, depending on the depth an overview needs to be to segue into the child pages.

Established base organization of information.

• Get Started is very thin and for user onboarding.
• Index replaces Get Started for regular users. Allowing for easy navigation across categorical necessities for users.
• Basics is conceptual and script driven knowledge for the framework.
• Framework API is the engineering and veteran user knowledgebase.
• Learn is for Youtube video funnelling, or text driven Guide access.

Cross linking is prioritized to move users to the knowledge they seek, asap.

Agentic Guidelines is an LLM based seed for how to use GS_Play and navigate the documentation for information access. The website has been optimized behind the scenes for LLM scraping.

Basics

Basics Implemented.

• Implemented Core
• Implemented Audio
• Implemented Cinematics
• Implemented Environment
• Implemented Interaction
• Implemented Juice
• Implemented Performer
• Implemented PhantomCam
• Implemented UI
• Implemented Unit

Framework API

Framework API Implemented.

• Implemented Core
• Implemented Audio
• Implemented Cinematics
• Implemented Environment
• Implemented Interaction
• Implemented Juice
• Implemented Performer
• Implemented PhantomCam
• Implemented UI
• Implemented Unit

2.2 - Feature List

Contents

• Core
• Audio
• Cinematics
• Environment
• Interaction
• Juice
• Performer
• PhantomCam
• UI
• Unit

GS_Core

GS_Audio

Audio is two gems. GS_Audio is free; GS_AudioPro is premium and extends it.

GS_Cinematics

GS_Environment

GS_Interaction

GS_Juice

GS_Performer

GS_PhantomCam

GS_UI

GS_Unit

2.3 - Patterns

Outline

The strength of the GS_Play framework is in it’s straightforward, and intuitive patterns.

By creating simple ways to look at certain featuresets, you can reliably expand your gameplay knowing you’re always going to properly connect with the underlying system.

Using our extensive list of templates, you can even more rapidly develop the features that make your project unique.

Where features connect across gems, they meet at neutral contracts collected in the GS_Core Interfaces layer — the three contract kinds (TypeBase, Emit, Exchange) are the connective pattern behind most of the diagrams below.

Use this quick list to jump to the features you want to look at.

You can expect a diagram outlining the relationships between feature elements, and then explanations on how the pattern plays out.

Have fun!

Legend

Contents

• Polymorphic Arrays - framework-wide
• Managers & Startup - GS_Core
• Save - GS_Core
• Stage Change - GS_Core
• Pulse - GS_Interaction
• World Triggers - GS_Interaction
• Camera Blend - GS_PhantomCam
• Unit Possession - GS_Unit
• Unit Input Handling - GS_Unit
• Movers & Grounders - GS_Unit

Polymorphic Arrays - framework-wide

Breakdown

Wherever GS_Play has an extensible set of things — the events in an audio library, the effects in a mix chain, the options in a profile, the reactions in an input reactor profile, the tracks in a motion asset — it uses the same shape.

Abstract base            reflected, e.g. an option type or an event type
      |
      |  subclasses reflected against it, in any gem
      v
vector<Base*>            the authored field on an asset or component
      |
      |  SerializeContext supplies the "Add" dropdown
      v
Editor type picker       every registered subtype, automatically

There is no registry, no discovery bus and no registration call. Reflecting a subclass against the base is the whole of it — the serializer already knows every type derived from a reflected base, so the property editor can offer them.

The rule that makes it work

An editable polymorphic field must be a vector of raw pointers to the base. A single Base* or a smart pointer is not editable in the property editor. The owning container owns its elements.

If you author an extensible field and the Add dropdown does not appear, this is nearly always why.

Why it is worth knowing as a pattern

Once you recognise the shape, every extensible system in the framework reads the same way, and extending any of them is the same three steps: derive from the base, implement its handful of virtuals, reflect it.

The input reactor profile is the clearest one to look at first, because the profile asset makes the whole authoring loop visible in one place.

Managers & Startup - GS_Core

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.

• The Basics: GS_Managers — Setup, startup events, and game navigation.
• Framework API: GS_Managers — Components, architecture, and C++ extension.

Back to top…

Save - GS_Core

Breakdown

When a save or load is triggered, the Save Manager broadcasts to every Saver in the scene. Each Saver independently handles its own entity’s state. The Record Keeper persists flat progression data alongside the save file.

Part	Broadcast Event	What It Means
Save Manager	OnSaveAll	Broadcasts to all Savers on save. Each serializes its entity state.
Save Manager	OnLoadAll	Broadcasts to all Savers on load. Each restores its entity state.
Record Keeper	RecordChanged	Fires when any progression flag is created, updated, or deleted.

Savers are per-entity components — add them to anything that needs to persist across sessions. The Record Keeper is a global singleton for flags and counters.

• The Basics: GS_Save — Triggering saves, the Record Keeper, and built-in Savers.
• Framework API: GS_Save — Save Manager, Saver base class, and C++ extension.

Back to top…

Stage Change - GS_Core

Breakdown

When a stage change is requested, the system follows a five-step sequence before gameplay resumes in the new level:

Step	Broadcast Event	What It Means
1. Standby	OnEnterStandby	Game Manager enters standby, halting all gameplay systems.
2. Unload	(internal)	The current stage’s entities are torn down.
3. Spawn	(internal)	The target stage prefab is instantiated.
4. Set Up	OnBeginSetUpStage	Stage Data runs its layered startup: SetUpStage → ActivateByPriority → Complete.
5. Complete	LoadStageComplete	Stage Manager broadcasts completion. Standby exits. Gameplay resumes.

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

• The Basics: GS_StageManager — Triggering stage changes, Stage Data, and Exit Points.
• Framework API: GS_StageManager — Stage Manager, Stage Data component, and C++ extension.

Back to top…

Pulse - GS_Interaction

Breakdown

When an entity enters a Pulsor’s trigger volume, the Pulsor emits its configured pulse type to all Reactors on the entering entity:

Step	What It Means
1. Collider overlap	Physics detects an entity entering the Pulsor’s trigger volume.
2. Pulse emit	PulsorComponent reads its configured PulseType and prepares the event.
3. Reactor query	Each PulseReactorComponent on the entering entity is checked with IsReactor().
4. Reaction	Reactors returning true have ReceivePulses() called and execute their response.

Pulse types are polymorphic — new types are discovered automatically at startup. Any gem can define custom interaction semantics without modifying GS_Interaction.

• The Basics: Pulsors — Pulse types, Reactor types, and ScriptCanvas usage.
• Framework API: Pulsors — Components, pulse and reactor type references, and C++ extension.

Back to top…

World Triggers - GS_Interaction

Breakdown

World Triggers split conditions from responses. Any number of World Triggers can stack on a single entity — each fires its own response independently when the condition is met.

Part	What It Means
Trigger Sensor	Monitors for a condition. When satisfied, calls Trigger() on all WorldTriggerComponent instances on the same entity.
World Trigger	Executes a response when Trigger() is called. Can be reset with Reset() to re-arm for the next activation.

No scripting is required for standard patterns. Compose Trigger Sensors and World Triggers in the editor to cover the majority of interactive world objects without writing any code.

• The Basics: World Triggers — Sensor types, trigger responses, and reset patterns.
• Framework API: World Triggers — Trigger Sensors, World Triggers, and C++ extension.

Back to top…

Camera Blend - GS_PhantomCam

Breakdown

When the dominant Phantom Camera changes, the Cam Manager queries the Blend Profile to determine transition timing and easing:

Step	What It Means
1. Priority change	A Phantom Camera gains highest priority or is activated.
2. Profile query	Cam Manager calls GetBestBlend(fromCam, toCam) on the assigned GS_PhantomCamBlendProfile asset.
3. Entry match	Entries are checked by specificity: exact match → any-to-specific → specific-to-any → default fallback.
4. Interpolation	Cam Core blends position, rotation, and FOV over the matched entry’s BlendTime using the configured EasingType.

Because Blend Profiles are shared assets, editing one profile updates every camera that references it.

• The Basics: GS_PhantomCam — Camera system overview, Blend Profiles, and ScriptCanvas usage.
• Framework API: GS_PhantomCam — Data model, GetBestBlend resolution, and asset structure.

Back to top…

Unit Possession - GS_Unit

Breakdown

Every unit has exactly one controller at a time, or no controller at all. Possession is established by calling Possess on the unit and released by calling DePossess. Ownership changes are observed through the GS_Core cross-gem contract PossessionEmissionBus whenever ownership changes so other systems can react.

Concept	Description
Possession	A controller attaches to a unit. The unit accepts input and movement commands from that controller only.
DePossession	The controller releases the unit. The unit halts input processing and enters a neutral state.
Possession events	Fire on the GS_Core PossessionEmissionBus (addressed by entity ID) whenever a unit’s controller changes.
GetController	Returns the entity ID of the current controller, or an invalid ID if none.
GetUniqueName	Returns the string name assigned by the Unit Manager when this unit was spawned.

• The Basics: Controllers — Possession, input routing, and controller assignment.
• Framework API: Unit Controllers — Controller components, possession API, and C++ extension.

Back to top…

Unit Input Handling - GS_Unit

Breakdown

The input pipeline has three stages. Each stage is a separate component on the unit entity, and they run in order every frame:

Stage	Component	What It Does
1. Read	GS_PlayerControllerInputReaderComponent	Reads raw input events from the active input profile and writes them into GS_InputDataComponent.
2. Store	GS_InputDataComponent	Holds the current frame’s input state — button presses, axis values — as structured data.
3. React	Reactor components	Read from GS_InputDataComponent and produce intent: movement vectors, action triggers, etc.

All reactor components downstream of the store stage read from the same GS_InputDataComponent, so there is no duplicated hardware polling and no risk of two reactors seeing different input states for the same frame.

• The Basics: Controllers — Possession, input routing, and controller assignment.
• The Basics: Core Input — Input profiles, action mappings, and options setup.
• The Basics: Unit Input — Input readers, axis configuration, and ScriptCanvas usage.
• Framework API: Unit Controllers — Controller components, possession API, and C++ extension.
• Framework API: Input Reader — Profile binding, action event reading, and C++ extension.
• Framework API: Input Reactor — InputDataComponent schema, reactor base class, and C++ extension.
• Framework API: Mover Context — Context state, mode authority, and C++ extension.

Back to top…

Movers & Grounders - GS_Unit

Breakdown

Movers and Grounders are multiple components on a Unit that are constantly changing activation based on the units state. When a mover is active, it freely processes the unit’s movement based on it’s functionality. At any moment, through internal or external forces, the Movement, Rotation, or Grounding state can change, which disables the old movers, and activates the new one to continue controlling the Unit.

Input Reader
    ↓  InputReactorRequestBus::FeedInputEvent
GS_InputReactorComponent
    ↓  dispatches by event name and phase
Reaction types  (KeyboardMovement / JoypadMovement / Jump)
    ↓  MoverContextRequestBus::SetMoveInputAxis
GS_MoverContextComponent
    ↓  ModifyInputAxis() → camera-relative
    ↓  GroundInputAxis() → ground-projected
    ↓  MoverContextNotificationBus::MovementModeChanged("Free")
GS_3DFreeMoverComponent  [active when mode == "Free"]
    ↓  AccelerationSpringDamper → rigidBody->SetLinearVelocity
GS_PhysicsRayGrounderComponent  [active when grounding mode == "Free"]
    ↓  MoverContextRequestBus::SetGroundNormal / SetContextState("grounding", ...)
    ↓  MoverContextRequestBus::ChangeMovementMode("Slide")  ← when slope too steep
GS_3DSlideMoverComponent  [active when mode == "Slide"]

The Slide mover activates when the Unit is walking on too steep an angle. It takes control over the unit, slides down the hill, then restores the previous movement behaviour.

• The Basics: Mover Context — Movement modes, grounding states, and configuration.
• The Basics: Movement — Mover types, grounder types, and ScriptCanvas usage.
• Framework API: Input Reactor — InputDataComponent schema, reactor base class, and C++ extension.
• Framework API: Mover Context — Context state, mode authority, and C++ extension.
• Framework API: Movers — Mover and grounder components, movement APIs, and C++ extension.

Back to top…

2.4 - Templates List

All GS_Play extension types are generated through the ClassWizard CLI. The wizard handles UUID generation, cmake file-list registration, and module descriptor injection automatically. Never create these files from scratch.

python ClassWizard.py \
    --template <TemplateName> \
    --gem <GemPath> \
    --name <SymbolName> \
    [--input-var key=value ...]

Contents

• GS_Core
• GS_Interaction
• GS_Unit
• GS_UI
• GS_Juice
• GS_PhantomCam
• GS_Cinematics
• Registration Quick Reference

GS_Core

Full details: GS_Core Templates

GS_Core also ships the GS_Core Project template, and GS_Complete ships GS_Complete Project — full O3DE project templates with the managers already wired up. See GS_Core Templates.

GS_Interaction

Full details: GS_Interaction Templates

GS_Unit

Full details: GS_Unit Templates

GS_UI

Full details: GS_UI Templates

GS_Juice

Full details: GS_Juice Templates

GS_PhantomCam

Full details: GS_PhantomCam Templates

GS_Cinematics

Full details: GS_Cinematics Templates

Registration Quick Reference

2.5 - Powerful Utilities

Powerful Utilities Outline

Powerful Utilities

2.6 - Glossary

GS_Play Definitions

Acoustic Material

A preset describing how a surface treats sound — how much it absorbs, scatters and transmits. Applied to acoustic geometry so a curtain muffles where concrete rings. (GS_AudioPro)

Action

An Action is a reusable, entity-scoped behavior triggered by name. Actions are authored as ActionComponent instances and fired via ActionRequestBus. Any trigger source — a physics zone, dialogue effect, another action, or scripted logic — can invoke an action by name without needing a direct reference to the target component.

Babble

Babble is procedural audio vocalisation synchronized to the Typewriter text display system in GS_Cinematics. The BabbleComponent generates tones keyed to a speaker’s identity and tone configuration, producing low-fidelity speech sounds as each character is revealed. See Babble API.

Controller

See Unit Controller.

Apply Target

What an option does to the engine when its value changes — a console variable, a window mode, an audio channel, or nothing at all. Composed onto an option separately from its widget, and the extension point for adding your own settings.

Audio Event

A named sound the game can fire. Carries its own pooling, variation, distance falloff and concurrency settings, so firing one is always just a name.

Coyote Time

Coyote Time is a grace period during which a grounded jump remains valid for a brief window after the unit walks off a ledge. It prevents the frustrating experience of pressing jump a frame too late when stepping off an edge. Configured per mover component as a float duration in seconds.

Custom (preset)

The active preset name when the current values no longer match any defined preset. Not a stored state — it is simply what “no preset matches” resolves to.

Debug Mode

Debug Mode is a setting on the Game Manager component that makes the game start in the current editor level instead of navigating to the title stage. All manager initialization and event broadcasting proceed normally — only the startup navigation changes. Use it for rapid iteration on any level without going through the full boot flow.

Headless

A manager set to drive its own startup with no Game Manager in the project. The way a single GS feature is deployed into a project that is not built on GS_Play.

Extensible

Extensible means able to be inherited from to augment and expand on the core functionality. Extensible classes and components, identified by the extensible tag in the documentation, are those available on the public Gem API build target and usable across gem and project boundaries. Extensible classes usually have ClassWizard templates to rapidly generate child classes.

Feedback Sequence

A Feedback Sequence is a data asset (.feedbackmotion) that drives world-space entity property animations — position, rotation, scale, material parameters — over time. Sequences are played on entities via GS_FeedbackRequestBus. Track types within a sequence are polymorphic and extensible via the FeedbackMotionTrack ClassWizard template. See Feedback System API.

Grounder

A Grounder is a component that detects whether a unit is standing on a surface and reports the ground normal, surface material, and grounded state. Grounders feed data to movers and to coyote time logic. The built-in GS_PhysicsRayGrounderComponent uses a downward raycast. Custom grounders can be created with the Grounder ClassWizard template. See Movement API.

Input Data

Input Data is a structured snapshot of a player’s current input state: movement vectors, button states, and action flags. It is held by GS_InputDataComponent on the controller entity and updated each frame by an InputReaderComponent. Input Reactor components read from this snapshot to translate intent into unit commands. See Input Data API.

Input Profile

An Input Profile is a named mapping between hardware input events and GS_InputData fields. Profiles are defined in the GS_Options system and can be swapped at runtime to support multiple control schemes (gamepad, keyboard/mouse, accessibility layouts). See GS_Options API.

Input Reactor

An Input Reactor is a component on the unit entity that reads GS_InputData from the controller and translates it into movement vectors or action bus calls. Input Reactors are the bridge between the controller’s intent and the unit’s subsystems. Custom reactors are created with the InputReactor ClassWizard template. See Input Data API.

Input Reader

An Input Reader is a component on the controller entity that polls hardware input events and writes them into GS_InputDataComponent. It is the hardware-facing end of the input pipeline. The built-in GS_PlayerControllerInputReaderComponent handles standard gamepad and keyboard events. Custom readers are created with the GS_InputReaderComponent ClassWizard template. See Input Data API.

Interface Contract

An Interface Contract is a neutral, cross-gem agreement collected in GS_Core/Interfaces so feature gems depend on the contract rather than on each other’s internals. There are three kinds: TypeBase (a pickable Strategy base — subclass and reflect to extend), Emit (a one-way *EmissionBus observation signal), and Exchange (a two-way *ExchangeBus query). See Core Interfaces.

Manager

A Manager is a component that extends GS_ManagerComponent and registers with the Game Manager at startup. Managers are spawned by the Game Manager, initialized in a guaranteed two-stage sequence, and made globally accessible via EBus. Each GS_Play gem that provides a system component (Save, Stage, UI, Audio, etc.) includes a manager.

Modular

Modular describes a system or feature that is self-contained with clear boundaries between its internal structure and external integrations. Base functionality has no outside dependencies beyond GS_Core, ensuring that when you interface with it, no additional gems are required for it to work. GS_Core itself is the sole shared dependency across all GS_Play gems. Some modular features optionally integrate with O3DE subsystems (for example, GS_UI depends on LyShine).

Mix Effect

One of the 22 DSP processors in GS_Audio — filters, EQ, delay, reverb, character effects and utilities. Authored as a named, ordered chain on a component, and surfaced again as graph nodes in GS_AudioPro.

Motion Composite

A Motion Composite is a named grouping of motion layers within GS_Motion that play and blend together. Composites allow multiple concurrent animations (e.g., a camera shake layered over a position tween) to be authored, started, and stopped as a unit.

Motion Proxy

A Motion Proxy is a lightweight target object used by GS_Motion to animate values that are not directly addressable on a component. Proxies act as intermediate containers; the animation writes into them, and a binding reads the proxy value each frame and applies it to the real target.

Motion Track

A Motion Track is a single animatable property lane within a Feedback Sequence or UI Animation asset. Each track drives one property (e.g., position X, material tint alpha) over time using keyframe curves. Custom track types are registered via Reflect(context) and authored with a ClassWizard template (FeedbackMotionTrack or UiMotionTrack). See Feedback API and UI Animation API.

Mover

A Mover is a component that implements one locomotion mode for a unit: walking, swimming, climbing, floating, and so on. Each mover processes movement input and outputs a velocity or transform delta. The active mover is selected by name at runtime. Multiple movers can coexist on one entity; only one is active at a time. Custom movers are created with the Mover ClassWizard template. See Movement API.

Movement Mode

A Movement Mode is the named identifier of a mover component. Units switch modes by calling SetMovementMode with the mode string defined in the mover’s Activate(). Common examples: "Walk", "Swim", "Fly".

MoverContext

GS_MoverContextComponent transforms raw input intent into mode-aware movement commands and manages which movement mode is active at any given moment. It holds movement profiles and routes input to the correct mover. Only one mover runs at a time — mode switches activate a different mover, not a blend of multiple. See Movement API.

Option Profile

An asset declaring the settings a game exposes — each with a key, a widget kind and an apply target. Multiple profiles stack and merge by key.

Polymorphic Array

The framework’s convention for an extensible type set: a vector of pointers to a reflected abstract base, where the serializer supplies the type picker. See Patterns.

Paper Performer

A Paper Performer is a billboard-based character rendering approach for 2.5D and top-down games. The PaperFacingHandlerComponent keeps a sprite quad oriented toward the active camera or a configurable facing target each tick. Custom facing strategies can be created by extending PaperFacingHandlerBaseComponent. See Paper Performer API.

Performer

A Performer is a character entity registered with the GS_PerformerManagerComponent. Performers are addressable by a unique name string and support skin slot swapping, locomotion hook binding, and optional head tracking. The Performer Manager is the lookup point for retrieving performer entities by name at runtime. See Performer API.

Phantom Camera

A Phantom Camera is a virtual camera component (GS_PhantomCameraComponent) that holds a complete camera state: FOV, clip planes, follow target, look-at target, offsets, and priority. Phantom cameras do not render — they are candidate states. The Cam Core blends the real camera toward the highest-priority phantom. Custom behavior is added by extending the component with the PhantomCamera ClassWizard template. See Phantom Cameras API.

Possession

Possession is the relationship between a Unit Controller and a Unit. A controller possesses a unit by calling Possess, gaining authority over its movement and actions. A unit can only be possessed by one controller at a time. Possession is released by calling DePossess. Ownership changes are observed through the GS_Core PossessionEmissionBus contract. See Unit Controllers API.

Pulse / Pulsor

A Pulse is a typed data payload broadcast from an emitter trigger volume into the Pulsor system. A Pulsor Emitter fires pulses when triggered; Pulsor Reactors on other entities receive pulses on a matching named channel. New pulse types are created with the PulsorPulse ClassWizard template. See Pulsors API.

Reactor

A Reactor is a component that receives Pulses on a named channel from the Pulsor system and executes a response. Reactors subscribe to a specific pulse type and channel name. Multiple reactors can listen on the same channel simultaneously. New reactor types are created with the PulsorReactor ClassWizard template. See Pulsors API.

Record / RecordKeeper

A Record is a named integer value stored persistently in the GS_Save system as a flat key-value entry. Records are used for progression flags and counters — quest state, NPC disposition, collected items, and similar global data. The RecordKeeperRequestBus provides HasRecord, SetRecord, GetRecord, and DeleteRecord. Records persist alongside the save file and survive level transitions. See GS_Save API.

Signal Chain

The fixed order every sound travels: emission, environment, binaural, volume channel, master. See the Audio Signal Model.

Skin Slot

A Skin Slot is one addressable mesh layer in a modular character’s appearance composition. Each slot holds an actor asset and a list of material overrides. PerformerSkinSlotComponent manages one slot; SkinSlotHandlerComponent manages the full set for a character and applies PerformerSkinSlotsConfigProfile presets. See Performer API.

Stage Marker

A Stage Marker is a named world-space anchor entity used by GS_Cinematics to position NPCs during dialogue sequences. A Performance navigates or teleports the assigned NPC to the marker’s transform. Markers are registered by name with the Cinematics Manager. See Cinematics Manager API.

Standby

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

Startup Sequence

The Startup Sequence is the three-stage lifecycle the Game Manager runs before gameplay is ready: Stage 1 (Initialize) — each manager activates internally; Stage 2 (SetupManagers) — all managers connect to each other; Stage 3 (StartupComplete) — the game is fully ready. Listen to OnStartupComplete on GameManagerNotificationBus to know when it is safe to begin gameplay.

Timeline Expansion

Timeline Expansion refers to the extensibility layer of GS_Cinematics that allows new track and key types to be added to the dialogue sequence timeline. Custom tracks register via Reflect(context) and integrate with the sequencer’s playback engine. See Timeline Expansion API.

Spatialization

Everything that happens to a sound as it travels from its emission point to the listener — direction, distance, occlusion, environment. A property of the source, not an effect you add.

Trigger Channel

A Trigger Channel is the named string key used to match World Triggers to Trigger Sensors. A trigger fires events on its channel name; any sensor listening to the same channel name receives the event. Channels are free-form strings authored in the component properties.

Trigger Sensor

A Trigger Sensor is a component that listens on a named Trigger Channel and executes a response when an event fires on that channel. New sensor types are created with the TriggerSensor ClassWizard template. See World Triggers API.

Unit

A Unit is any entity possessable by a controller. The GS_UnitComponent marker transforms an ordinary entity into a unit, registering it with the Unit Manager and exposing the possession interface. The unit provides the body (movement, collision, visuals); the controller provides the brain (input or AI). See Units API.

Volume Channel

A named group of sound types — voice, music, environment — with its own level, feeding master. What an options menu’s audio sliders drive.

Unit Controller

A Unit Controller is a component that possesses a unit entity and drives its behavior. The base GS_UnitControllerComponent handles possession, placement helpers, and unique naming. GS_PlayerControllerComponent adds player input integration; GS_AIControllerComponent adds AI hooks. Custom controllers are created with the UnitController ClassWizard template. See Unit Controllers API.

World Trigger

A World Trigger is a component that fires a named event on a Trigger Channel when its activation condition is met — volume entry, exit, proximity, or custom logic. New trigger types are created with the WorldTrigger ClassWizard template. See World Triggers API.

O3DE Source Definitions

AZ::Component

AZ::Component is the base class for all O3DE components. All GS_Play components ultimately inherit from it, either directly or through a GS_Play base class. It provides the Activate(), Deactivate(), GetProvidedServices(), and Reflect() interface that the O3DE component system calls at runtime.

AZ::Data::AssetData

AZ::Data::AssetData is the base class for O3DE asset types. Custom data assets in GS_Play (such as FeedbackMotionAsset, PerformerSkinSlotsConfigProfile, save records) derive from this class and are serialized by the Asset Processor.

AZ::EntityId

AZ::EntityId is the unique identifier for an entity in O3DE. It is the primary address type for ById EBus calls. An invalid (null) entity ID evaluates as AZ::EntityId::IsValid() == false. Most GS_Play bus calls take an AZ::EntityId as their address.

Class Wizard

The Class creation utility built natively into the O3DE codebase. Use the Class Wizard to create many common classes needed for O3DE project development. GS_Play extends the Class Wizard with gem-specific templates for generating extension classes. See ClassWizard reference.

Component

A Component in O3DE is a discrete unit of behavior or data that lives on an Entity. Components are authored in C++ as classes inheriting from AZ::Component, reflected into the engine’s serialization and editing systems, and added to entities in the Editor. GS_Play provides pre-built component types for all its subsystems.

EBus

An EBus (Event Bus) is O3DE’s primary inter-component communication mechanism. It is a typed, address-routed publish/subscribe bus. “Request” buses carry method calls to a handler; “Notification” buses broadcast events to listeners. Buses can be addressed by entity ID (ById), by a custom address, or broadcast to all handlers. All GS_Play public APIs are exposed as EBus interfaces.

EditContext

AZ::EditContext is the O3DE reflection context that controls how a type appears in the Editor Inspector. EditContext entries define display names, category, tooltip, slider limits, and which fields are visible. It is accessed from inside Reflect(context) after the SerializeContext block. See O3DE Reflection Rules in project instructions for placement constraints.

Entity

An Entity in O3DE is a container of components. Entities themselves have no behavior — all behavior comes from the components attached to them. Entities are identified by an AZ::EntityId and can be loaded from prefabs, spawned at runtime via EntitySpawnTicket, or created procedurally.

EntitySpawnTicket

An AZ::EntitySpawnTicket is the runtime handle for a spawned entity or prefab instance in O3DE. It keeps the spawned entity alive as long as the ticket is held. Releasing the ticket destroys the spawned entities. GS_Play’s Unit Manager and Stage Manager use spawn tickets to manage spawned unit and manager entities.

Gem

A Gem is O3DE’s modular project extension unit — equivalent to a plugin or package. Each GS_Play subsystem is packaged as a gem (GS_Core, GS_Unit, GS_UI, etc.). Gems declare their public API via build targets, and projects opt in by listing gems in their project configuration.

Module Descriptor

A Module Descriptor is the O3DE gem entry point — a class derived from AZ::Module that registers component type descriptors with the engine on startup. Every GS_Play gem has a module descriptor, and the ClassWizard templates automatically add new component descriptors to it when generating extension classes.

O3DE

Open 3D Engine — the open-source 3D engine on which GS_Play is built. Maintained by the Linux Foundation. O3DE provides the entity-component framework, asset pipeline, physics integration (PhysX), UI system (LyShine), animation (EMotionFX), and scripting (Script Canvas, Lua) that GS_Play builds upon.

Prefab

A Prefab in O3DE is a reusable, nestable entity hierarchy saved as a .prefab file. Prefabs are the O3DE equivalent of Unity prefabs or Unreal Blueprints at the entity composition level. GS_Play’s Game Manager, unit templates, and manager entities are typically authored and spawned as prefabs.

ReflectContext

AZ::ReflectContext is the base class for all O3DE reflection contexts. The Reflect(AZ::ReflectContext* context) static method on each component is called by the engine during startup and accepts a ReflectContext that may be cast to SerializeContext, EditContext, BehaviorContext, or others. Each context controls a different aspect of how the type is surfaced to the engine.

SerializeContext

AZ::SerializeContext is the O3DE reflection context that controls how a type is serialized — to .prefab files, save data, and asset files. It defines which fields are persisted, the type version, and the class hierarchy. It is the first context accessed in a Reflect() implementation. Placing ->Attribute(AZ::Edit::Attributes::EnableForAssetEditor, true) in SerializeContext (not EditContext) is required for asset types to appear in the Asset Editor.

Templates

Templates are pre-designed packages that allow the generative creation of gems, components, classes, and file types by copying and modifying template files to meet systemic needs. In GS_Play, ClassWizard templates handle UUID generation, cmake file-list registration, and module descriptor injection automatically. See the Templates List for all available GS_Play templates.

TypeId / UUID

A TypeId (also called UUID in O3DE context) is the globally unique identifier assigned to every reflected C++ type. It is a 128-bit value expressed as a hex string in braces, e.g. {A1B2C3D4-...}. The ClassWizard generates a new random UUID for each class it creates. UUIDs must be unique across all gems in a project; never duplicate them. They appear in AZ_COMPONENT_IMPL and in SerializeContext ->Class<>() declarations.

2.7 - Links

GS_Play

Legal & Press

Community

Genome Studios

O3DE

3 - The Basics

GS_Play is a full production set of modular features that can all be individually toggled on to enable only the features you need for your project. The “Basics” section covers what each feature set does, how to work with it from the editor and scripts, and what events and nodes are available — without requiring deep architectural knowledge.

If you are new to GS_Play, start with Get Started first. If you need architecture-level detail, component internals, or extension guides, use the Framework API section instead.

How This Section Is Organized

Each gem section follows this structure:

Gem overview page — What the gem does, the problems it solves, and a summary of its feature sets with links to feature sub-pages.

Feature sub-pages — One page per feature set. Each covers:

• What it does and what components are involved.
• Editor setup for drop-in use.
• Relevant ScriptCanvas nodes and EBus events.
• A quick reference table.
• Links to the Framework API for deeper reference.

Pages in this section deliberately omit architecture internals, extension code, and low-level component details. If you need those, follow the Framework API links at the bottom of each page.

Sections

3.1 - GS_Core

GS_Core is the required foundation for every GS_Play enabled project. All other GS gems depend on it to drive their complex behaviour, and utilize its systemic features. It provides the game startup sequence, persistence, level loading, input handling, a triggerable action system, and a shared utility library.

If you have not set up GS_Core yet, start with the Simple Project Setup guide before reading further.

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

Quick Navigation

Installation

GS_Core is a required gem. It will be added to your project when you enable any other GS_Play gem.

For a complete guided setup, follow the Simple Project Setup guide or video tutorial.

Follow these steps in particular:

1. Configure Project
2. Prepare Managers
3. Prepare Startup

Quick Installation Summary

Once the gem is registered to your project:

1. Create a Game Manager prefab and place it in every level.
2. Create prefabs of any managers you wish to utilize in your project
3. Add all the manager prefabs to your GameManager Managers list.
4. Implement a way to activate “Begin Game”
   • Create a UI to fire New Game, or Load Game.
   • Create a Script to fire New Game, or Load Game OnStartupComplete.
   • Toggle “Debug Mode” on. This skips through the begin game process.

GS_Managers

Controls the game startup lifecycle — spawning and initializing all manager systems in a guaranteed order, then providing top-level game navigation: New Game, Continue, Load Game, Return to Title, and Quit. The starting point for any game-wide behavior.

GS_Managers API

GS_Save

Handles all save and load operations, including entity state persistence across level loads and simple key-value record tracking for global flags and counters.

GS_Save API

GS_StageManager

Manages level loading and navigation. Place named Exit Points in your levels to control where the player arrives, and use Stage Data components to configure per-level settings like NavMesh references and spawn configuration.

GS_StageManager API

Settings

Declare the options your game exposes — volume, graphics quality, resolution, accessibility — as data, and the framework applies them, saves them and restores them next launch. Presets give you Low / Medium / High with no extra work.

Settings API

GS_Options

Manages player input through swappable Input Profile assets and Input Reader components, with group-level enable/disable for suppressing input during menus, cutscenes, or transitions.

GS_Options API

Debugging

Press play on the level you are editing and actually run that level, with Debug Mode. Then inspect and drive the running game from the in-game GS_Play menu — change any setting live, balance the audio mix, or switch cameras.

Debugging API

Systems

Core framework systems used across multiple gems: the GS_Actions triggerable behavior system and the GS_Motion track-based animation engine.

Systems API

Utilities

A collection of shared tools: easing curves (40+ types), spring dampers for smooth value following, weighted random selection, color and float gradients, spline helpers, and Physics Trigger Volume components.

Utilities API

See Also

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

• Framework API: GS_Core

For step-by-step project setup:

• Simple Project Setup

Get GS_Core

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

3.1.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.

3.1.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.1.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.

3.1.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.

3.1.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.

3.1.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.

3.1.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.

3.1.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.

3.1.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.

3.1.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.

3.2 - GS_AI

GS_AI provides the structural foundation for AI-driven entity behavior. It defines the base architecture that AI controller implementations build upon, integrating with the Unit system’s controller pattern to drive NPC entities through behavior logic rather than player input.

For architecture details and extension patterns, see the GS_AI API.

How It Works

GS_AI establishes the conventions and base classes for AI in the GS_Play framework. AI controllers extend the Unit Controller pattern — the same mechanism that player controllers use to drive units. Switching an entity between player control and AI control is a standard possession swap with no special handling required.

AI implementations listen to the same game lifecycle events as every other GS_Play system. AI controllers respond to standby mode, stage transitions, and manager lifecycle broadcasts automatically through the manager pattern.

Integration Points

See Also

For the full API and extension patterns:

• Framework API: GS_AI

For related systems:

• The Basics: Unit Controllers

Get GS_AI

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

3.3 - GS_Audio

GS_Audio is the audio system for GS_Play. It plays sounds, mixes them, and places them in the world — and it comes in two gems.

The dividing line is how you author, not how good the audio is. The free gem carries the complete effect palette and the same spatial audio Pro uses. Pro adds a visual canvas to build sounds on, plus music, speech and real acoustics.

Each feature below is tagged Base or Pro so you can tell which gem it needs.

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

Start Here

If you are new to the audio system, read the Audio Signal Model first. It is short, and it explains how a sound travels from its source to your speakers — which stages exist, what order they run in, and what the words source, spatialization and volume channel mean here.

Two things from it save the most time:

• Spatialization is a property of the sound, not an effect you add. Position a source and it is spatialized. There is no spatializer to drop into a chain.
• Reverb and real geometric reflections are alternatives, not layers. Use one or the other, never both, or the sound double-reverbs.

Quick Navigation

Installation

GS_Audio requires GS_Core and the MiniAudio gem. Add all three to your project’s gem dependencies.

Quick Installation Summary

1. Enable the GS_Audio gem in your project configuration.
2. Create an Audio Manager prefab and add it to the Game Manager’s Managers list.

No Game Manager in your project? Add the Audio Manager to your level and tick Headless on it. It will start itself, and you get the audio system with no dependency on the GS_Play startup sequence — useful when audio is the only GS feature you want.

Adding the premium tier

Enable GS_AudioPro alongside GS_Audio and use the Pro Audio Manager component on your manager prefab instead of the base one. Everything else is authored on that component exactly as before.

Audio Manager

Base. The Audio Manager is the singleton controller for the whole audio system. It initializes the engine, owns the mixing channels, loads your audio event libraries, and carries the listener.

The listener is worth knowing about early: there is no separate listener component. The manager holds it and you point it at an entity. You can also split it — proximity following your character while facing follows your camera — which is the recommended setup for third-person games.

Audio Manager API

Audio Events

Base. A named sound your game can fire. Author events in a library asset, assign the library to the Audio Manager, then play sounds by name from script, C++ or a trigger.

Variation, distance falloff, concurrency caps and entity tracking are all configured on the event — the call site is always just a name. Events can play recorded clips, procedural noise, or chiptones, and clip pools mean a footstep never repeats identically.

Audio Events API

SFXR Profiles

Base. Sound effects made entirely of numbers — coins, lasers, jumps, blips — with no recording and no audio files. Design one in the browser, paste it into an asset, and pool a few mutations so the sound varies.

27 profiles ship with the gem, so a new project has working effects immediately.

SFXR Profiles API

Mixing & Effects

Base. Named mixing channels, each with its own volume and an optional chain of effects — filters, EQ, shelving, delay, reverb, and character effects like chorus, flanger and bit-crushing.

Environmental influence lets a world volume push effects onto a channel while the listener is inside it: walk into a cave, everything gains reverb; walk out and it lifts. Influences stack by priority and are keyed to the entity that applied them.

Mixing & Effects API

Spatial Audio

Base. Positioned sounds are placed in the world automatically — direction, distance falloff, and HRTF processing so a sound feels like it comes from somewhere. There is nothing to add to a sound to make it happen.

The one thing you configure is the listener. In third person you split it: distance measured from your character, direction from your camera.

Spatial Audio API

Audio Pro

Pro. The four features below all ship in GS_AudioPro. Start at the Audio Pro overview for what the premium tier adds, how it attaches to the free gem, and where each feature’s bus lives.

Audio Pro Overview API

Audio Event Graph

Pro. A visual node editor for authoring complex sound events. Build a sound as a graph — sources, filters, effects and conditional routing, connected on a canvas — with a Start / Loop / Finish phase lifecycle and runtime variables that let gameplay reshape the sound while it plays.

This is the premium tier’s headline authoring feature. The free tier reaches the same processors through named effect chains on components.

Audio Event Graph API

Score Arrangement

Pro. Multi-layer music assets. An arrangement defines time signature, tempo and fade behaviour, and holds layers that can be brought in and out independently — so the music adds a drum line as combat starts and drops it when it ends.

Score Arrangement API

Klatt Voice Synthesis

Pro. Text-to-speech built on Klatt formant synthesis. It generates voice from parameters rather than playing recordings, so a project can give hundreds of characters distinct voices with no audio assets and no recording sessions. Supports 3D spatial audio and inline tags that change pitch, speed or waveform partway through a line.

Klatt Voice API

See Also

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

• Framework API: GS_Audio
• Audio Signal Model

For step-by-step project setup:

• The Basics: GS_Managers

Get GS_Audio

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

3.3.1 - Audio Manager

Base — ships in GS_Audio.

The Audio Manager is the one component the audio system needs. It starts the engine, holds your volume channels, loads your event libraries, and carries the listener that every positioned sound is measured against.

It is a GS manager, so it plugs into the Game Manager’s startup like the rest — or runs on its own if your project does not have one.

For component properties and the full API, see the Framework API reference.

Contents

• Setting It Up
• Using Audio Without a Game Manager
• What It Manages
• Setting the Listener
• Quick Reference
• Glossary
• See Also

Setting It Up

1. Create an entity and add the GS_AudioManagerComponent.
2. Configure your volume channels — a named list such as Music, SFX, Voice, Ambience.
3. Assign your event libraries.
4. Turn the entity into a prefab, set the wrapper entity to Editor Only, and save.
5. Add the prefab to the Game Manager’s Startup Managers list.

This is the same prefab pattern every GS manager uses — see The Basics: GS_Managers if you have not set one up before.

Using Audio Without a Game Manager

If audio is the only GS feature your project uses, you do not need the manager stack at all.

Add the Audio Manager to your level, tick Headless on it, and press play. It starts itself, and everything on these pages works exactly as documented. No Game Manager, no startup sequence, no other managers.

This is the intended path for dropping GS_Audio into a project that is not otherwise built on GS_Play.

What It Manages

Setting the Listener

There is no listener component. The manager holds the listener and you point it at an entity.

For first person, point it at your camera or player and you are finished. For third person, split it — distance measured from your character, direction from your camera. See Spatial Audio for why that combination is the one you want.

If you never set a listener, the manager uses its own entity and warns. Audio will work, but it will be positioned from wherever your manager prefab happens to be.

Quick Reference

Glossary

See Also

For the full API:

• Framework API: Audio Manager

For related systems:

• The Basics: Audio Events — what the libraries hold
• The Basics: Mixing & Effects — the channels it owns
• The Basics: Spatial Audio — what the listener feeds
• The Basics: GS_Managers — the manager pattern

Get GS_Audio

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

3.3.2 - Audio Events

Base — ships in GS_Audio.

An audio event is a named sound your game can fire. You author events in an event library asset, assign the library to the Audio Manager, and then play sounds by name from anywhere — script, C++ or a trigger volume.

Everything that makes a sound behave well in a game — variation, distance falloff, a cap on how many can play at once, following a moving object — is configured on the event, not at the call site. Firing one is always just a name.

For component properties and the extension guide, see the Framework API reference.

Contents

• Creating an Event Library
• Choosing an Event Type
• Making Sounds Vary
• Distance and Concurrency
• Firing Events
• Quick Reference
• Glossary
• See Also

Creating an Event Library

1. In the Asset Browser, create a new Audio Event Library (.aev) asset.
2. Add an event to it and pick a type from the dropdown.
3. Give it an Event Name — this is what you fire by.
4. Set its Mixing Channel so it routes to the right volume channel.
5. Assign the library to your Audio Manager’s library list.

Libraries can also be added and removed while the game is running, which is how you would stream in a level’s sound set.

Choosing an Event Type

Noise and Sfxr events need no audio files at all. They generate their sound at runtime, which makes them useful early in a project when the audio pass has not happened yet.

Making Sounds Vary

Both Pool and Sfxr events hold a pool, and pick from it at random on every fire.

This is the single highest-value thing to know about the event system. A footstep event with one clip sounds mechanical after three steps. The same event with five recorded variants sounds like walking — and the code firing it does not change at all.

For Sfxr events the pool is even cheaper to fill: generate a sound at sfxr.me, press mutate a few times, and import each result as a profile. Five mutated explosions in one pool means the explosion never repeats identically.

A pool of one is perfectly valid. It is just a sound that does not vary.

Distance and Concurrency

The last two matter more than they look. A collision sound fired from a physics callback can trigger dozens of times in a few frames; the concurrency limit and repeat hold are what keep that from turning into noise, without any logic on your side.

Firing Events

Three calls on AudioManagerRequestBus, all resolving the event by name:

PlayEventOnEntity keeps tracking the entity as it moves, so it is the right choice for anything attached to a character, vehicle or projectile.

Quick Reference

Glossary

See Also

For the full API and the extension guide:

• Framework API: Audio Events

For related systems:

• The Basics: Audio Manager — loads your libraries
• The Basics: SFXR Profiles — what Sfxr events play
• The Basics: Mixing & Effects — where an event’s channel routes

Get GS_Audio

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

3.3.3 - SFXR Profiles

Base — ships in GS_Audio.

SFXR profiles are sound effects made entirely of numbers. No recording, no audio files, no disk space worth mentioning — a coin pickup, a laser shot or a jump blip described as a parameter set.

They are the fastest way to get real sound into a project, and 27 of them ship with the gem, so a new project has working effects before it has any audio of its own.

For the parameter reference, see the Framework API reference.

Contents

• Making a Sound
• Using Profiles
• Building a Variation Pool
• What Ships With the Gem
• Glossary
• See Also

Making a Sound

The intended workflow runs through the browser, because that is where the instant preview is.

1. Open sfxr.me.
2. Pick a generator — Pickup, Laser, Explosion, Powerup, Hurt, Jump, Blip — and press it until you like what you hear. Or press Mutate on a sound you already like.
3. Press Serialize and copy the JSON it gives you.
4. In O3DE, create a new SFXR Profile (.sfxrprofile) asset.
5. Open its Import from sfxr.me group and paste the JSON into the field.
6. The parameters populate. Save.

You can also edit the 24 parameters by hand on the asset afterwards — the import is a starting point, not a lock.

Using Profiles

A profile is played through an Sfxr audio event:

1. Add an event to your event library and set its type to Sfxr.
2. Add one or more profiles to the event’s profile list.
3. Fire the event by name like any other sound.

Audio Pro users can also drop an Sfxr node into an Audio Event Graph and feed it profiles the same way.

Building a Variation Pool

An Sfxr event holds a list of profiles and picks one at random every time it fires.

This is where the browser workflow pays off. Make an explosion you like, press Mutate four times, and import all five results. Drop them into one event and your explosion never sounds the same twice — with no logic anywhere in your game.

An event with one profile is fine, and an event with an empty list is simply silent.

What Ships With the Gem

27 profiles in the gem’s Assets/SFXR Profiles/ folder:

• 7 classic presets — Coin, Laser, Explosion, Powerup, Hurt, Jump, Blip.
• 20 named custom profiles.

Use them directly, or open one and mutate it into something of your own.

Glossary

See Also

For the parameter reference:

• Framework API: SFXR Profiles

For related systems:

• The Basics: Audio Events — how profiles get played

Get GS_Audio

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

3.3.4 - Mixing & Effects

Base — ships in GS_Audio.

Mixing has two jobs, and they are worth keeping separate in your head.

Volume channels group sounds by what kind of sound they are — voice, music, environment, combat — so a player can turn one down without touching the others. This is what your options menu drives.

Effect chains process the signal — filters, EQ, delay, reverb, and character effects like chorus and bit-crushing. You build a chain on a component, name it, and point sounds at that name.

All 22 effects are available in the free gem. Audio Pro authors the same processors on a visual canvas instead.

For component properties and the full effect reference, see the Framework API reference.

Contents

• Volume Channels
• Building an Effect Chain
• The Effects
• Environmental Influence Zones
• Quick Reference
• Glossary
• See Also

Volume Channels

Channels are configured on the Audio Manager as a named list. Each audio event names the channel it routes to.

Set them up the way your options menu will present them — a Voice channel, a Music channel, an SFX channel — and wiring the sliders becomes trivial, because the options system can drive channel levels directly.

Channels are independent of position. A footstep, a spell and a line of dialogue are all spatialized the same way, and all three route to different channels.

Building an Effect Chain

1. Add a Mix Effect component to an entity.
2. Give it a Name — this is what sounds and other chains will target.
3. Add effects to its list. They run top to bottom.
4. Set its Output Target — another chain’s name, or a volume channel.

Then point sounds at it by setting an event’s Mixing Channel to your chain’s name. Channels and chains share one namespace, so a sound does not care which kind of thing it is aimed at.

Three things that make this easier than it sounds:

• Order does not matter. If a chain points at something that does not exist yet, the connection waits and completes when it appears. You never have to think about activation order.
• You can add chains at runtime. Sounds already playing through that channel pick up the new routing.
• One entity can hold several chains. Give each its own name and point one at another to compose them.

You can put a chain on the emitting entity to colour just that object’s sound, or use shared global chains for project-wide treatments. Both work, and most projects use both.

The Effects

Environmental Influence Zones

A world entity can push effects onto channels while the player is inside it — walk into a cave and everything gains reverb, walk out and it lifts.

Zones stack by priority, so overlapping zones resolve predictably rather than by whichever fired last, and each zone’s contribution is tracked against the entity that applied it so removing it is unambiguous.

Quick Reference

Glossary

See Also

For the full API and the effect reference:

• Framework API: Mixing & Effects
• Framework API: Mix Effects

For related systems:

• The Basics: Audio Manager — owns the channel list
• The Basics: Audio Events — how a sound picks its channel
• The Basics: Spatial Audio — positioning, which is separate from mixing

Get GS_Audio

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

3.3.5 - Spatial Audio

Base — ships in GS_Audio.

Spatial audio is handled for you. Fire a sound at a position or on an entity and it is placed in the world: direction, distance falloff, and HRTF binaural processing so it sounds like it is coming from somewhere rather than from inside your head.

There is nothing to add to a sound to make this happen, and nothing to add to a chain. The only thing you configure is the listener — where the player is hearing from.

For settings and behaviour detail, see the Framework API reference.

Contents

• Setting the Listener
• Third-Person: Splitting the Listener
• Distance Falloff
• What This Does Not Do
• Quick Reference
• Glossary
• See Also

Setting the Listener

There is no listener component to add. The Audio Manager carries the listener, and you point it at an entity.

For a first-person game, that is the whole setup — point it at the camera or the player and you are done.

If you set nothing, the manager falls back to its own entity and warns you. That fallback exists so the system is never silently broken, but it is not where you want your listener.

Third-Person: Splitting the Listener

In third person the camera and the character are in different places, and “where is the player hearing from” has two different right answers.

• How close a sound is should be measured from the character. Proximity is about your body.
• Which direction a sound is in should be measured from the camera. Left and right are about where you are looking.

So set them separately: