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_Cinematics
• GS_Core
• GS_Environment
• GS_Interaction
• GS_Juice
• GS_Performer
• GS_PhantomCam
• GS_UI
• GS_Unit
• Documentation

GS_Audio

Latest version: 0.6.0

Change Summary

Audio Event Graph — visual node-based sound event editor with data-flow evaluation, phase lifecycle, filters, effects, routing, pooling, and runtime variable control.

GS_Audio 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.5.0

Change Summary

First official base release. Ready for continued development and support. On the way to 1.0!

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.6.0
• 0.5.0

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 - 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.3 - 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.4 - Core Change Log

Logs

• 0.5.0

Core 0.5.0

• COOOOREEEEE

2.1.5 - 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.6 - 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.7 - 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.8 - 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.9 - 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.10 - 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.11 - 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

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

• 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

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
    ↓  InputDataNotificationBus::InputStateChanged
Input Reactor Components
    ↓  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_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

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.

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.

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.

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

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.

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.

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.

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.

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

Useful Links

Genome Studios

GS_HUB discord link

GS_Play Asset Store Page

gs_play branding guidelines

gs_play site terms of service

gs_play EULA

gs_play socials

genome socials

o3de site

o3de documentation

o3de branding guidelines

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

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

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

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 manages player-facing configuration and input handling. Its primary feature is the Input Profile system, which provides group-based input binding management that can be toggled at runtime without code changes.

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

Contents

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

Options Manager

The Options Manager is a singleton that holds the active Input Profile and makes it available to all Input Reader components. It responds to the Game Manager lifecycle automatically.

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.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.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 management gem for GS_Play. It provides a visual node-based audio event authoring system, a multi-layer music scoring system, mixing buses with effects chains, and a built-in Klatt formant voice synthesizer with 3D spatial audio. All audio features integrate with the GS_Play manager lifecycle and respond to standby mode automatically.

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

Quick Navigation

Installation

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

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

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.

Audio Manager

The Audio Manager is the singleton controller for the entire audio system. It initializes the audio engine, manages mixing buses, loads audio event libraries, and coordinates score playback. Like all GS_Play managers, it extends the Manager base class and plugs into the Game Manager’s startup sequence automatically.

Audio Manager API

Audio Event Graph

The Audio Event Graph is a visual node editor for authoring complex sound events. Build audio processing chains with source nodes, filter nodes, effects, and conditional routing — all connected in a graph that evaluates as a live data-flow pipeline. Supports phase lifecycle (Start / Loop / Finish) and runtime variable control for dynamic sound behavior.

Audio Event Graph API

Mixing & Effects

The mixing system provides named audio buses with configurable effects chains. Each bus can have filters applied — low pass, high pass, band pass, notch, peaking EQ, shelving, delay, and reverb. Audio Bus Influence Effects allow environmental zones to dynamically modify bus effects based on the listener’s position.

Mixing & Effects API

Score Arrangement

Score Arrangement Tracks are multi-layer music assets. Each arrangement defines a time signature, BPM, fade behavior, and a set of Score Layers — individual audio tracks that can be enabled or disabled independently. This allows dynamic music that adds or removes instrument layers based on gameplay state.

Score Arrangement API

Klatt Voice Synthesis

GS_Play includes a built-in text-to-speech system based on Klatt formant synthesis. The Klatt Voice component converts text to speech in real time with configurable voice parameters — frequency, speed, waveform, formants, and pitch variance. The system supports 3D spatial audio and inline KTT tags for expressive delivery.

Klatt Voice API

See Also

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

• Framework API: GS_Audio

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

The Audio Manager is the singleton controller for the entire audio system. It initializes the MiniAudio engine, manages mixing buses, loads audio event libraries, and coordinates score track playback. It also manages the instance lifecycle for Audio Event Graphs — pooling, firing, and releasing graph instances.

Like all GS_Play managers, it extends the Manager base class and responds to the Game Manager lifecycle automatically.

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

Contents

• What It Manages
• Audio Event Graph Instances
• Quick Reference
• Glossary
• See Also

What It Manages

Audio Event Graph Instances

The Audio Manager is the runtime entry point for the Audio Event Graph system. Two patterns are available:

Fire-and-Forget

The simplest pattern — the Manager handles everything automatically:

PlayAudioGraph(assetPath) → plays the graph → auto-cleans up when finished

Manual Instance Control

For sounds that need to be modified after starting — looping ambience, sounds driven by game state variables:

AcquireAudioGraph(assetPath) → instanceId
FireAudioGraph(instanceId)
SetAudioGraphVariable(instanceId, "paramName", value)   ← update at any time
SetAudioGraphEntity(instanceId, entityId)               ← 3D tracking
StopAudioGraph(instanceId) or FinishAudioGraph(instanceId)
ReleaseAudioGraph(instanceId)

The manager pools idle instances internally — acquiring and releasing is cheap.

Quick Reference

Audio Event Graph

Mixing & Score

Glossary

For full definitions, see the Glossary.

See Also

• The Basics: Audio Event Graph — Visual graph editor for sound events
• Framework API: Audio Manager — Full API reference
• The Basics: Mixing
• The Basics: GS_Managers

Get GS_Audio

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

3.3.2 - Audio Event Graph

The Audio Event Graph is a visual node-based editor for authoring complex sound events. Instead of a single clip pool, you connect sources, filters, effects, and routing nodes into a graph that evaluates as a data-flow pipeline. Each .audiograph file is one sound event. At runtime, the graph maps directly to a live audio processing chain.

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

Contents

• How It Works
• Phase Lifecycle
• Nodes
• Using Variables
• Playing at Runtime
• Quick Reference
• Glossary
• See Also

How It Works

Nodes in an Audio Event Graph evaluate left to right in topological order. Connections carry AudioRoute values — handles to a point in the audio processing chain. The signal flows through:

1. An Entry node gates which phase is active
2. Source nodes create and output audio
3. Filter and effect nodes process the signal
4. Routing nodes (If/Switch) direct the signal based on variables
5. The Output node wires everything to a mixing bus

Only nodes affected by a change re-evaluate — the rest are skipped. This makes variable-driven sound modification cheap even for complex graphs.

Phase Lifecycle

Every Audio Event Graph supports up to three phases:

Phases transition automatically: Start fires once, Loop repeats while looping is enabled, Finish plays when FinishAudioGraph() is called. Not all phases are required — a simple one-shot only needs Start.

Entry nodes share routing freely. A source wired to both Start and Loop phases produces sound in both.

Nodes

Source Nodes

Both support volume, pitch, delay, looping, and 3D spatialization.

Filter Nodes

LowPass, HighPass, BandPass, Notch, PeakingEQ, LowShelf, HighShelf — all take audio_in and output audio_out. Parameters (cutoff, Q, gain) can be set per-node or bound to graph variables.

Effect Nodes

Routing Nodes

IfNode and SwitchNode route AudioRoute values based on conditions or a selector variable. Use these for conditional audio paths — different sounds based on surface type, weather, or character state.

Output Node

Aud_OutputNode wires the final signal to a named mixing bus. Every graph needs exactly one Output node.

Using Variables

Declare variables in the Variable Panel. Bind them to filter parameter slots (right-click > Convert to Reference) or use If/Switch nodes to route based on them.

At runtime, setting a variable re-evaluates only the nodes that depend on it — the rest of the graph is untouched.

Common patterns:

Variables are set from gameplay code via the Audio Manager:

SetAudioGraphVariable(instanceId, "underwater", 0.8)
SetAudioGraphVariableBool(instanceId, "isSprinting", true)

Playing at Runtime

All Audio Event Graph playback goes through the Audio Manager.

Fire-and-Forget

For one-shot sounds with no runtime modification needed:

PlayAudioGraph("Assets/Audio/Explosion.audiograph")

Manual Control

For sounds that loop, need variable updates, or need explicit stopping:

1. AcquireAudioGraph(assetPath) — get an instance ID
2. SetAudioGraphLooping(id, true) — if it loops
3. SetAudioGraphEntity(id, entityId) — for 3D tracking
4. FireAudioGraph(id) — start playback
5. SetAudioGraphVariable(id, name, value) — update variables any time
6. StopAudioGraph(id) or FinishAudioGraph(id) — stop cleanly
7. ReleaseAudioGraph(id) — return the instance to the pool

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

• Framework API: Audio Event Graph — Full node catalog and extension guide
• The Basics: Audio Manager — Runtime playback API
• The Basics: Audio Events — Simpler fire-and-forget sound playback
• The Basics: Mixing — Mixing buses that graphs route through

Get GS_Audio

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

3.3.3 - Mixing & Effects

The mixing system provides named audio buses with configurable effects chains. Each bus can have multiple audio filters applied for real-time audio processing. Audio Bus Influence Effects allow environmental zones to dynamically modify bus parameters based on the listener’s position.

For component properties and filter types, see the Framework API reference.

Contents

• Available Filters
• Environmental Audio Influence
• Quick Reference
• Glossary
• See Also

Available Filters

Environmental Audio Influence

Audio Bus Influence Effects allow spatial zones to modify bus effects dynamically. When the listener enters an influence zone (like a cave or tunnel), the zone’s effects are applied to the specified bus with priority-based stacking. Multiple overlapping zones resolve by priority.

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: GS_Audio

For related systems:

• The Basics: Audio Manager

Get GS_Audio

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

3.3.4 - Score Arrangement

Score Arrangement Tracks are multi-layer music assets for dynamic, adaptive game music. Each arrangement defines a time signature, tempo, fade behavior, and a set of independently controllable Score Layers. This enables music that responds to gameplay — adding percussion during combat, muting melody during dialogue, or transitioning between intensity levels.

For asset structure and playback API, see the Framework API reference.

Contents

• How It Works
• Supported Time Signatures
• Glossary
• See Also

How It Works

A Score Arrangement Track is a data asset containing:

Each Score Layer is an independent audio stream within the arrangement. Layers can be enabled or disabled at runtime, creating dynamic music that evolves based on game state.

Supported Time Signatures

4/4, 4/2, 12/8, 2/2, 2/4, 6/8, 3/4, 3/2, 9/8

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: GS_Audio

For related systems:

• The Basics: Audio Manager

Get GS_Audio

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

3.3.5 - Klatt Voice Synthesis

GS_Play includes a built-in text-to-speech system based on Klatt formant synthesis. The KlattVoiceComponent converts text to speech in real time with configurable voice parameters. Voices are positioned in 3D space and attenuate with distance, making synthesized speech feel like it comes from the character speaking.

For component properties, voice parameter details, and the phoneme mapping system, see the Framework API reference.

Contents

• How It Works
• Voice Configuration
• KTT Tags
• Phoneme Maps
• 3D Spatial Audio
• Quick Reference
• Glossary
• See Also

How It Works

1. Configure a voice using a KlattVoiceProfile — set frequency, speed, waveform, formants, and pitch variance.
2. Assign a KlattPhonemeMap — maps text characters to ARPABET phonemes for pronunciation.
3. Speak text from ScriptCanvas or C++ — the system converts text to phonemes and synthesizes audio in real time.
4. Position in 3D — the voice component uses KlattSpatialConfig for 3D audio positioning relative to the entity.

Voice Configuration

KTT Tags

KTT (Klatt Text Tags) allow inline parameter changes within speech text for expressive delivery:

"Hello <speed=0.5>world</speed>, how are <pitch=1.2>you</pitch>?"

The KlattCommandParser processes these tags during speech synthesis, enabling mid-sentence changes to speed, pitch, and other voice parameters.

For the complete tag reference — all attributes, value ranges, and reset behavior — see the Framework API: KTT Voice Tags.

Phoneme Maps

Two base phoneme maps are available:

Custom phoneme overrides allow project-specific word pronunciations (character names, fantasy terms) without modifying the base map.

3D Spatial Audio

The KlattSpatialConfig controls how synthesized speech is positioned in 3D:

• Voices attenuate with distance from the listener.
• The KlattVoiceSystemComponent tracks the listener position and updates all active voices.
• Multiple characters can speak simultaneously with correct spatial positioning.

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: GS_Audio

For related systems:

• The Basics: Audio Manager

Get GS_Audio

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

3.4 - GS_Cinematics

GS_Cinematics is the complete dialogue and cinematic control system for GS_Play. It provides a node-graph authoring tool for branching dialogue sequences, a runtime sequencer with conditions and side effects, a UI layer for text display and player choice, and a Cinematics Manager for scene staging. Custom conditions, effects, and performance types are discovered automatically through O3DE serialization, so project-specific dialogue behaviors can be added without modifying the gem.

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

Quick Navigation

Installation

GS_Cinematics requires GS_Core, LyShine, and RecastNavigation. The node editor tools additionally require GraphCanvas and GraphModel as editor-only dependencies.

For a full guided walkthrough, follow the Simple Project Setup guide.

Quick Installation Summary

1. Enable the GS_Cinematics gem in your project configuration.
2. Create Cinematics Manager and Dialogue Manager prefabs, add to the Game Manager’s Managers list.
3. Create .dialoguedatabase assets with the Dialogue Editor (GS Tools > Dialogue Editor).
4. Place DialogueSequencer and DialogueUI components in your level.
5. Bake NavMesh in levels where PathTo performances will be used.

Cinematics Manager

The Cinematics Manager coordinates the begin and end of cinematic sequences, broadcasting enter/exit events so other systems know when to yield control. It maintains a registry of stage marker entities placed in each level — named anchor points that performers and cameras look up at runtime to determine positioning during a sequence.

Cinematics Manager API

Dialogue System

The Dialogue System is the authoring and runtime core. Dialogue is authored in the Dialogue Editor — a visual node graph tool — and stored in .dialoguedatabase container files holding actors and sequences. Each sequence is a graph of polymorphic nodes: text, selection, random branch, effects, and performances. At runtime, the sequencer walks the graph, evaluates conditions, executes effects, and emits events for the UI layer.

Dialogue System API

Dialogue UI

The Dialogue UI feature set puts dialogue text and player choices on screen. DialogueUI handles screen-space text display with a Typewriter for character-by-character reveal. DialogueUISelection renders player choices as selectable buttons. World-space variants place speech bubbles above actors. Babble plays audio tied to the active speaker. The DialogueUIBridge routes sequencer events to the correct UI implementation and routes player selection back.

Dialogue UI API

Performances

Performances are polymorphic actions that move or reposition actors during dialogue. MoveTo translates actors to named stage markers, PathTo navigates via NavMesh, and Reposition teleports instantly. All run asynchronously — the sequencer waits for completion before advancing. Custom performance types can be created through extending the class.

Performances API

See Also

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

• Framework API: GS_Cinematics

For step-by-step project setup:

• Simple Project Setup

Get GS_Cinematics

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

3.4.1 - Cinematics Manager

The Cinematics Manager is the GS_Core-integrated manager component for the GS_Cinematics system. It signals when a cinematic sequence begins and ends, broadcasts events so other systems — UI, movement, input — know when to yield control to a cutscene, and maintains a registry of named CinematicStageMarkerComponent entities placed in each level.

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

Contents

• Stage Markers
• Cinematic Events
• Starting and Ending Cinematics
• ScriptCanvas Usage
• Quick Reference
• Glossary
• See Also

Stage Markers

Stage markers are named anchor entities placed in each level that serve as spatial reference points for cinematic sequences. Performers and camera systems look up markers by name at runtime to determine where actors should stand, face, or move to during a cutscene.

This design decouples authored dialogue data from level-specific layout. The same sequence asset plays in any level as long as that level provides CinematicStageMarkerComponent entities with the expected names.

To register a marker, add CinematicStageMarkerComponent to an entity in the level and give it a name. The Cinematics Manager automatically discovers and registers all markers in the level on startup via RegisterStageMarker. At runtime, any system can retrieve a marker entity by name with GetStageMarker.

Cinematic Events

When a cinematic begins and ends, the Cinematics Manager broadcasts events on CinematicsManagerNotificationBus. Listen to these in any system that needs to yield or reclaim control during a cutscene — player input, HUD, AI, camera.

Starting and Ending Cinematics

Call BeginCinematic to signal that a cinematic is starting and EndCinematic when it completes. These calls broadcast EnterCinematic and ExitCinematic respectively. They do not drive animation or sequence playback directly — that is the role of DialogueSequencerComponent. The Cinematics Manager handles the global state change so all listening systems respond in one coordinated broadcast.

ScriptCanvas Usage

Reacting to Cinematic State

To pause gameplay systems when a cinematic starts and resume them when it ends, connect to CinematicsManagerNotificationBus:

Triggering a Cinematic

To start a cinematic from a trigger or cutscene entity, call BeginCinematic, drive the sequence through the Dialogue Sequencer, then call EndCinematic on completion:

Looking Up a Stage Marker

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: GS_Cinematics

For related systems:

• The Basics: Dialogue

• The Basics: GS_Managers

Get GS_Cinematics

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

3.4.2 - Dialogue System

The Dialogue System is the authoring and runtime core of GS_Cinematics. Dialogue is authored visually in the Dialogue Editor — a node graph tool where sequences are built from Text, Selection, Effects, and Performance nodes inside a .dialoguedatabase container file. At runtime, GS_DialogueManagerComponent manages the active database and maps performer names to entities in the level, while DialogueSequencerComponent drives playback — walking the graph, evaluating conditions, executing effects, and emitting events that UI components consume.

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

Contents

• Dialogue Editor
• Database Model
• Node Types
• Conditions
• Effects
• Performances
• Runtime Playback
• Localization
• ScriptCanvas Usage
• Quick Reference
• Glossary
• See Also

Dialogue Editor

Dialogue is authored in the Dialogue Editor — a visual node graph tool opened from GS Tools > Dialogue Editor. Each .dialoguedatabase file is a container holding all actors and sequences for a dialogue database. Sequences are built as directed node graphs: connect Text, Selection, Random, Effects, and Performance nodes to define the conversation flow. The editor saves the entire container as one file — individual sequences are not separate assets.

Conditions, effects, and performance types from any gem are discovered automatically at startup and appear in the editor without modifying GS_Cinematics.

Database Model

A .dialoguedatabase file is a container managed entirely through the Dialogue Editor:

The editor saves and loads the entire container as one file. Individual sequences are not separate assets. Switch the active database at runtime via DialogueManagerRequestBus::ChangeDialogueDatabase.

Authoring a Sequence

1. Open GS Tools > Dialogue Editor
2. File > New → save as .dialoguedatabase
3. Define performers on the Performers page
4. On the Sequences page, click Add in the sidebar, name the sequence
5. Build the graph: drag nodes from the palette, connect FlowOut → FlowIn
6. Ctrl+S to save the database

Node Types

Each sequence is a directed graph of nodes connected by FlowOut → FlowIn slots.

Conditions

Conditions are polymorphic objects added to any node. The sequencer evaluates all conditions before entering a node — failed conditions cause the evaluator to skip it and try the next valid path.

Custom conditions from any gem are discovered automatically — subclass DialogueCondition, reflect it, and it appears in the inspector type picker.

Effects

Effects are polymorphic objects executed when the sequencer reaches an Effects node.

Custom effects follow the same discovery pattern as conditions.

Performances

Performances are polymorphic actions executed at Performance nodes. The sequencer can optionally wait for completion before advancing.

Custom performance types are discovered automatically.

Runtime Playback

GS_DialogueManagerComponent

The top-level manager for all dialogue. Holds the active database, maps performer names to level entities, and is the entry point for starting sequences.

DialogueSequencerComponent

Drives sequence playback. Walks the graph, evaluates conditions, executes effects, triggers performances, and emits notifications for the UI layer.

Localization

Text nodes store lines as LocalizedStringId references — a key plus default fallback text. At runtime Resolve() looks up the key in the active LocalizedStringTable and returns the localized string. If no table is loaded or the key is absent, the fallback text is used.

ScriptCanvas Usage

Starting a Dialogue Sequence

Performer Marker Setup

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

• Framework API: Dialogue System — Architecture, components, and C++ extension
• Framework API: Dialogue Editor — Full editor reference
• The Basics: Dialogue UI
• The Basics: Cinematics Manager

Get GS_Cinematics

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

3.4.2.1 - Dialogue UI

The Dialogue UI layer is the display side of the GS_Cinematics system. It receives events from DialogueSequencerComponent through DialogueUIBridgeComponent and routes them to the correct UI implementation — screen-space for HUD-style dialogue or world-space for speech bubbles above actors. Player choices are handled by selection components, and the TypewriterComponent reveals text character-by-character. BabbleComponent optionally plays per-character audio babble to give speakers a voice.

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

Contents

• Component Overview
• DialogueUIBridgeComponent
• Dialogue Display Components
• Selection Components
• TypewriterComponent
• BabbleComponent
• ScriptCanvas Usage
• Quick Reference
• Glossary
• See Also

Component Overview

DialogueUIBridgeComponent

The Bridge component is the central connector between the sequencer and the UI. Place it on the same entity as DialogueSequencerComponent. It listens for OnDialogueTextBegin and OnDialogueSequenceComplete from the sequencer and forwards those events to whatever UI components are registered with it. It also receives player selection events from the selection UI and forwards them back to the sequencer.

This design keeps the sequencer and the display fully decoupled — swapping in a new UI implementation only requires registering it with the Bridge.

Dialogue Display Components

Screen-Space Text

DialogueUIComponent handles HUD-style dialogue display. Add it to a UI canvas entity. It exposes the active TypewriterComponent so other systems can check typewriter state or force completion.

World-Space Speech Bubbles

WorldDialogueUIComponent extends DialogueUIComponent for world-space placement. It positions the dialogue panel above the speaking actor’s entity in 3D space. Use this for over-the-shoulder dialogue or conversations where the camera stays in the world rather than cutting to a UI overlay.

Selection Components

Screen-Space Choices

DialogueUISelectionComponent renders the player’s available choices as a list on the HUD. Each choice is backed by a DialogueSelectButtonComponent entity that is configured with option text and a selection index. When the player activates a button, it fires back through the Bridge to the sequencer.

World-Space Choices

WorldDialogueUISelectionComponent extends DialogueUISelectionComponent for world-space display. Choices appear positioned in 3D space rather than as a HUD overlay, useful for games with diegetic UI.

TypewriterComponent

The TypewriterComponent reveals a string one character at a time. It fires OnTypeFired for each character revealed and OnTypewriterComplete when the full string is displayed. Use ForceComplete to instantly reveal the remaining text — typically wired to a player skip input — and ClearTypewriter to reset the display to empty.

BabbleComponent

BabbleComponent pairs with TypewriterComponent to play short audio sounds for each character revealed, giving the impression of a speaker’s voice. Each actor has a SpeakerBabbleEvents record that maps them to a specific babble sound profile. The component returns the correct BabbleToneEvent for the current speaker via GetBabbleEvent, which is called by the typewriter on each OnTypeFired.

ScriptCanvas Usage

Forcing Typewriter Completion on Skip Input

Wire a player input action to ForceComplete so pressing a button instantly reveals the current line:

Reacting to Typewriter Events

Quick Reference

Glossary

For full definitions, see the Glossary.