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

Summary: First official base release. Audio manager, event playback, mixing buses, multi-layer score arrangement, and Klatt voice synthesis.

GS_Audio Logs

GS_Cinematics

Latest version: 0.5.0

Summary: First official base release. Full dialogue system with node graph sequencer, polymorphic conditions/effects/performances, world and screen-space UI, typewriter, babble, localization, and the in-engine dialogue editor.

GS_Cinematics Logs

GS_Core

Latest version: 0.5.0

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

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

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

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

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

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

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

Summary: First official base release. Mode-driven unit movement system with player/AI controllers, 3-stage input pipeline, multiple mover types, grounders, and movement influence fields.

GS_Unit Logs

Documentation

Latest version: 1.0.0

Summary: First official base release. Ready to be developed, updated, and refined over the continued development of GS_Play!

Docs Logs

2.1.1 - Audio Change Log

Logs

• 0.5.0

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

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

• 0.5.0

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

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

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.

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
• Dialogue Authoring - GS_Cinematics
• 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…

Dialogue Authoring - GS_Cinematics

Breakdown

A dialogue sequence is authored in the node editor, stored in a .dialoguedb asset, and driven at runtime by the Dialogue Manager and Sequencer:

Layer	What It Means
DialogueDatabase	Stores named actors and sequences. Loaded at runtime by the Dialogue Manager.
DialogueSequence	A directed node graph. The Sequencer walks from startNodeId through Text, Selection, Effects, and Performance nodes.
Conditions	Polymorphic evaluators on branches. Failed conditions skip that branch automatically.
Effects	Polymorphic actions at EffectsNodeData nodes — set records, toggle entities.
Performers	Named actor anchors in the level. Resolved from database actor names via DialoguePerformerMarkerComponent.

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

• The Basics: Dialogue System — Authoring sequences, node types, conditions, effects, and runtime playback.
• Framework API: Dialogue System — Manager and sequencer APIs, extensible types, 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. The unit fires UnitPossessed on UnitNotificationBus 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.
UnitPossessed event	Fires on UnitNotificationBus (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.

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. 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 event-based sound playback, 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.
3. Create Audio Event Library assets for your sound effects.
4. Place GS_AudioEventComponent on entities that need to play sounds.

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 Events

Audio Events are the primary way to play sounds. Each event defines a pool of audio clips with selection rules (random or sequential), 2D or 3D playback mode, concurrent instance limiting, and repeat-hold behavior. Events are grouped into Audio Event Library assets that the Audio Manager loads at startup.

Audio Events 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. 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
• Quick Reference
• Glossary
• See Also

What It Manages

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

Audio Events are the primary way to play sounds in GS_Play. Each event defines a pool of audio clips with selection rules, playback mode (2D or 3D), concurrent instance limiting, and repeat-hold behavior. Events are grouped into Audio Event Library assets that the Audio Manager loads at startup.

For asset structure and component properties, see the Framework API reference.

Contents

• How It Works
• Event Configuration
• GS_AudioEventComponent
• Quick Reference
• Glossary
• See Also

How It Works

1. Create an Audio Event Library asset in the O3DE Asset Editor.
2. Define audio events — each with a name, clip pool, and playback settings.
3. Load the library by assigning it to the Audio Manager.
4. Play events by name from ScriptCanvas or C++.

Event Configuration

GS_AudioEventComponent

Place a GS_AudioEventComponent on any entity that needs to play sounds. The component references events by name from loaded libraries and handles 3D positioning automatically based on the entity’s transform.

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
• The Basics: Mixing

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 .dialoguedb assets with the 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 content is stored in .dialoguedb assets containing actors, portraits, and sequences. Each sequence is a graph of polymorphic nodes — text, selection, random branch, effects, and performances. A visual node editor lets writers author graphs directly in the O3DE Editor. 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 content is stored in .dialoguedb assets (DialogueDatabase), which contain named actors and a collection of DialogueSequence records. Each sequence is a graph of polymorphic nodes. At runtime, GS_DialogueManagerComponent manages the database and maps performer names to entities in the level, while DialogueSequencerComponent drives playback — walking the graph, evaluating conditions on branches, executing effects, and emitting events that UI and other systems consume.

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

Contents

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

Dialogue Database

Breakdown

A dialogue sequence is authored in the node editor, stored in a .dialoguedb asset, and driven at runtime by the Dialogue Manager and Sequencer:

Layer	What It Means
DialogueDatabase	Stores named actors and sequences. Loaded at runtime by the Dialogue Manager.
DialogueSequence	A directed node graph. The Sequencer walks from startNodeId through Text, Selection, Effects, and Performance nodes.
Conditions	Polymorphic evaluators on branches. Failed conditions skip that branch automatically.
Effects	Polymorphic actions at EffectsNodeData nodes — set records, toggle entities.
Performers	Named actor anchors in the level. Resolved from database actor names via DialoguePerformerMarkerComponent.

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

E Indicates extensible classes and methods.

Patterns - Complete list of system patterns used in GS_Play.

DialogueDatabase Asset

The DialogueDatabase is a .dialoguedb asset authored in the O3DE node editor. It is the single source of truth for all dialogue content in a project section.

Load a database at runtime by calling ChangeDialogueDatabase on DialogueManagerRequestBus. The manager resolves performer names from the database against DialoguePerformerMarkerComponent entities placed in the current level.

Node Types

Each sequence is a directed graph of DialogueNodeData nodes. The sequencer walks the graph starting from startNodeId and advances through the nodes in order.

Conditions

Conditions are polymorphic objects attached to sequence branches. The sequencer evaluates all conditions on a branch before following it. Branches whose conditions fail are skipped.

Effects

Effects are polymorphic objects executed when the sequencer reaches an EffectsNodeData node. Effects can also be reversed.

Performances

Performances are polymorphic objects executed when the sequencer reaches a PerformanceNodeData node. A performance can be blocking — the sequencer pauses and waits for OnPerformanceComplete before advancing — or non-blocking, where dialogue continues immediately after the performance fires.

Like conditions and effects, performance types are discovered automatically at startup via the type registry. Custom performance types from any gem appear in the editor without modifying GS_Cinematics.

Runtime Playback

GS_DialogueManagerComponent

The Dialogue Manager is the top-level manager for all dialogue. It holds the active DialogueDatabase, maps performer names to level entities via DialoguePerformerMarkerComponent, and is the entry point for starting sequences by name.

DialogueSequencerComponent

The Dialogue Sequencer drives sequence playback. It walks the node graph, evaluates conditions, executes effects, triggers performances, and emits notifications when text lines begin and when the sequence completes. It is typically placed on a dedicated sequencer entity in the level alongside DialogueUIBridgeComponent.

Localization

Text nodes store speaker lines as LocalizedStringId references rather than raw strings. A LocalizedStringId holds a key and a default fallback text. At runtime, the sequencer calls Resolve() on each LocalizedStringId, which looks up the key in the active LocalizedStringTable and returns the localized string for the current locale. If no table is loaded or the key is not found, the default text is returned.

To use localization, load a LocalizedStringTable asset through your project’s initialization flow before any dialogue plays.

ScriptCanvas Usage

Starting a Dialogue Sequence

Reacting to Sequence States

Listen on DialogueSequencerNotificationBus to receive speaker and text data as each line begins:

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: Dialogue System

For related systems:

• The Basics: Cinematics Manager
• The Basics: Dialogue UI

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.

See Also

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

• Framework API: Dialogue UI

For related systems:

• The Basics: Dialogue
• 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.2 - Performances

Performances are polymorphic actions that move or reposition actors during dialogue sequences. The sequencer triggers a performance when it reaches a PerformanceNodeData node and waits for OnPerformanceComplete before advancing. This async model lets multi-step actor choreography complete fully before dialogue continues. Three built-in performance types cover direct movement, navmesh navigation, and instant teleportation. Custom types can be created by extending the base class.

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

Contents

• How Performances Work
• Built-in Performance Types
• MoveTo_DialoguePerformance
• PathTo_DialoguePerformance
• RepositionPerformer_DialoguePerformance
• Async Completion
• Extending with Custom Performances
• ScriptCanvas Usage
• Quick Reference
• Glossary
• See Also

How Performances Work

When the sequencer encounters a PerformanceNodeData node, it:

1. Resolves the named performer entity via DialogueManagerRequestBus → GetPerformer.
2. Instantiates the performance object specified on the node.
3. Calls DoPerformance() — the public entry point.
4. Waits. The sequencer does not advance until the performance broadcasts OnPerformanceComplete.
5. Resumes from the next node once completion is received.

The performance itself handles the movement logic, monitors completion, and signals back through its notification bus. This means a single PerformanceNodeData can represent any action that takes time — walking to a spot, running a path, playing an animation, triggering a VFX sequence — as long as it broadcasts completion when done.

Built-in Performance Types

All three extend DialoguePerformance, the abstract base class. The base class provides DoPerformance(), ExecutePerformance(), and FinishPerformance() hooks, plus TickBus integration for per-frame movement updates.

MoveTo_DialoguePerformance

MoveTo_DialoguePerformance translates an actor toward one or more named stage markers using direct movement — no obstacle avoidance, no navmesh. It broadcasts movement requests over MoveTo_PerformanceNotificationBus. Listening systems (typically the performer’s movement component) receive those requests and execute the actual translation. When the actor reaches the final marker, the performance calls FinishPerformance() and broadcasts completion.

Use this for stylized games where physical path correctness is less important than snappy, predictable actor placement, or for any case where the path between actor and marker is guaranteed to be clear.

PathTo_DialoguePerformance

PathTo_DialoguePerformance navigates an actor to one or more named stage markers using the RecastNavigation navmesh. It requests a path from the navmesh, walks the actor along that path, and completes when the actor arrives at the final marker. Use this in games with detailed geometry where actors must walk around walls, furniture, and obstacles rather than moving in a straight line.

RecastNavigation must be enabled in the project and a navmesh must be baked in any level where PathTo performances are used.

RepositionPerformer_DialoguePerformance

RepositionPerformer_DialoguePerformance teleports an actor instantly to a named stage marker. It does not animate, translate, or navigate — it sets position directly. Useful for placing actors at the start of a new scene, recovering from a previous sequence that ended far from the required starting point, or repositioning actors that are off-camera and do not need visible movement.

Async Completion

All performances signal completion asynchronously. The sequencer does not poll or time out — it simply waits for the performance to call FinishPerformance(), which broadcasts OnPerformanceComplete over the appropriate notification bus. This means:

• A performance can take any amount of time.
• A performance can be driven by external events — animation callbacks, physics arrival, etc.
• Multiple performances can run in parallel if the node graph is structured to fork, because each notifies independently.

When writing custom performance types, always call FinishPerformance() when the action is done. Forgetting to do so will stall the sequencer indefinitely.

Extending with Custom Performances

Custom performance types are discovered automatically through O3DE serialization at startup. Extend DialoguePerformance, reflect it, and your custom type appears in the node editor’s performance picker and can be placed on any PerformanceNodeData node.

See the Framework API reference for the full base class interface and extension guide.

ScriptCanvas Usage

Performances are authored in the dialogue node graph and executed automatically by the sequencer. Most projects do not need to drive performances from ScriptCanvas directly. The common scripting patterns involve the movement side — receiving move or path requests from a performance and executing them on the performer entity.

Receiving a MoveTo Request

[MoveTo_PerformanceNotificationBus → StartMoveToMarker(markerEntity)]
    └─► [Move performer toward markerEntity position]
    └─► [When arrived → MoveTo_PerformanceRequestBus → ReportArrival]

Receiving a Reposition Request

[RepositionPerformer_PerformanceNotificationBus → RepositionToMarker(markerEntity)]
    └─► [Set performer transform to markerEntity transform]

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: Dialogue System

For related systems:

• The Basics: Dialogue
• The Basics: Cinematics Manager
• The Basics: Dialogue UI

Get GS_Cinematics

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

3.5 - GS_Environment

GS_Environment manages the living world — the passage of time, the shift between day and night, and the visual appearance of the sky. It provides a singleton time authority that other systems subscribe to for world tick events and phase-change notifications, decoupling every time-dependent system from managing its own clock. Sky presentation is data-driven through configuration assets.

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

Quick Navigation

Installation

GS_Environment requires GS_Core and the Atom renderer. Add both to your project.

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

Quick Installation Summary

1. Enable the GS_Environment gem in your project configuration.
2. Create a Time Manager prefab and add it to the Game Manager’s Managers list.
3. Create SkyColourConfiguration assets for your sky appearance.

Time Manager

The Time Manager is the singleton authority for world time. It advances time each tick according to a configurable speed, exposes query and control methods, and broadcasts WorldTick and DayNightChanged events so any system can react to time progression without polling.

Time Manager API

Sky Configuration

The Sky Configuration system defines how the sky looks at different times of day through data assets. SkyColourConfiguration assets hold colour values for dawn, midday, dusk, and night — swappable per-region, per-weather, or per-level without modifying entity hierarchies.

Sky Configuration API

See Also

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

• Framework API: GS_Environment

For step-by-step project setup:

• Simple Project Setup

Get GS_Environment

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

3.5.1 - Time Manager

The Time Manager is the singleton controller for world time in your project. It drives the time-of-day value, controls how fast time passes, determines day/night state, and broadcasts timing events that other systems (lighting, AI schedules, environmental effects) can react to.

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

Contents

• How It Works
• Controlling Time
• Responding to Time Events
• Entity Configuration
• Quick Reference
• Glossary
• See Also

How It Works

The Time Manager maintains a continuous time-of-day value. Each frame, it advances the time based on the configured passage speed and broadcasts a WorldTick event. When the time crosses the day/night threshold, it broadcasts DayNightChanged.

You set the main camera reference so the Time Manager can position sky effects relative to the player’s view.

Controlling Time

ScriptCanvas

Responding to Time Events

Time Manager Entity Configuration

In order to drive many of the environment effects and weather systems, the Time Manager needs many entities and components available to it.

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: GS_Environment

For related systems:

• The Basics: Sky Configuration
• The Basics: GS_Managers

Get GS_Environment

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

3.5.2 - Sky Configuration

Sky Colour Configuration assets define the visual appearance of the sky at different times of day. These are data assets created in the O3DE Asset Editor that the Time Manager references to drive sky color transitions as time progresses.

For asset structure and property details, see the Framework API reference.

Contents

• How It Works
• Glossary
• See Also

How It Works

A Sky Colour Configuration asset defines color values for key times of day (dawn, midday, dusk, night). The Time Manager samples the configuration based on the current time of day and interpolates between the defined colors to produce smooth transitions.

Different environments (desert, forest, underwater) can use different configuration assets. Swapping the active configuration changes the sky appearance without modifying entity hierarchies.

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: GS_Environment

For related systems:

• The Basics: Time Manager
• Utilities: Colour Gradient

Get GS_Environment

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

3.6 - GS_Interaction

GS_Interaction provides three independent but composable systems for making the world respond to entities. Pulsors broadcast typed events via physics volumes, the Targeting system finds and locks onto the best interactable in proximity with a cursor overlay, and World Triggers fire configurable responses from zones and conditions without requiring script code.

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

Quick Navigation