The Basics

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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

Quick Navigation

Installation

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

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

Quick Installation Summary

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

Audio Manager

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

Audio Manager API

Audio Event Graph

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

Audio Event Graph API

Mixing & Effects

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

Mixing & Effects API

Score Arrangement

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

Score Arrangement API

Klatt Voice Synthesis

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

Klatt Voice API

See Also

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

• Framework API: GS_Audio

For step-by-step project setup:

• The Basics: GS_Managers

Get GS_Audio

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

3.1 - Audio Manager

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

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

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

Contents

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

What It Manages

Audio Event Graph Instances

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

Fire-and-Forget

The simplest pattern — the Manager handles everything automatically:

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

Manual Instance Control

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

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

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

Quick Reference

Audio Event Graph

Mixing & Score

Glossary

For full definitions, see the Glossary.

See Also

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

Get GS_Audio

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

3.2 - Audio Event Graph

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

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

Contents

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

How It Works

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

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

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

Phase Lifecycle

Every Audio Event Graph supports up to three phases:

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

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

Nodes

Source Nodes

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

Filter Nodes

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

Effect Nodes

Routing Nodes

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

Output Node

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

Using Variables

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

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

Common patterns:

Variables are set from gameplay code via the Audio Manager:

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

Playing at Runtime

All Audio Event Graph playback goes through the Audio Manager.

Fire-and-Forget

For one-shot sounds with no runtime modification needed:

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

Manual Control

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

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

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

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

Get GS_Audio

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

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

4 - GS_Cinematics

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

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

Quick Navigation

Installation

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

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

Quick Installation Summary

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

Cinematics Manager

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

Cinematics Manager API

Dialogue System

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

Dialogue System API

Dialogue UI

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

Dialogue UI API

Performances

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

Performances API

See Also

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

• Framework API: GS_Cinematics

For step-by-step project setup:

• Simple Project Setup

Get GS_Cinematics

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

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.

4.2 - Dialogue System

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

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

Contents

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

Dialogue Editor

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

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

Database Model

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

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

Authoring a Sequence

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

Node Types

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

Conditions

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

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

Effects

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

Custom effects follow the same discovery pattern as conditions.

Performances

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

Custom performance types are discovered automatically.

Runtime Playback

GS_DialogueManagerComponent

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

DialogueSequencerComponent

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

Localization

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

ScriptCanvas Usage

Starting a Dialogue Sequence

Performer Marker Setup

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

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

Get GS_Cinematics

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

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.

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.

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.

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.

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.

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

Installation

GS_Interaction requires GS_Core, LmbrCentral, LyShine, and CommonFeaturesAtom. Add all required gems to your project before placing Interaction components in a level.

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

Quick Installation Summary

1. Enable the GS_Interaction gem in your project configuration.
2. Configure physics collision layers for trigger volumes.
3. Place Pulsor, Targeting, or World Trigger components on entities as needed.

Pulsors

The Pulsor system is a physics-driven event broadcast layer. A PulsorComponent on any entity with a trigger collider emits a typed pulse event when another entity enters or exits that volume. PulseReactorComponents on the receiving entity listen for those events and respond. Pulse types are polymorphic and registered at runtime, so project-specific types can be added without modifying GS_Interaction.

Pulsors API

Targeting

The Targeting system handles “which interactable entity is the player looking at or closest to right now?” A TargetingHandler on the player maintains a live registry of nearby targets, evaluates candidates on demand, and exposes the current target via bus events. Cursor components render a tracking reticle on screen that updates based on the selected target’s properties.

Targeting API

World Triggers

World Triggers are a data-driven system for firing game responses when conditions are met, with no script boilerplate required. TriggerSensor components define the condition side (interact, collider overlap, record check), and WorldTrigger components define the response (set record, toggle entity, change stage, print log). The combination lets most interactive world objects be authored entirely in the editor.

World Triggers API

See Also

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

• Framework API: GS_Interaction

For step-by-step project setup:

• Simple Project Setup

Get GS_Interaction

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

6.1 - Pulsors

The Pulsor system is a physics-driven event broadcast layer. A PulsorComponent lives on any entity with a trigger collider and emits a typed pulse event when another entity enters or exits that volume. PulseReactorComponent instances on the receiving entity listen for those events and respond. Because pulse types are polymorphic and registered at runtime, you can define project-specific pulse types without modifying the Pulsor or Reactor components themselves.

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

Contents

• How Pulses Work
• Pulse Types
• Reactor Types
• Extending with Custom Pulse Types
• Components
• ScriptCanvas Usage
• Quick Reference
• Glossary
• See Also

How Pulses Work

Breakdown

When a physics trigger fires, the PulsorComponent iterates all PulseReactorComponent instances on the entering entity and calls ReceivePulses() on each one that returns true from IsReactor() for the emitted pulse type. Each reactor independently decides whether it handles a given pulse, so multiple reactors on one entity can each respond to a different subset of pulse types without interfering with each other.

Step	What Happens
1 — Collider overlap	Physics system detects 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 called with IsReactor() for that type.
4 — Reaction	Reactors that return true have ReceivePulses() called and execute their response.

E Indicates extensible classes and methods.

Patterns - Complete list of system patterns used in GS_Play.

Pulse Types

A pulse type is a class derived from the abstract PulseType base. It carries no payload — the type itself is the signal. Reactors match on type identity, so adding a new type automatically makes it distinct from all existing ones.

Built-In Pulse Types

Reactor Types

A reactor type is a class derived from the abstract ReactorType base. It defines what the receiving entity does when a matching pulse arrives. One entity can carry multiple reactors — one for each pulse type it needs to handle.

Built-In Reactor Types

Extending with Custom Pulse Types

Custom pulse and reactor types are discovered automatically through O3DE serialization at startup. Any team or plugin can add new interaction semantics — damage types, pickup types, status effects — by extending the base class and reflecting it, without modifying GS_Interaction itself. Custom types appear automatically as options in the editor’s component property dropdowns and are available to all Pulsors and Reactors in the project.

For the full extension guide and C++ interface, see Framework API: Pulsors and Framework API: Pulses.

Components

ScriptCanvas Usage

The GS_Core PulseReactorEmissionBus exposes the reactor’s state for script-driven queries (the ScriptCanvas node name is preserved from the pre-interfaces bus). A common pattern is to wait for a Reactor to receive a pulse via OnPulseReceived, then process its incoming data for your own pulse processing.

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: Pulsors
• Framework API: Pulses
• Framework API: Reactors
• Framework API: Third-Party Implementation

For related systems:

• GS_Interaction

Get GS_Interaction

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

6.2 - Targeting

The Targeting system answers the question “which interactable entity should the player act on right now?” A GS_TargetingHandlerComponent on the player maintains a live registry of nearby targets. Proximity detection volumes populate that registry automatically as the player moves. When the handler evaluates candidates, it selects the best target and broadcasts the result so the cursor layer and any downstream logic stay in sync.

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

Contents

• How Targeting Works
• Target Components
• Targeting Handler
• Interaction Fields
• Cursor System
• Interaction Input
• Quick Reference
• Glossary
• See Also

How Targeting Works

The targeting pipeline runs across four layers — proximity detection, target registration, target selection, and cursor display. Each layer is a separate component so they can be mixed and matched for different entity configurations.

Target Components

GS_TargetComponent is the base marker that makes an entity targetable. It carries four properties the cursor layer reads to display correctly:

GS_InteractTargetComponent extends GS_TargetComponent with specialised interaction semantics. Use it for any entity that can be interacted with via the InteractInputReaderComponent.

Targeting Handler

The GS_TargetingHandlerComponent is the central coordinator. It tracks all currently-registered candidates and determines which one is the best target at any given moment.

Notifications

Subscribe to GS_TargetingHandlerNotificationBus to react to targeting state changes:

ScriptCanvas — Listening for Target Changes

ScriptCanvas — Querying the Current Target

Interaction Fields

GS_TargetingInteractionFieldComponent is a physics trigger volume placed on targetable entities. When the player’s collider overlaps the field, it calls RegisterTarget on the handler. When the player leaves, it calls UnregisterTarget. The handler never has to poll — the field layer pushes updates automatically.

The field’s volume shape (sphere, box, capsule) determines the interaction range independently of the entity’s visual or physics collision bounds, so you can have a large detection range with a small visible object.

Cursor System

The cursor layer visualizes the current target selection on screen. It is composed of two components that work together:

ScriptCanvas — Cursor Control

[GS_CursorRequestBus → SetCursorVisuals]
    └─► Updates the sprite and colour from the selected target's properties.

[GS_CursorRequestBus → SetCursorPosition]
    └─► Moves the cursor to track the target's world position.

[GS_CursorRequestBus → HideCursor]
    └─► Hides the cursor when no target is selected or targeting is suspended.

UI Cursor Canvas

A LyShine ui canvas that pairs with the in-world CursorComponent.

The cursor canvas applies visuals to the UI image in behalf of the targeting system.

Interaction Input

InteractInputReaderComponent extends GS_Core::GS_InputReaderComponent to map raw button input to interaction events.

Place it on the same entity as the GS_TargetingHandlerComponent. When the player presses the configured interact button, the reader fires an event the handler can act on to confirm the current selection or trigger the target’s interact action.

This keeps input handling decoupled from targeting logic — you can swap input mappings or replace the reader component without touching the handler.

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: Targeting
• Framework API: Targeting Handler
• Framework API: Targets
• Framework API: Interaction Fields
• Framework API: Interaction Input

For related systems:

• GS_Interaction

Get GS_Interaction

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

6.3 - World Triggers

World Triggers are a data-driven system for firing game responses when conditions are met. A TriggerSensorComponent defines the condition side — physics overlap, player interact, record check. A WorldTriggerComponent defines the response side — changing stage, toggling an entity, writing a record, logging a message. Each component holds an array of polymorphic type objects, so any combination of conditions and responses can be composed on a single entity without scripting.

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

Contents

• How World Triggers Work
• Sensor Types
• Trigger Types
• Reset and Re-Arming
• ScriptCanvas Usage
• Editor Setup Pattern
• Quick Reference
• Glossary
• See Also

How World Triggers Work

Breakdown

Each trigger is split into two container components. Logic lives in type objects held by each component:

Part	Role
TriggerSensorComponent	Holds andConditions and orConditions arrays of TriggerSensorType objects. When conditions pass, fires WorldTriggerRequestBus::Trigger on the same entity.
WorldTriggerComponent	Holds a triggerTypes array of WorldTriggerType objects. On Trigger(), calls Execute() on every type. On Reset(), calls OnReset().

You can add any mix of sensor types and trigger types — for example, a door that requires both a physics overlap AND a record flag (andConditions) before it opens (TriggerType_ToggleEntities), then sets a quest record (TriggerType_SetRecord).

E Indicates extensible classes and methods.

Patterns - Complete list of system patterns used in GS_Play.

Sensor Types

Add sensor types to the andConditions or orConditions arrays on a TriggerSensorComponent. The four built-in types cover the most common condition patterns:

Trigger Types

Add trigger types to the triggerTypes array on a WorldTriggerComponent. The four built-in types handle the most common response patterns:

Reset and Re-Arming

Calling Reset() on WorldTriggerRequestBus calls OnReset() on every trigger type in the component. Each type can reverse its effect or prepare for re-activation:

• TriggerType_ToggleEntities inverts entity states on both Execute and OnReset, enabling toggle behavior.
• Switches that cycle on repeat interaction.
• Area triggers that fire each time a player re-enters.
• Multi-step sequences where earlier steps re-arm later ones.

ScriptCanvas Usage

WorldTriggerRequestBus exposes both core methods directly to scripts:

A common script pattern is to use a SensorType_Record condition to gate a sequence, then script the reset from a separate event so the trigger only re-arms after additional conditions are met:

You can also bypass the sensor component entirely and call Trigger() directly from any script when you need to fire a world trigger response programmatically — for example, from a dialogue completion callback or an animation event.

Editor Setup Pattern

Most interactive world objects follow this assembly in the editor:

1. Create an entity for the interactive object (door, switch, collectible, zone border).
2. Add a TriggerSensorComponent to the entity.
3. Add the appropriate sensor type(s) to andConditions or orConditions (e.g. SensorType_PlayerInteract for interact, SensorType_Collider for proximity).
4. Add a WorldTriggerComponent to the same entity.
5. Add the appropriate trigger type(s) to triggerTypes (e.g. TriggerType_ToggleEntities to open a door, TriggerType_SetRecord to record the event).
6. Configure each type’s properties in the editor — no scripting needed for these patterns.

For interact-based sensors, also add GS_TargetComponent or GS_InteractTargetComponent so the Targeting system can select this entity.

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: World Triggers
• Framework API: Trigger Sensors
• Framework API: World Trigger Types
• Framework API: Record Sensor Type

For related systems:

• GS_Interaction

Get GS_Interaction

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

7 - GS_Juice

GS_Juice is the game feel and feedback system. It provides motion-based visual feedback effects — screen shake, bounce, flash, pulse, material glow — authored as data assets and played on entities at runtime. GS_Juice extends the GS_Motion animation system with feedback-specific track types, so all timing, easing, and proxy targeting features are available for feedback effects.

For architecture details, track types, and the domain extension pattern, see the GS_Juice API.

Quick Navigation

Installation

GS_Juice requires GS_Core. Add both gems to your project.

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

Quick Installation Summary

1. Enable the GS_Juice gem in your project configuration.
2. Create .feedbackmotion assets in the O3DE Asset Editor.
3. Place FeedbackEmitter components on entities that need to play effects.

Feedback System

The feedback system is the core of GS_Juice. Feedback Motion assets (.feedbackmotion) define one or more animation tracks that play together as a feedback effect. The Feedback Emitter component plays a feedback motion on itself or on a target entity. Effects are additive — they modify properties relative to the entity’s current state, so multiple effects stack without conflict.

Two track types are included:

• Transform Track — Animates position offset, scale, and rotation using gradients. Ideal for screen shake, bounce, squash-and-stretch, and recoil.
• Material Track — Animates material properties (opacity, emissive intensity, color tint) using gradients. Ideal for hit flash, damage glow, and fade effects.

Feedback System API

See Also

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

• Framework API: GS_Juice

For related systems:

• The Basics: GS_Motion
• The Basics: Utilities — Gradients

Get GS_Juice

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

7.1 - Feedback System

The Feedback System is the core of GS_Juice. Feedback Motion assets define animation tracks that play together as a visual effect — screen shake, bounce, hit flash, glow pulse. The Feedback Emitter component plays these effects on entities, with support for proxy targeting and stacking.

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

Contents

• Track Types
• Feedback Emitter
• Authoring Feedback Motions
• Stacking Effects
• Proxy Targeting
• Glossary
• See Also

Track Types

Both track types use Gradients from GS_Core, giving you full control over the animation shape at every point in the effect’s duration.

Feedback Emitter

The FeedbackEmitter component lives on any entity and plays a Feedback Motion.

Authoring Feedback Motions

1. Create a .feedbackmotion asset in the O3DE Asset Editor.
2. Add transform and/or material tracks.
3. Configure each track’s gradients — these define the animation curve shape.
4. Set timing (start time, duration) and easing for each track.
5. Optionally set track identifiers for proxy targeting.
6. Assign the asset to a FeedbackEmitter component.

Stacking Effects

Feedback effects are additive — each track applies its property change relative to the entity’s current state. Multiple effects on the same entity stack naturally without conflict. A bounce effect and a flash effect can run simultaneously on the same entity.

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.

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: GS_Juice

For related systems:

• The Basics: GS_Motion
• The Basics: Utilities — Gradients

Get GS_Juice

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

8 - GS_Item

GS_Item provides the foundational inventory and equipment infrastructure for GS_Play games. It handles how items are stored, organized, and associated with characters — from simple containers that hold collectables to slot-based equipment systems that drive visual changes through GS_Performer.

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

Quick Navigation

Installation

GS_Item requires GS_Core. GS_Performer is an optional dependency for visual equipment integration.

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

Quick Installation Summary

1. Enable the GS_Item gem in your project configuration.
2. Define item data assets for your game’s items.
3. Place Inventory components on entities that need to store items.
4. Place Equipment components on characters that need to equip items.

Inventory

The Inventory system is a container-based model for item storage. Each inventory is a collection of item slots where each slot holds an item reference and a stack count. The system handles adding, removing, querying, and capacity management. Any entity can host an inventory — a player backpack, a chest, a vendor, or a loot bag.

Inventory API

Equipment

The Equipment system is the slot-based layer that governs which items a character has equipped. Each slot has a defined type and enforces compatibility rules. Equipment integrates with GS_Performer’s Skin Slot system — equipping an item automatically updates the matching visual asset, connecting inventory state to character presentation.

Equipment API

See Also

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

• Framework API: GS_Item

For related systems:

• The Basics: Skin Slots

Get GS_Item

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

8.1 - Inventory

The Inventory system provides container-based item storage for entities. Inventory components define slot-based containers that hold item data, support stacking, and enable item transfer between entities (player to chest, vendor to player).

For component properties and the inventory data model, see the Framework API reference.

Contents

• How Inventory Works
• Glossary
• See Also

How Inventory Works

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: Inventory

For related systems:

• The Basics: Equipment

Get GS_Item

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

8.2 - Equipment

The Equipment system provides typed equipment slots for characters. Equipment slots enforce type constraints (helmet slot accepts helmets, weapon slot accepts weapons) and integrate directly with the Skin Slot system in GS_Performer to update visual appearance when items are equipped or unequipped.

For component properties and the equipment data model, see the Framework API reference.

Contents

• How Equipment Works
• Integration with Skin Slots
• Glossary
• See Also

How Equipment Works

Integration with Skin Slots

Equipment slots can be linked to Performer Skin Slots. When an item is equipped, the corresponding skin slot’s actor mesh and materials are automatically swapped to match the item. No manual wiring is required — the connection is data-driven through slot name matching.

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: Equipment

For related systems:

• The Basics: Inventory
• The Basics: Skin Slots

Get GS_Item

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

9 - GS_Performer

GS_Performer is the character presentation layer for GS_Play. It handles the visual side of any entity that needs to look like a character — whether that is a fully-rigged 3D mesh swapping equipment, a sprite-based billboard character, or an animated unit whose blend parameters track real movement velocity. GS_Performer sits above GS_Unit and GS_Core, consuming movement and game state events to keep visual output in sync with gameplay.

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

Quick Navigation

Installation

GS_Performer requires GS_Core. EMotionFX and GS_Unit are optional dependencies for animation and velocity-driven locomotion.

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

Quick Installation Summary

1. Enable the GS_Performer gem in your project configuration.
2. Create a Performer Manager prefab and add it to the Game Manager’s Managers list.
3. Place PerformerSkinSlotComponent and SkinSlotHandlerComponent on character entities.
4. For 2.5D characters, add a PaperFacingHandlerComponent.

Performer Manager

The Performer Manager is the singleton coordinator for all registered performers in the active scene. It follows the GS_Core manager pattern — spawned by the Game Manager, participates in standby, and is accessible globally via its request bus. Systems that need to enumerate or query active performers route through this component.

Performer Manager API

Skin Slots

The Skin Slot system is the modular equipment and appearance layer for characters. Each PerformerSkinSlotComponent represents an equipment slot holding an actor asset and material overrides. The SkinSlotHandlerComponent manages the full collection for one character, providing batch operations and appearance-changed notifications. This makes character visual configuration composable rather than monolithic.

Skin Slots API

Paper Performer

The Paper Performer system provides billboard-style 2.5D character rendering. The PaperFacingHandlerComponent rotates the entity’s mesh to face the active camera each frame, accounting for movement direction to prevent visual artifacts from naive always-face-camera implementations. Custom facing logic can be substituted without modifying the core component.

Paper Performer API

Locomotion

The Locomotion feature set connects an entity’s physical movement to its animation layer. The VelocityLocomotionHookComponent reads velocity from the physics system each tick and drives animation blend parameters — speed and direction — that EMotionFX or Simple Motion components consume. Animations stay tightly synchronized with gameplay movement without manual state machine scripts.

Locomotion API

See Also

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

• Framework API: GS_Performer

For step-by-step project setup:

• Simple Project Setup

Get GS_Performer

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

9.1 - Performer Manager

The Performer Manager is the singleton controller for the performer system. It tracks all active performers in the scene, handles registration and lookup, and responds to the Game Manager’s lifecycle events automatically.

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

Contents

• How It Works
• Quick Reference
• Glossary
• See Also

How It Works

Performers register with the Performer Manager when they activate. The manager provides lookup by name so that other systems — dialogue, cinematics, AI — can find performers without maintaining their own references.

The Performer Manager responds to standby and shutdown broadcasts from the Game Manager, coordinating performer state across level transitions.

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: GS_Performer

For related systems:

• The Basics: GS_Managers

Get GS_Performer

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

9.2 - Performers

Performers are the character entity types in GS_Performer. Each type defines how a character’s visual layer is structured and rendered — whether a flat sprite quad that rotates to face the camera, or a fully-rigged 3D mesh driven by EMotionFX. Choose the performer type that fits your character pipeline, then add Performer Features to layer in additional capabilities.

For component details and C++ extension, see the Framework API: Performers.

Paper Performer

The Paper Performer is a billboard-based character type for 2.5D and top-down games. The PaperFacingHandlerComponent orients the entity’s sprite quad toward the active camera each frame, accounting for movement direction to prevent visual artifacts. It is the simplest performer type — lightweight, with no animation graph required.

Paper Performer API

Avatar Performer

The Avatar Performer is the full 3D character pipeline. It drives a rigged EMotionFX actor and integrates with Skin Slots and the Velocity Locomotion Hook for a complete character presentation layer. Use this for characters with full 3D rigs, animation blend trees, and runtime equipment swapping.

Avatar Performer API

See Also

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

• Framework API: Performers

For related systems:

• Performer Features
• Performer Manager

Get GS_Performer

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

9.2.1 - Avatar Performer

Get GS_Performer

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

9.2.2 - Paper Performer

The Paper Performer system provides billboard-style character rendering for 2.5D games. The Paper Facing Handler rotates sprite-based characters to always face the active camera while maintaining proper orientation relative to movement direction. This prevents the visual artifacts that occur when a flat sprite is viewed from the side.

For component properties and the facing algorithm, see the Framework API reference.

Contents

• How It Works
• Camera-Aware Variant
• Entity Configuration
• Glossary
• See Also

How It Works

The PaperFacingHandlerComponent is placed on any entity that uses sprite-based or flat-mesh character rendering. Each frame, it calculates the optimal facing direction based on:

1. The active camera’s position (via CamCore notifications).
2. The entity’s movement direction.
3. Configurable facing rules.

The result is a character that always presents its front face to the camera without snapping or popping during movement direction changes.

Camera-Aware Variant

The CamCorePaperFacingHandlerComponent (in GS_Performer) extends the base paper facing with direct camera core integration. It listens to the GS_Core CamCoreEmissionBus for camera position updates, ensuring the facing calculation uses the exact camera state rather than a cached position.

Entity Configuration

Note this has been put inside a GS_Unit prefab.

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: Paper Performer

For related systems:

• The Basics: PhantomCam
• Utility: Angles Helper

Get GS_Performer

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

9.3 - Performer Features

Performer Features are components that layer onto any performer entity, regardless of type. They are not tied to how a character is rendered — they extend what any performer can do. Skin Slots give any character modular equipment slots. Locomotion connects physics movement to the animation graph automatically.

For component details and C++ extension, see the Framework API: Performer Features.

Skin Slots

The Skin Slot system provides modular equipment and appearance management. Each PerformerSkinSlotComponent represents one equipment position on the character — helm, chest, weapon — holding a swappable actor mesh and material set. The SkinSlotHandlerComponent coordinates all slots on a character and supports preset profiles for NPC archetypes or full equipment sets.

Skin Slots API

Locomotion

The Velocity Locomotion Hook connects entity movement to animation automatically. It reads the entity’s physics velocity each frame and writes blend parameters — speed and direction — directly into the EMotionFX animation graph, driving walk, run, idle, and fall transitions without manual state machine scripting.

Locomotion API

See Also

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

• Framework API: Performer Features

For related systems:

• Performers
• Performer Manager

Get GS_Performer

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

9.3.1 - Skin Slots

The Skin Slot system provides modular character appearance. Each slot represents an equipment position on a character (head, body, arms, weapon) and holds an actor mesh with its materials. The Skin Slot Handler manages the full collection of slots for a character, enabling runtime equipment swapping through data changes rather than entity restructuring.

For component properties and data structures, see the Framework API reference.

Contents

• How It Works
• Skin Slot Data
• Quick Reference
• Glossary
• See Also

How It Works

Each character entity has one SkinSlotHandlerComponent and multiple PerformerSkinSlotComponent children — one per equipment position.

When you equip a new item, you update the slot’s SkinSlotData — the system swaps the actor mesh and materials automatically.

Skin Slot Data

Skin Slot Configuration Profiles are preset assets that define complete character appearances — useful for NPC archetypes or equipment sets.

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: GS_Performer

For related systems:

• The Basics: Item — Equipment

Get GS_Performer

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

9.3.2 - Locomotion

The Velocity Locomotion Hook automatically drives animation blend parameters from an entity’s velocity. Instead of manually scripting animation state transitions, you attach this component and it reads the entity’s physics velocity each frame, writing the appropriate blend values to the animation system.

For component properties, see the Framework API reference.

Contents

• How It Works
• When to Use
• Glossary
• See Also

How It Works

The VelocityLocomotionHookComponent runs on the tick bus. Each frame it:

1. Reads the entity’s current velocity from the physics system.
2. Extracts speed, direction, and vertical velocity.
3. Writes these as blend parameters to the entity’s EMotionFX animation graph.

This creates a seamless connection between movement and animation — walk, run, idle, and fall transitions happen automatically based on physics state.

When to Use

The component is stateless and lightweight — it reads velocity and writes parameters each frame with no internal state machine.

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: GS_Performer

For related systems:

• The Basics: Unit — Movement

Get GS_Performer

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

10 - GS_PhantomCam

GS_PhantomCam is the camera management system for GS_Play. Instead of driving a single camera directly, you place lightweight virtual cameras — Phantom Cameras — in your level. Each Phantom Camera carries a priority value and runs a per-tick stage pipeline that produces its candidate pose. The Cam Core drives the real engine camera to match whichever Phantom Camera currently has the highest priority. Transitions between cameras are animated by Blend Profile assets, and Influence Fields let spatial zones or gameplay states adjust priority dynamically.

For multi-player and split-screen, GS_PhantomCam can also run in a channel-aware mode where each player gets its own arbitration slot — Tier 1 single-cam, Tier 2 single-player rig, Tier 3 multi-channel co-op — without changing the per-cam authoring surface.

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

Quick Navigation

Architecture

Breakdown

Each Phantom Camera publishes a candidate pose every tick by running its Body → Aim → Reposition → Noise pipeline. The Cam Manager arbitrates priority across all registered Phantom Cameras inside a channel (channel 0 covers all single-player projects). When the channel’s winner changes, the Cam Core looks up the best blend for the pair and animates the real camera from the outgoing pose to the new one — optionally inheriting pose state across the transition and applying mid-blend interrupt correction when a new winner appears before the current blend completes.

Scenario	Which Blend Is Used
Camera A becomes inactive, Camera B was waiting	The Cam Core queries the assigned Blend Profile for an A → B entry.
No entry matches the pair	The Cam Core falls back to its own default blend time, easing, and shape.
A new transition starts before the current one finishes	The Cam Core applies a mid-blend correction window so the cam does not snap.
Blend entry’s Inherit State is set	The outgoing cam’s body publishes a pose snapshot; the incoming cam’s body adopts it before the blend executes.

Because Blend Profiles are assets, the same profile can be shared across many Phantom Cameras. A single edit to the asset changes the feel of every camera that references it.

E Indicates extensible classes and methods.

Patterns - Complete list of system patterns used in GS_Play.

Installation

GS_PhantomCam requires GS_Core only. Add both gems to your project before placing PhantomCam components in a level.

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

Quick Installation Summary

1. Enable the GS_PhantomCam gem in your project configuration.
2. Create a Cam Manager prefab and add it to the Game Manager’s Managers list.
3. Choose your authoring tier:
   • Tier 1 / 2 (single-player) — Assign a rig prefab to the Cam Manager’s Primary Rig Prefab, or hand-place a Cam Core entity in the level.
   • Tier 3 (split-screen / co-op) — Toggle Enable Instanced Channels on the Cam Manager and populate the Channel Configs list. Detailed walkthrough ships with the Channels & Instancing docs.
4. Place Phantom Camera entities with desired Body, Aim, and Additive stages.
5. Create Blend Profile assets for camera transitions.

Cam Manager

The Cam Manager is the singleton camera-system controller, integrated with GS_Core’s manager lifecycle. It handles startup and shutdown, owns per-channel registries (cameras, targets, influences, group targets), runs priority arbitration, dispatches cross-channel cinematic overrides, and orchestrates the engine’s active main view. In multi-channel projects, the Cam Manager also spawns rig prefabs at startup and re-spawns them on stage transitions.

Cam Manager API

Phantom Cameras

A Phantom Camera is a single entity component — GS_PhantomCameraComponent — that carries priority, lens, target routing, snap / focus / blendingOut state, and the stage pipeline slot that gives the cam its behavior. Where previous versions of GS_PhantomCam shipped separate components for each behavior (clamped-look, static-orbit, spline track), all those behaviors are now stage variants on the single base component.

Phantom Cameras API

Stage Pipeline

Every Phantom Camera runs the same per-tick pipeline:

Body → Aim → Reposition additives → Noise additives → Finalize

Authors compose a cam by picking a Body stage (follow, orbit, dynamic orbit, leading-follow, track), an Aim stage (default look, clamped look), and zero-or-more Additive stages (collision, tug listeners, Perlin noise, impulse). The same component becomes a follow cam, an orbital cam, a tracking dolly, or a third-person shoulder cam depending on what is slotted.

For step-by-step composition recipes — third-person shoulder cam, orbital boss cam, tracking dolly — see the recipes page.

Stage Composition Recipes API

Cam Core

Cam Core is the runtime bridge between the Phantom Camera system and the actual O3DE camera entity. It receives the channel’s arbitrated winner from the Cam Manager, looks up the matching Blend Profile entry, optionally runs a state-inheritance handoff between the outgoing and incoming cams, and animates the real camera over the blend duration. When a new transition starts before the current one completes, Cam Core applies a mid-blend correction window so the cam does not snap.

Cam Core API

Blend Profiles

Blend Profiles are .camblendprofile data assets that define how the Cam Core transitions between Phantom Cameras. Each entry specifies a From / To pair, a duration, an easing curve, a blend shape (Linear / Cylindrical / Spherical around a pivot), an inherit-state flag, and a pivot source. Authors share one profile across many cameras for visual consistency, then add per-pair overrides where the feel needs to differ.

Blend Profiles API

Influence Fields

Influence Fields are spatial or global modifiers that dynamically shift camera priority. GlobalCameraInfluence applies a constant priority modifier for its entire active lifetime (typically scoped to a level via the StageData entity); CameraInfluenceField applies a priority modifier when an entity enters a PhysX trigger volume. In multi-channel projects, influences are routed to the channel that owns the entity that triggered them — clean isolation between players in co-op.

Influence Fields API

See Also

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

• Framework API: GS_PhantomCam

For step-by-step project setup:

• Simple Project Setup

Get GS_PhantomCam

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

10.1 - Cam Manager

The Cam Manager is the camera system’s singleton manager. It integrates with GS_Core’s standard manager lifecycle, handles the camera system’s startup and shutdown through the two-stage initialization sequence, and maintains awareness of which Phantom Camera is currently dominant. Any time the active camera changes, the Cam Manager broadcasts a notification so dependent systems can react without polling.

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

Contents

• Manager Lifecycle
• Enabling and Disabling the Camera System
• Tracking the Active Camera
• Suspending the Camera System
• Changing the Camera Target
• Three Authoring Tiers
• Entity Configuration
• Quick Reference
• Glossary
• See Also

Manager Lifecycle

The Cam Manager is a GS_ManagerComponent and participates in the standard GS_Core startup sequence. It activates alongside all other managers during the two-stage initialization, making it safe to call camera system methods any time after OnStartupComplete.

Enabling and Disabling the Camera System

The camera system can be suspended and resumed independently of other gameplay systems. This is used during UI-only states, loading screens, or when a cinematic takes direct control of the camera.

Both events are on CamManagerNotificationBus. Broadcast them to switch the camera system state from any script or component.

Tracking the Active Camera

The Cam Manager broadcasts SettingNewCam on CamManagerNotificationBus whenever a different Phantom Camera becomes dominant. This fires any time a camera with higher priority activates, a dominant camera deactivates, or a blend resolves to a new target.

Use this event in any system that needs to know which camera is currently active — aiming reticles, world-space UI elements, minimaps, or audio listener positioning.

ScriptCanvas

Suspending the Camera System

ScriptCanvas

Broadcast DisableCameraSystem to suspend camera updates, for example when a cutscene takes direct camera control:

Because DisableCameraSystem and EnableCameraSystem are notifications rather than requests, they are fire-and-forget. Any script can broadcast them.

Changing the Camera Target

ScriptCanvas

The follow target, designated by the CamManager, can be set with Get/Set Target:

Three Authoring Tiers

The Cam Manager exposes three top-level fields that control how the camera system is configured for your project. Most single-player projects use Tier 1; multi-player or split-screen projects use Tier 3.

For the full step-by-step walkthrough of each tier — including common Tier 3 patterns (shared cinematic cams, hero-perspective cams, cross-channel dispatch) and the lobby flow for variable player counts — see the dedicated Channels page:

Channels & Instancing API

Cam Manager Entity Configuration

In Tier 1, assign your rig prefab (containing a Cam Core and any cams that should persist with the manager) to the Cam Manager’s Primary Rig Prefab field. The Cam Manager spawns the rig at startup.

In Tier 2, hand-place the Cam Core entity as a child of the Cam Manager. Any phantom cameras that should persist between stage changes can sit alongside the Cam Core.

In Tier 3, populate m_channelConfigs with one entry per supported player slot — see Channels & Instancing.

Across all tiers, the PossessedUnit event on a player controller is a convenient way to push the camera target the moment the player unit spawns.

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: Cam Manager

For related systems:

• The Basics: Channels & Instancing
• The Basics: Phantom Cameras
• The Basics: Cam Core
• The Basics: GS_Managers
• The Basics: Unit Controllers

Get GS_PhantomCam

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

10.1.1 - Channels & Instancing

GS_PhantomCam can be configured at three different tiers depending on what your project needs. Most projects use Tier 1 (single-cam) or Tier 2 (single-player rig). Co-op, split-screen, and per-player-cinematic projects use Tier 3 (multi-channel). The per-cam authoring surface is identical across tiers — what changes is the Cam Manager configuration and how many rigs the system spawns.

This page is a concept primer. For step-by-step Tier 1 / Tier 2 / Tier 3 walkthroughs, common Tier 3 patterns, and the lobby-flow recipe for variable player counts, see the recipes collection.

Channel Tier Configurations (Recipes) API

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

Contents

• What Is a Channel?
• Choosing a Tier
• Pitfalls
• See Also

What Is a Channel?

A channel is one player viewpoint slot. Each channel owns:

• An instantiated rig subtree (one Cam Core + zero or more Phantom Cameras).
• Its own target binding (typically the player unit for that channel).
• Its own priority table — arbitration is independent per channel.
• Its own active influence-field records.

Channel 0 is the implicit default for all single-player flows. You only deal with non-zero channels in Tier 3.

Multi-view rendering is pending. Until the AttachmentImage work lands, the engine renders one channel’s view at a time even when multiple channels are arbitrating internally. The Cam Manager’s active main-view API selects which channel reaches the framebuffer. The arbitration / dispatch / target binding all work today — only the simultaneous-rendering piece is gated.

Choosing a Tier

You can build a project at Tier 1, then add Tier 3 later by toggling the master gate and authoring channel configs — the per-cam configuration and stage compositions you authored at Tier 1 still work.

The Tier 3 walkthrough recipe also covers common Tier 3 patterns (in-rig per-player cams, shared cinematic collapse cams, hero-perspective cams, cross-channel dispatch) and the lobby flow for variable player counts.

Pitfalls

Tug-field channels are not instancing channels

Tug-field m_channels are arbitrary string tags (“Cinematic”, “Combat”) that match tug volumes to listeners. They are unrelated to the integer ChannelIds on this page despite the shared word. See Tug Fields for the unrelated tagging system.

A cam outside any rig prefab in Tier 3

If you place a Local-scope Phantom Camera in the level (not inside a rig prefab) with multi-channel ON, the stamp-walk misses and the cam falls through to legacy channel 0. This may surprise you. To make a level-placed cam channel-aware in Tier 3, set its scope to TrueUnique with explicit binding.

AllChannels outside a rig prefab

AllChannels-scoped cams outside a rig prefab currently warn and fall back to channel 0. The “out-of-rig runtime cloning” path is deferred. For per-player broadcast cams, place the cam inside the rig prefab.

Cam Manager spawns BEFORE HandleStartup

The Cam Manager spawns configured rigs from OnStartupComplete and only then broadcasts HandleStartup. This means cams inside spawned rigs receive the startup wave alongside everything else — your gameplay code can rely on Cam Cores being registered by the time HandleStartup fires. Stage transitions follow the same pattern: respawn before re-broadcasting HandleStartup.

See Also

Recipes:

• Channel Tier Configurations — step-by-step Tier 1 / 2 / 3 walkthroughs, common Tier 3 patterns, lobby flow.

Framework API:

• Channels & Instancing — Framework API — full bus surface, internal state, spawn pipeline.
• Cam Manager — Framework API — owning component.

Related basics pages:

• The Basics: Cam Manager — manager lifecycle and notifications.
• The Basics: Phantom Cameras — Channel Scope authoring.

Get GS_PhantomCam

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

10.2 - Cam Core

Cam Core is the rendering bridge between the Phantom Camera system and the actual O3DE camera entity. GS_CamCoreComponent runs on tick, reads the dominant Phantom Camera’s configuration each frame, and writes position, rotation, and field of view directly to the camera entity that the renderer uses. Phantom Cameras define intent — Cam Core executes it.

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

Contents

• What Cam Core Does Each Frame
• Responding to Camera Position Updates
• Cam Core Setup
• Querying Cam Core State
• Quick Reference
• Glossary
• See Also

What Cam Core Does Each Frame

On every tick, Cam Core follows this sequence:

Because Cam Core owns the final write to the camera entity, it is also the correct insertion point for last-mile adjustments such as screen shake offsets, post-processing overrides, or recoil displacement — applied after blend resolution but before the frame renders.

Responding to Camera Position Updates

CamCoreNotificationBus broadcasts UpdateCameraPosition every frame with the resolved camera transform. Connect to this bus in any system that needs per-frame camera location data.

ScriptCanvas

Cam Core Setup

Cam Core requires exactly one GS_CamCoreComponent in the level, and a separate entity with an O3DE Camera component that Cam Core is configured to drive. The Camera entity is what the renderer uses — Cam Core holds a reference to it and writes to it each frame.

Assign the Camera entity reference in the Cam Core component’s properties in the editor. Both entities should be present in every level that uses the PhantomCam system.

Querying Cam Core State

Use CamCoreRequestBus to read the current camera state or set the camera entity reference at runtime:

ScriptCanvas

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: Cam Core

For related systems:

• The Basics: Phantom Cameras
• The Basics: Cam Manager
• The Basics: Blend Profiles

Get GS_PhantomCam

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

10.2.1 - State Inheritance

State inheritance is an opt-in checkbox on each entry in a Blend Profile asset. When the box is ticked, the outgoing camera publishes a snapshot of its pose at the moment of transition, and the incoming camera’s Body stage adopts the snapshot through its own kinematic model. The blend then reads as a smooth drift instead of a swing.

When the box is unticked (the default), the incoming camera starts from its authored ideal — useful for cinematic shots where you want the camera to land at a specific framing regardless of where the outgoing camera was.

For the protocol mechanics, per-stage Get / Adopt implementations, and the matching m_inheritState field, see the Framework API reference.

Contents

• When to Tick the Box
• What Each Body Does With It
• The Common Gotcha
• Author Steps
• See Also

When to Tick the Box

The default is off so cinematic shots land at their authored poses unless you opt in.

What Each Body Does With It

Inheritance is body-only. The destination’s Aim stage runs fresh on the inherited body pose.

The Common Gotcha

If the destination cam looks like it’s snapping to its initial-yaw seed instead of inheriting from the source, check the inherit flag on the matched blend entry. The symptom varies by body type:

All three indicate the same root cause: the blend entry exists in the asset, but InheritState is unticked on it. Fix it in the asset.

Author Steps

1. Open the relevant .camblendprofile asset in the Asset Editor.
2. Find or add the blend entry for the From / To pair.
3. Tick the Inherit State checkbox on that entry.
4. Save the asset.

That’s the entire author surface. Everything else — pose snapshotting, body-stage Get / Adopt selection, ANGULAR vs POSITION derivation, the path-rejection threshold — happens automatically per body type.

For per-pair authoring at scale, share one blend profile across cams that should behave the same way, and use multiple profiles for cams that need different inheritance defaults.

See Also

Framework API:

• State Inheritance — Framework API — CamPoseSnapshot trait, per-body Get / Adopt implementations.
• Body Stage Variants — per-variant detail on what each body does on inherit.
• Blend Profiles — Framework API — the field’s home in the asset.

Related basics pages:

• The Basics: Blend Profiles — the asset that hosts the toggle.
• The Basics: Cam Core — the system that runs the handoff.

Get GS_PhantomCam

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

10.2.2 - Blend Profiles

Blend Profiles are .camblendprofile data assets that define how the Cam Core transitions from one Phantom Camera to another. Without a Blend Profile, transitions are instantaneous. A well-authored Blend Profile is often the single largest contributor to a camera system feeling polished rather than mechanical.

Each entry in a profile defines a single transition rule — a From / To pair plus the parameters that shape the blend: duration, easing curve, blend shape, pivot source, and whether the destination cam should inherit pose state from the source.

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

Contents

• What a Blend Entry Contains
• Resolution Order
• Blend Shape — Linear, Cylindrical, Spherical
• Pivot Source
• Inherit State
• Creating a Blend Profile Asset
• Quick Reference
• Glossary
• See Also

What a Blend Entry Contains

Each entry in a .camblendprofile defines a single transition rule:

Camera names correspond to the entity names of your Phantom Camera entities in the scene.

Resolution Order

When a transition occurs, the Cam Core asks the profile for the best entry matching the outgoing → incoming pair. Resolution is by specificity:

This layered resolution lets you author broad defaults (“any” to “any” at 1.0 seconds with Linear shape and Inherit unchecked) while overriding specific transitions (“MenuCam” → “GameplayCam” at 2.5 seconds with Spherical shape, Pivot Source = Destination, and Inherit on).

Blend Shape

How the cam’s position interpolates between source and destination. Rotation always slerps; the shape only affects position.

Auto-fallback to Linear. When neither cam reports a pivot (e.g. environmental cams without follow / look-at targets), the blend lerps straight regardless of the authored shape. The pivot resolution gracefully drops back to Linear so you don’t accidentally break a transition by picking a shape that can’t be computed.

Pivot Source

When Blend Shape is Cylindrical or Spherical, the cam arcs around a pivot in world space. The Pivot Source selects which cam’s pivot to use:

This field is ignored when Blend Shape is Linear.

A cam that doesn’t publish a pivot (typically a body type that has no target — DefaultFollowBody without a follow target) disqualifies itself from being the pivot source. The Cam Core falls back to whichever cam does publish one, or to Linear if neither.

Inherit State

Setting Inherit State opts the matched pair into the cam-to-cam pose handoff protocol. When enabled, the destination cam’s Body stage seeds itself from the outgoing cam’s pose before the blend runs. The blend then reads as a smooth drift instead of a swing.

For when to use it, per-body behavior, and the common authoring gotcha, see the dedicated guide:

State Inheritance API

Default is unchecked so cinematic shots authored at specific poses land at those poses unless you opt in.

Creating a Blend Profile Asset

1. Open the Asset Editor in O3DE.
2. Select New → GS_PhantomCamBlendProfile.
3. Name the asset descriptively — e.g. CombatBlend, CinematicSoftBlend, CharacterSelectBlend.
4. Add blend entries via the + button on the Blend List array.
5. For each entry:
   • Set From Camera name (or leave blank for “any”).
   • Set To Camera name (or leave blank for “any”).
   • Set Blend Time in seconds.
   • Choose Blend Type (easing curve).
   • Choose Blend Shape.
   • Choose Pivot Source (only matters if Shape is not Linear).
   • Tick Inherit State if you want a continuation-feel handoff.
6. Save the asset.
7. Assign it to a Cam Core component’s Blend Profile slot.

A starter SampleRigBlend.camblendprofile ships in gs_phantomcam/Assets/ for reference.

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

Framework API:

• Blend Profiles — Framework API — asset structure, version semantics, GetBestBlend resolution.
• State Inheritance — Framework API — the protocol behind the Inherit State toggle.

Related basics pages:

• The Basics: State Inheritance — when to tick the box, per-body behavior.
• The Basics: Cam Core — the system that consumes the profile.
• The Basics: Phantom Cameras — base cam authoring.
• The Basics: Cam Manager — manager lifecycle.

Get GS_PhantomCam

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

10.3 - Phantom Cameras

A Phantom Camera is a virtual camera definition placed in your level as a component on an ordinary entity. It does not render anything. Instead, the GS_PhantomCameraComponent holds priority, lens, target routing, and a stage pipeline slot that authors fill in to give the cam its behavior. The Cam Manager arbitrates priority across all registered Phantom Cameras in a channel — whichever active cam holds the highest priority drives the real camera at any given moment via the Cam Core.

Where previous versions of GS_PhantomCam shipped separate components for each behavior, all of those behaviors are now stage variants layered on top of the single base component. To make a cam follow, orbit, sweep along a spline, or track a group of subjects, you slot a Body stage and an Aim stage — and optionally one or more Additive stages — from the editor’s type-picker.

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

Contents

• How Priority Works
• PhantomCamData Fields
• Stage Composition
• Channel Scope
• Snap and Focus
• Activating and Deactivating Cameras
• Requesting Camera Data
• Quick Reference
• Glossary
• See Also

How Priority Works

Every GS_PhantomCameraComponent has a base priority. The Cam Manager continuously evaluates priority across all active Phantom Cameras in a channel and routes camera control to the highest. Influences (Influence Fields, gameplay code) can add temporary priority modifiers without touching the base value. When the dominant camera changes, the Cam Manager notifies the Cam Core to begin blending toward the new winner.

In multi-channel projects, each channel arbitrates independently — player 1 dominance changes do not affect player 2’s view.

PhantomCamData Fields

Each Phantom Camera stores a PhantomCamData record with its lens, priority, and follow target. Follow / look-at offsets, damping halflives, and target-mode resolution live on the stages, not on PhantomCamData.

A Phantom Camera with no CamTarget and no inherited channel target sits at its entity’s authored position until a target is bound.

Stage Composition

The cam’s behavior is the composition of one Body stage, one Aim stage, and zero-or-more Additive stages. Each is picked from the editor’s type-picker on the corresponding slot.

A third-person shoulder cam, for example, slots LeadingFollowBody + DefaultLookAtAim + a CollisionReposition additive. An orbital boss cam slots DynamicOrbitBody + DefaultLookAtAim + a PerlinNoise additive for handheld feel.

For full step-by-step composition recipes, see the recipes page.

Stage Composition Recipes API

Retired components

ClampedLook_PhantomCamComponent, StaticOrbit_PhantomCamComponent, and Track_PhantomCamComponent no longer exist as separate components. Their behavior is now provided by stage variants:

AlwaysFaceCameraComponent is unchanged — it is still a billboard helper, not a camera type itself.

Channel Scope

Each Phantom Camera authors a Channel Scope that decides how it participates in the channel system. In single-player projects, leave this at the default (Local) and everything routes through channel 0. In multi-channel projects:

For the full walkthrough, see Channels & Instancing.

Snap and Focus

A Phantom Camera ticks each frame when any of these is true:

• m_hasFocus — this cam is the channel’s currently-driven cam.
• m_alwaysUpdate — authored opt-in to always tick (background-tracking cams).
• m_blendingOut — this cam is the outgoing source of an in-flight blend.

Outside that condition the cam is fully dormant — it does not tick, its stages do not run, and its body does not integrate input.

The cam automatically snaps to its evaluated ideal pose (bypassing damping for one tick) on:

• Focus gain.
• A new target binding (SetCameraTarget).
• A new group-target binding (SetTargetFocusGroup).
• An explicit QueueSnapCamera() call.

For synchronous snap (typically only needed by framework code at mid-spawn binding), call SnapCameraNow() instead.

Activating and Deactivating Cameras

Phantom Cameras participate in priority arbitration only while their entity is active. Enable or disable the entity to add or remove a camera from the channel. The transition between dominant cameras is animated by whichever Blend Profile entry matches the outgoing → incoming pair (see Blend Profiles).

ScriptCanvas

To raise a camera’s priority and make it dominant:

Because priority is numeric, you can activate multiple cameras simultaneously and let priority values determine dominance without manually disabling others.

Requesting Camera Data

Use PhantomCameraRequestBus (addressed by the Phantom Camera entity’s ID) to read or write its configuration at runtime, query staged poses, or trigger an impulse on all ImpulseNoise additives.

ScriptCanvas

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: Phantom Cameras
• Framework API: Stage Pipeline

For related systems:

• The Basics: Cam Manager
• The Basics: Cam Core
• The Basics: Blend Profiles
• The Basics: Influence Fields

Get GS_PhantomCam

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

10.3.1 - Stage Composition

A Phantom Camera’s behavior is the composition of one Body stage, one Aim stage, and zero-or-more Additive stages. The same GS_PhantomCameraComponent becomes a follow cam, an orbital cam, a tracking dolly, or a third-person shoulder cam depending on what is slotted from the editor’s type-picker.

This page is a concept primer for the composition model. For step-by-step recipes (third-person shoulder cam, orbital player cam, static showcase, first-person clamped look, tracking dolly, group-framing cam) see the recipes collection.

PhantomCam Configurations (Recipes) API

For the per-variant fields and kinematic models, see the Stage Pipeline API reference.

Contents

• The Pipeline at a Glance
• Where to Go Next
• See Also

The Pipeline at a Glance

Each tick, the cam runs:

Body → Aim → Reposition additives → Noise additives → Finalize

Each stage owns its own damping. There is no separate “smoothing” stage.

Where to Go Next

See Also

Recipes for stage composition:

• PhantomCam Configurations — the step-by-step builds.

For the full per-variant API and kinematic models:

• Framework API: Stage Pipeline
• Framework API: Body Stage Variants
• Framework API: Aim Stage Variants
• Framework API: Additive Stage Variants

Related basics pages:

• The Basics: Phantom Cameras — base component fields and lifecycle.
• The Basics: Blend Profiles — how transitions between cams are authored.

Get GS_PhantomCam

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

10.3.2 - Noise & Impulse

Camera shake comes in two flavors, both as Noise additives on a Phantom Camera’s stage list:

• PerlinNoise — continuous Perlin-noise displacement. Use for handheld feel, idle sway, low-frequency wobble. Always sampling.
• ImpulseNoise — event-triggered burst, gated by an ADSR envelope. Use for explosions, foot-stomps, gun kicks. Stays silent until you fire it.

Both consume the same .camnoiseprofile asset and the same six-axis Perlin layer model. Stack freely on the same cam — a baseline handheld profile plus an event-triggered impact profile is the canonical combination.

For step-by-step composition recipes (handheld baseline, event-triggered impact, stacked handheld + impact), see the recipes collection.

Camera Noise Configurations (Recipes) API

For the asset reference and per-axis layer details, see Noise Profiles (Framework API). For the stage variants’ authored fields and kinematic models, see Additive Stage Variants (Framework API).

Contents

• Preset Library
• Triggering an Impulse from Gameplay Code
• Stable vs Final Pose for Gameplay Readback
• Authoring a Custom Profile
• See Also

Preset Library

A starter library of .camnoiseprofile assets ships in gs_phantomcam/Assets/Noise Profiles/. Drop one onto a PerlinNoise or ImpulseNoise stage’s Profile slot to get an immediate baseline. Match the preset’s lens family to the cam’s lens for natural feel.

Handheld lens family — pair with PerlinNoise

All-axes shake family — pair with ImpulseNoise or aggressive PerlinNoise

Tuning intensity without re-authoring

Per-cam intensity is dialed on the additive stage’s AmplitudeGain (and FrequencyGain for speed). A single Normal_Mild profile can drive a subtle cutscene cam (AmplitudeGain = 0.3) and a frantic chase cam (AmplitudeGain = 1.8) without authoring new assets.

For project-specific characters — gunfire-tuned impulse profiles, ultra-mild cinematic sway, etc. — see Authoring a Custom Profile.

Triggering an Impulse from Gameplay Code

Fire TriggerCameraImpulse(strength) on the cam to play one burst of every ImpulseNoise additive on it.

C++

#include <GS_PhantomCam/Cameras/GS_PhantomCameraBus.h>

// Compute distance-based falloff.
const float strength = AZ::GetClamp(1.0f - distance / radius, 0.0f, 1.0f);

GS_PhantomCam::PhantomCameraRequestBus::Event(
    activeCameraEntityId,
    &GS_PhantomCam::PhantomCameraRequests::TriggerCameraImpulse,
    strength);

strength multiplies each stage’s AmplitudeGain for that specific burst. Pass 1.0 for full profile intensity, smaller for distance falloff, larger to boost.

Author pattern: distance-attenuated impact source

A typical “explosion at world position X” pattern:

const float distance     = (explosionPos - cameraPos).GetLength();
const float falloff      = AZ::GetClamp(1.0f - distance / kEffectRadius, 0.0f, 1.0f);
const float baseStrength = 1.5f;       // for the explosion's overall punch

const float impulseStrength = baseStrength * falloff;

GS_PhantomCam::PhantomCameraRequestBus::Event(
    activeCamId,
    &GS_PhantomCam::PhantomCameraRequests::TriggerCameraImpulse,
    impulseStrength);

Cams outside kEffectRadius receive strength = 0 and ignore. Cams at the explosion’s exact position receive full baseStrength.

Querying the active cam

TriggerCameraImpulse is per-cam, so you need a target cam id. The common pattern is to track the channel’s currently-active cam via SettingNewCam / SettingNewCamOnChannel and store it, or query CamManagerRequestBus::GetActiveCamCore() for the engine’s active view.

Stable vs Final Pose for Gameplay Readback

Cam pose snapshots come in three flavors:

The pitfall. If your character moves “where the camera is facing,” and you read GetFinalPose (or the entity’s TransformBus), every shake event will momentarily drag the character around. Use GetStablePose instead — the cam’s pose without noise displacement.

AZ::Transform stable;
GS_PhantomCam::PhantomCameraRequestBus::EventResult(
    stable,
    activeCamId,
    &GS_PhantomCam::PhantomCameraRequests::GetStablePose);

const AZ::Vector3 cameraForward = stable.GetBasisY();   // O3DE forward axis