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

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

Quick Navigation

Installation

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

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

Quick Installation Summary

1. Enable the GS_Audio gem in your project configuration.
2. Create an Audio Manager prefab and add it to the Game Manager’s Managers list.
3. Create Audio Event Library assets for your sound effects.
4. Place GS_AudioEventComponent on entities that need to play sounds.

Audio Manager

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

Audio Manager API

Audio Events

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

Audio Events API

Mixing & Effects

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

Mixing & Effects API

Score Arrangement

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

Score Arrangement API

Klatt Voice Synthesis

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

Klatt Voice API

See Also

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

• Framework API: GS_Audio

For step-by-step project setup:

• The Basics: GS_Managers

Get GS_Audio

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

3.1 - Audio Manager

The Audio Manager is the singleton controller for the entire audio system. It initializes the MiniAudio engine, manages mixing buses, loads audio event libraries, and coordinates score track playback. Like all GS_Play managers, it extends the Manager base class and responds to the Game Manager lifecycle automatically.

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

Contents

• What It Manages
• Quick Reference
• Glossary
• See Also

What It Manages

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: GS_Audio

For related systems:

• The Basics: Audio Events
• The Basics: Mixing
• The Basics: GS_Managers

Get GS_Audio

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

3.2 - Audio Events

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

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

Contents

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

How It Works

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

Event Configuration

GS_AudioEventComponent

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

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: GS_Audio

For related systems:

• The Basics: Audio Manager
• The Basics: Mixing

Get GS_Audio

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

3.3 - 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 .dialoguedb assets with the Dialogue Editor.
4. Place DialogueSequencer and DialogueUI components in your level.
5. Bake NavMesh in levels where PathTo performances will be used.

Cinematics Manager

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

Cinematics Manager API

Dialogue System

The Dialogue System is the authoring and runtime core. Dialogue content is stored in .dialoguedb assets containing actors, portraits, and sequences. Each sequence is a graph of polymorphic nodes — text, selection, random branch, effects, and performances. A visual node editor lets writers author graphs directly in the O3DE Editor. At runtime, the sequencer walks the graph, evaluates conditions, executes effects, and emits events for the UI layer.

Dialogue System API

Dialogue UI

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

Dialogue UI API

Performances

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

Performances API

See Also

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

• Framework API: GS_Cinematics

For step-by-step project setup:

• Simple Project Setup

Get GS_Cinematics

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

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 content is stored in .dialoguedb assets (DialogueDatabase), which contain named actors and a collection of DialogueSequence records. Each sequence is a graph of polymorphic nodes. At runtime, GS_DialogueManagerComponent manages the database and maps performer names to entities in the level, while DialogueSequencerComponent drives playback — walking the graph, evaluating conditions on branches, executing effects, and emitting events that UI and other systems consume.

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

Contents

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

Dialogue Database

Breakdown

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

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

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

E Indicates extensible classes and methods.

Patterns - Complete list of system patterns used in GS_Play.

DialogueDatabase Asset

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

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

Node Types

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

Conditions

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

Effects

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

Performances

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

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

Runtime Playback

GS_DialogueManagerComponent

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

DialogueSequencerComponent

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

Localization

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

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

ScriptCanvas Usage

Starting a Dialogue Sequence

Reacting to Sequence States

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

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: Dialogue System

For related systems:

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

Get GS_Cinematics

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

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

PulseReactorNotificationBus exposes the reactor’s state for script-driven queries. A common pattern is to wait for a Reactor to receive a pulse, 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_Complete) extends the base paper facing with direct camera core integration. It listens to CamCoreNotificationBus 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. It uses virtual cameras — Phantom Cameras — that compete for control through a priority system. Whichever holds the highest priority drives the real camera’s position, rotation, and FOV. Transitions are governed by Blend Profile assets, and Influence Fields let spatial zones adjust camera behavior dynamically.

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

Quick Navigation

Architecture

Breakdown

Blend Profiles are referenced from within a Phantom Camera’s blend settings. When the Cam Manager determines a transition is needed, it reads the outgoing camera’s blend settings to find the profile to use.

Scenario	Which Profile Is Used
Camera A becomes inactive, Camera B was waiting	Camera A’s blend profile governs the outgoing transition.
Camera B is activated and is now highest priority	Camera B’s blend profile governs the incoming transition.
No blend profile is assigned	Transition is instantaneous — no interpolation.

Because 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. Place a Cam Core entity with GS_CamCoreComponent in every level.
4. Place Phantom Camera entities with desired behavior components.
5. Create Blend Profile assets for camera transitions.

Cam Manager

The Cam Manager is the singleton camera system manager, integrated with GS_Core’s manager lifecycle. It handles startup and shutdown, responds to enable/disable events so the camera can be suspended during cinematics, and broadcasts whenever the dominant camera changes so downstream systems stay in sync.

Cam Manager API

Phantom Cameras

Phantom Cameras are virtual camera definitions placed as components on ordinary entities. Each holds field of view, clip planes, optional follow and look-at targets, positional and rotational offsets, and a priority value. The highest-priority camera drives the real camera. Specialized behavior components extend the vocabulary: first-person, orbit, static orbit, clamped look, and spline track.

Phantom Cameras API

Cam Core

Cam Core is the rendering bridge between the Phantom Camera system and the actual O3DE camera entity. It reads the current dominant camera’s data each frame and writes position, rotation, and FOV to the real camera. It also broadcasts per-frame camera position updates for shadow casters, audio listeners, and LOD controllers.

Cam Core API

Blend Profiles

Blend Profiles are data assets that define how the camera transitions when control shifts between Phantom Cameras. Each profile specifies blend duration, position easing curve, and rotation easing curve — independently, so position can ease out while rotation snaps. Profiles are shared by name across cameras for visual consistency.

Blend Profiles API

Influence Fields

Influence Fields are spatial or global modifiers that dynamically shift camera priority. GlobalCameraInfluence applies to cam core unconditionally, while CameraInfluenceField defines a physics trigger volume that modifies the priority when the player is inside it. Multiple fields with the same camera target stack influence.

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

Cam Manager Entity Configuration

The Cam Manager MUST carry the MainCamera with it. This enables proper control of the camera and ensures there is a Cam Core no matter what stage you load into to start.

Additionally, you can add any phantom cameras that will persist between stage changes. This is usually the “rig” cameras that constantly track the player.

Using a PossessedUnit event on a player controller enables you to immediately set the Cam Manager target to your spawned player unit.

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: 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.2 - Phantom Cameras

Phantom Cameras are virtual camera definitions placed in the level as components on ordinary entities. They do not render anything. Instead, each Phantom Camera holds a configuration record that describes how the real camera should behave when that Phantom Camera is dominant. The Cam Manager determines dominance by comparing priority values — whichever active Phantom Camera holds the highest priority drives the real camera at any given moment.

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

Contents

• How Priority Works
• PhantomCamData Fields
• Camera Behavior Types
• Activating and Deactivating Cameras
• Requesting Camera Data
• Quick Reference
• Glossary
• See Also

How Priority Works

Every GS_PhantomCameraComponent has a priority value. The Cam Manager continuously tracks all active Phantom Cameras and routes camera control to the one with the highest priority. When a Phantom Camera is disabled or deactivated, the next-highest priority camera takes over.

PhantomCamData Fields

Each Phantom Camera stores a PhantomCamData record that defines the full camera configuration for when that camera is dominant.

FollowTarget and LookAtTarget are both optional. A Phantom Camera with neither set holds the position and rotation of its entity in the level.

Camera Behavior Types

Beyond the base GS_PhantomCameraComponent, several behavior components can be added to a Phantom Camera entity to specialize how it moves and aims:

Each behavior component is additive — the base Phantom Camera still drives priority and targeting while the behavior component modifies position or rotation evaluation.

Activating and Deactivating Cameras

Phantom Cameras participate in priority competition only while their entity is active. Enable and disable the entity to add or remove a camera from competition. The transition between dominant cameras is governed by the Blend Profile referenced in the outgoing camera’s blend settings.

ScriptCanvas

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

Because priority is numeric, you can also 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:

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

For related systems:

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

Get GS_PhantomCam

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

10.3 - 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.4 - Blend Profiles

Blend Profiles are data assets that define how the camera transitions when control shifts 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.

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

Contents

• What a Blend Profile Contains
• How Blend Profiles Are Referenced
• Creating a Blend Profile Asset
• Easing Curve Reference
• ScriptCanvas — Triggering a Blend
• Quick Reference
• Glossary
• See Also

What a Blend Profile Contains

Each GS_PhantomCamBlendProfile asset defines the shape of a single camera transition:

Position, rotation, and FOV each have independent easing settings. This makes it straightforward to compose transitions that feel distinct in each axis — for example, position eases out slowly while rotation snaps quickly, or FOV leads the transition while position lags.

How Blend Profiles Are Referenced

Creating a Blend Profile Asset

Blend Profile assets are created from the Asset Browser in the O3DE Editor:

1. Right-click in the Asset Browser where you want to store the profile.
2. Select Create Asset → GS_PhantomCamBlendProfile.
3. Name the asset descriptively — for example, CombatCameraBlend or CinematicSoftBlend.
4. Open the asset to edit duration and easing curves.
5. Assign the asset to one or more Phantom Camera components in the level.

Easing Curve Reference

Easing curves control the acceleration profile of an interpolation. Common choices and their camera feel:

ScriptCanvas — Triggering a Blend

Blends trigger automatically when the dominant Phantom Camera changes. To trigger a blend from script, simply change which camera is active or dominant:

[Custom Event → EnterCombat]
    └─► [EntityId → Set Active (combat camera entity)]
            └─► Cam Manager detects priority change
            └─► Blend Profile on combat camera governs the transition
            └─► Cam Core interpolates position, rotation, FOV over blend duration

There is no separate “start blend” call. The blend begins the moment the Cam Manager determines a new dominant camera and ends when Cam Core finishes interpolating.

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: Blend Profiles

For related systems:

• The Basics: Phantom Cameras
• The Basics: Cam Core
• The Basics: Cam Manager

Get GS_PhantomCam

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

10.5 - Influence Fields

Influence Fields are modifiers that change camera priority dynamically beyond what any individual Phantom Camera’s base prioerity specifies. Two types are available: global components that apply unconditionally, and spatial field components that apply only when the player enters a defined volume.

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

Contents

• Types of Influence Fields
• Priority Stacking
• Quick Reference
• Glossary
• See Also

Types of Influence Fields

Both types use CamInfluenceData records to describe what they modify. Multiple fields can be active at the same time — their effects are resolved by priority stacking.

Priority Stacking

When multiple influence fields are active at the same time, their priority changes add to the target camera’s priority. This enables growingly more granular spaces to regularly shift in, by adding a new influence field, and shift out, when you exit and are in a more general space.

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: Influence Fields

For related systems:

• The Basics: Phantom Cameras
• The Basics: Cam Core
• The Basics: Cam Manager
• The Basics: Stage Data
• Utility: Physics Trigger Volume

Get GS_PhantomCam

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

11 - GS_Stats

GS_Stats provides the statistical and modifier infrastructure for RPG-style character systems. It handles the application, tracking, and expiry of status effects — the layer between raw gameplay events and the numerical state of a character.

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

Quick Navigation

Installation

GS_Stats 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_Stats gem in your project configuration.
2. Define status effect data assets for your game’s modifiers.
3. Place status effect components on entities that need to receive modifiers.

Status Effects

Status Effects are the primary mechanism for applying timed or permanent modifiers to entities. Each effect defines what it changes, how long it lasts, whether it stacks, and what happens on expiry. The system handles the full lifecycle: application, duration tracking, stack management, and cleanup. Effects are data-driven — designers author new types in the Asset Editor without touching code.

Status Effects API

See Also

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

• Framework API: GS_Stats

Get GS_Stats

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

11.1 - Status Effects

Status Effects are timed or permanent modifiers that alter entity stats or behavior. They support stacking, expiration, and side-effect triggering — enabling standard RPG mechanics like poison damage over time, temporary buffs, and debuff stacking.

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

Contents

• How Status Effects Work
• Glossary
• See Also

How Status Effects Work

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: Status Effects

Get GS_Stats

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

12 - GS_UI

GS_UI is the complete user interface framework for GS_Play, built on top of O3DE’s LyShine rendering layer. It provides a singleton manager for canvas lifecycle and focus, a single-tier page navigation architecture, motion-based button animations, a LyShine-specific track animation system authored as data assets, and input interception utilities for pause menus and stage transitions.

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

Quick Navigation

Installation

GS_UI requires GS_Core and LyShine. Add both gems to your project before placing UI components.

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

Quick Installation Summary

1. Enable the GS_UI gem in your project configuration.
2. Create a UI Manager prefab and add it to the Game Manager’s Managers list.
3. Create LyShine UI canvases with GS_UIPageComponent on root elements.
4. Create .uiam animation assets for page transitions and button effects.

UI Manager

The UI Manager is the singleton that owns canvas lifecycle for the entire game session. It loads and unloads canvases by name, maintains a global focus stack, and handles startup focus deterministically. All canvas operations go through the Manager so that cross-canvas navigation and focus transitions remain coordinated.

UI Manager API

Page Navigation

Page Navigation is the single-tier architecture that structures all navigable screens. Canvases contain root pages that can parent nested child pages recursively. Navigation is driven through the Page component: NavigateTo, NavigateBack, ChangePage, and ChangeUI handle all routing. Pages play UiAnimationMotion assets on show and hide for data-driven transitions.

Page Navigation API

UI Interaction

Enhanced button animations and input interception. GS_ButtonComponent extends LyShine interactables with UiAnimationMotion-based hover and select animations. GS_UIInputInterceptorComponent captures input events while a canvas is focused, preventing them from reaching gameplay. Both systems work together on interactive canvases.

UI Interaction API

UI Animation

UI Animation extends GS_Motion with eight LyShine-specific tracks: position, scale, rotation, element alpha, image alpha, image color, text color, and text size. Tracks are authored together in .uiam assets and played in parallel at runtime. Page components embed motion instances for show/hide transitions, and a standalone component makes animations available on any UI entity.

UI Animation API

Widgets

Standalone UI components for game-event-driven scenarios outside the page navigation model. Load screens display automatically during stage transitions. Pause menus overlay gameplay and suppress gameplay input while active.

Widgets API

See Also

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

• Framework API: GS_UI

For step-by-step project setup:

• Simple Project Setup

Get GS_UI

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

12.1 - UI Manager

The UI Manager is the singleton controller for all UI canvases in your project. It loads and unloads canvases, maintains a global focus stack that tracks which canvas the player is currently interacting with, and handles cross-canvas navigation so that opening a pause menu over gameplay UI and returning to it works automatically.

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

Contents

• How It Works
• Loading and Unloading Canvases
• Querying UI State
• UI Input Profile
• Quick Reference
• Glossary
• See Also

How It Works

The UI Manager maintains a global focus stack — a history of which UI canvas has focus. When you open a new canvas (like a pause menu), it pushes onto the stack. When you close it, the previous canvas (gameplay HUD) regains focus automatically.

At startup, the UI Manager loads canvases and waits for root pages to register. One canvas is designated as the startup focus UI — it receives focus automatically when the startup sequence completes.

Loading and Unloading Canvases

ScriptCanvas

If you wish to change between canvases, leaving the previous inactive, and enabling the next:

Toggle off your current canvas, then focus the next. Focus automatically handles enabling the canvas for use.

Using Page: NavigateBack will naturally hide the new canvas, and reactivate the past one.

Querying UI State

ScriptCanvas

UI Input Profile

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: UI Manager

For related systems:

• The Basics: Page Navigation
• The Basics: GS_Managers

Get GS_UI

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

12.2 - Page Navigation

Page Navigation is the core of the GS_UI system. Pages are the fundamental unit of UI organization — each page represents a screen, panel, or section of your interface. Pages can be root pages (registered with the UI Manager as a canvas entry point) or nested child pages (managed by a parent page). Navigation uses a push/pop focus stack so the system always knows where to return when the player backs out.

For architecture details, the NavigateTo algorithm, and component internals, see the Framework API reference.

Contents

• Page Types
• Required Companion Components
• Navigation Methods
• Return Policies
• Page Transitions
• Quick Reference
• Glossary
• See Also

Page Types

A canvas typically has one root page at the top, with child pages nested beneath it for sub-screens (settings tabs, inventory categories, confirmation dialogs).

Example of pages within pages to determine UI display structure, and handling changing focus between pages. SettingsWindowPage represents the main options windows. The child pages are the actual different windows that display within the space, changing with side menu changes.

For guides on complex page navigation, see Lesson: Create UI.

Required Companion Components

Root page entities require two additional components alongside GS_UIPageComponent:

Add both to every root page entity in the UI Editor.

Navigation Methods

These are the primary methods for controlling page flow:

Handling Page Components

Navigating Pages

Changing UIs

Return Policies

Each page has a NavigationReturnPolicy that controls which element gets focus when the page is returned to:

Page Transitions

Pages support three motion slots for animated transitions:

Each slot takes a .uiam (UI Animation Motion) asset. See UI Animation for track types.

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: Pages

For related systems:

• The Basics: UI Manager
• The Basics: UI Animation

Get GS_UI

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

12.3 - UI Interaction

UI Interaction covers two systems that handle player input at the UI layer: enhanced buttons with motion-based hover and select animations, and the input interceptor that captures input events while a canvas is focused.

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

Contents

• Buttons
• Input Interception
• Integration
• Glossary
• See Also

Buttons

GS_ButtonComponent extends LyShine’s interactable system with UiAnimationMotion support. When the player hovers over a button (mouse or gamepad navigation), a configurable animation plays. When the button is selected, a separate animation fires. Both animations use .uiam assets, giving full control over position, scale, rotation, alpha, and color transitions.

Setup

1. Add a LyShine UiButtonComponent (or other interactable) to your entity.
2. Add GS_ButtonComponent to the same entity.
3. Author .uiam assets for hover, unhover, and select states.
4. Assign the assets to the corresponding fields in the Inspector.

Integration with Page Focus

When page navigation moves focus to a button (via keyboard or gamepad), the button treats focus as a hover event and plays its hover animation. This ensures consistent visual feedback regardless of input method.

Input Interception

GS_UIInputInterceptorComponent prevents input from leaking to gameplay systems while a UI canvas is active. It uses a GS_UIInputProfile asset to define which input channels to intercept. Intercepted events are re-broadcast on UIInputNotificationBus so UI-specific logic can respond to them.

When the canvas loses focus, the interceptor deactivates automatically and input flows normally back to gameplay.

Setup

1. Add GS_UIInputInterceptorComponent to the root page entity.
2. Configure a GS_UIInputProfile asset with the channels to intercept.
3. Connect to UIInputNotificationBus in any component that should respond to intercepted events.

Integration

Buttons and input interception work together on interactive canvases:

• The input interceptor blocks gameplay input while a menu is open.
• Buttons provide visual hover/select feedback driven by UIInputNotificationBus events.
• The page system routes gamepad focus to the correct button automatically.

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: UI Interaction
• Framework API: Button
• Framework API: UI Input

For related systems:

• The Basics: UI Animation
• The Basics: Page Navigation

Get GS_UI

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

12.3.1 - Buttons

GS_ButtonComponent is an enhanced button that adds GS_Motion-based animations for hover and select states. For the full guide, see The Basics: UI Interaction.

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

Contents

• How It Works
• Integration with Page Focus
• Handling Button Events
• Glossary
• See Also

How It Works

The GS_ButtonComponent connects to LyShine’s interactable notification system. When the interactable reports a hover event, the button plays its hover animation. When it reports an unhover event, the animation reverses or stops. Select works the same way.

Animations are defined as .uiam assets and assigned in the Inspector. Each button can have independent hover and select motions.

Integration with Page Focus

When page navigation moves focus to a button (via keyboard or gamepad), the button treats focus as a hover event and plays its hover animation. This ensures consistent visual feedback regardless of input method.

Handling Button Events

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: Button

For related systems:

• The Basics: UI Animation
• The Basics: Page Navigation

Get GS_UI

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

12.4 - UI Animation

UI Animation extends the GS_Motion system with 8 LyShine-specific animation tracks. Animations are authored as .uiam (UI Animation Motion) assets in the O3DE Asset Editor and can be used for page transitions, button hover effects, and standalone component animation.

For track type details, the domain extension pattern, and component internals, see the Framework API reference.

Contents

• Available Tracks
• Where Animations Are Used
• Authoring Animations
• Proxy Targeting
• Quick Reference
• Glossary
• See Also

Available Tracks

Each track animates a single LyShine property over time:

Multiple tracks can run simultaneously within a single motion — for example, a page show animation might fade in (Element Alpha) while sliding up (Position) and scaling from 90% to 100% (Scale).

Where Animations Are Used

Authoring Animations

1. Create a new .uiam asset in the O3DE Asset Editor.
2. Add tracks for the properties you want to animate.
3. Configure timing, easing curves, and property values for each track.
4. Optionally set track identifiers for proxy targeting.
5. Assign the asset to a component slot in the Inspector.

Proxy Targeting

When tracks have identifiers (named labels), they appear in the motion’s proxy list. Proxies let you redirect a track to a different entity in the UI hierarchy — for example, animating a background panel separately from a content area within the same page transition.

Quick Reference

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: UI Animation

For related systems:

• The Basics: GS_Motion
• The Basics: Page Navigation
• The Basics: Buttons

Get GS_UI

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

12.5 - Widgets

Widgets are standalone UI components that handle specific game scenarios outside the page navigation model. They activate and deactivate in response to game events rather than player navigation — a load screen appears during a stage transition, a pause menu overlays gameplay when the player pauses.

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

Contents

• Load Screen
• Pause Menu
• Glossary
• See Also

Load Screen

GS_LoadScreenComponent shows a loading canvas during stage transitions and hides it when loading is complete. Place it on the Game Manager entity and configure a LyShine canvas to use as the loading screen.

The component listens for StageManagerNotificationBus events and drives the canvas visibility automatically — no ScriptCanvas or manual triggers required.

Pause Menu

PauseMenuComponent handles the pause overlay. It listens for the configured pause input action and toggles a designated pause canvas on and off, broadcasting events so other systems know to yield control.

Glossary

For full definitions, see the Glossary.

See Also

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

• Framework API: Widgets

For related systems:

• The Basics: UI Manager
• The Basics: Page Navigation

Get GS_UI

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

13 - GS_Unit

GS_Unit is the complete character control system for GS_Play. It handles how entities are registered as controllable units, which controller possesses each unit, how raw player input is captured and converted into intent, and how that intent is translated into physical movement through a modular stack of movers, grounders, and influence fields.

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

Quick Navigation

Installation

GS_Unit requires GS_Core. Add both gems to your project before using any Unit components.

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

Quick Installation Summary

1. Enable the GS_Unit gem in your project configuration.
2. Create a Unit Manager prefab and add it to the Game Manager’s Managers list.
3. Configure physics collision layers for character movement.
4. Place a Player Controller and Unit entity in your level.

Unit Manager

The Unit Manager is the singleton coordinator for everything unit-related. It handles registration of new units as they spawn, maintains an indexed list of all active units queryable by name or ID, and provides the spawn interface for runtime unit creation. It also participates in the standby system for clean level transitions.

Unit Manager API

Controllers

Controllers are the possession layer — they determine which entity a given intelligence (player or AI) currently owns and drives. Player and AI controllers share the same possession interface, so swapping control mid-game or having both active simultaneously requires no special-casing.

Controllers API

Input Data

The Input Data feature set converts hardware signals into structured intent your movement code can consume. The PlayerControllerInputReader reads raw input events, InputData components store the current state, and Input Reactors compute movement vectors from keyboard or joystick input with deadzones and scaling.

Input Data API

Units

Unit overview description, leads to movement.

Units API

See Also

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

• Framework API: GS_Unit

For step-by-step project setup:

• Simple Project Setup

Get GS_Unit

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

13.1 - Unit Manager

The Unit Manager is the global coordinator for all units in a GS_Play project. It maintains a registry of every active unit entity, provides the interface for spawning new units at runtime, tracks which player controllers are currently active, and participates in the GS_Core standby system so that all controlled characters pause cleanly during level transitions.

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

Contents

• What the Unit Manager Does
• Spawning Units
• Registering Player Controllers
• Checking Unit Identity
• Standby Mode
• Quick Reference
• Glossary
• See Also