Stages on GS_Play Gameplay Framework

Body Stage Variants

Mon, 01 Jan 0001 00:00:00 +0000

The Body stage owns state.position for each tick. Five variants ship with GS_PhantomCam — each with its own kinematic model (orbit math, spring damping, path interpolation, band response, etc.). All variants share a target-routing front-end via the CamTargetMode enum documented in Stage Pipeline. Per-variant state inheritance support is summarized below; see State Inheritance for the full protocol.

DefaultFollowBody
OrbitBody
DynamicOrbitBody
LeadingFollowBody
TrackBody
Cross-Variant Summary
See Also

DefaultFollowBody

Simple follow camera. Tracks a target at an authored offset, position-space spring damped.

PhantomCam Configurations

Mon, 01 Jan 0001 00:00:00 +0000

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

Each recipe below names a Body pick, an Aim pick, and any Additive picks, plus the key field values that produce the target behavior. For the concept, the per-tick pipeline, and per-stage field references, see The Basics: Phantom Cameras and the Stage Pipeline API.

Stage Pipeline

Mon, 01 Jan 0001 00:00:00 +0000

Every Phantom Camera runs the same fixed pipeline per tick:

Body → Aim → Reposition additives → Noise additives → Finalize

The Body and Aim stages produce the cam’s smoothed ideal pose; Reposition additives correct it for collision / tug volumes; Noise additives perturb it for shake and impulse; Finalize commits the result to the entity transform and the engine camera component.

Stages are not AZ::Components. They are reflected polymorphic types — derived from IBodyStage, IAimStage, or IAdditiveStage. The editor’s type-picker enumerates registered derivations from the SerializeContext class hierarchy, so other gems can extend the catalog cleanly without touching the base component.

Aim Stage Variants

Mon, 01 Jan 0001 00:00:00 +0000

The Aim stage owns state.rotation for each tick. Two variants ship with GS_PhantomCam; other gems (notably gs_performer) register additional variants through the same IAimStage interface. All variants share a target-routing front-end via the CamTargetMode enum documented in Stage Pipeline.

Aim does not implement state inheritance by design — inheritance is body-only. The destination cam’s aim runs fresh on the inherited body pose.

Aim-Origin Convention
Decoupled Ideal Rotation
DefaultLookAtAim
ClampedLookAim
Extension Surface
See Also

Aim-Origin Convention

A subtle but important rule: every Aim variant uses ctx.camInitialTM.GetTranslation() as the aim origin — the cam’s current world position at the start of the tick — not state.position (which the Body just wrote this tick).

Stage Composition

Mon, 01 Jan 0001 00:00:00 +0000

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

Additive Stage Variants

Mon, 01 Jan 0001 00:00:00 +0000

Additive stages stack — multiple may run per cam. Each declares its phase via GetStage():

Reposition — runs BEFORE noise. Corrections (collision, occlusion, tug reposition). State after this phase is captured as m_stablePose.
Noise — runs AFTER reposition. Perturbations (camera shake, drift, impulses). State after this phase is captured as m_finalPose.

The Phantom Camera component partitions additives into m_repositionStages and m_noiseStages once at slot-assign time so per-tick code does not re-check the enum each frame.

Stages on GS_Play Gameplay Framework

Body Stage Variants

Contents

DefaultFollowBody

PhantomCam Configurations

Stage Pipeline

Aim Stage Variants

Contents

Aim-Origin Convention

Stage Composition

Additive Stage Variants