Input Data

The Input Data subsystem bridges the controller entity (where hardware input is read) and the unit entity (where input is acted on). The controller reads raw device events and routes named event values into the unit’s GS_InputDataComponent. Reactor components on the unit then convert that stored state into movement vectors or game actions.

This separation keeps units ignorant of input bindings — any controller can possess any unit without the unit needing to change.

For usage guides and setup examples, see The Basics: GS_Unit.

Contents

• How It Works
• Component Reference
• API Reference
• See Also

How It Works

Breakdown

The input pipeline has three stages. Each stage is a separate component on the unit entity, and they run in order every frame:

Stage	Component	What It Does
1 — Read	GS_PlayerControllerInputReaderComponent	Reads raw input events from the active input profile and writes them into GS_InputDataComponent.
2 — Store	GS_InputDataComponent	Holds the current frame’s input state — button presses, axis values — as structured data.
3 — React	Reactor components	Read from GS_InputDataComponent and produce intent: movement vectors, action triggers, etc.

All reactor components downstream of the store stage read from the same GS_InputDataComponent, so there is no duplicated hardware polling and no risk of two reactors seeing different input states for the same frame.

• The Basics: Controllers — Possession, input routing, and controller assignment.
• The Basics: Core Input — Input profiles, action mappings, and options setup.
• The Basics: Unit Input — Input readers, axis configuration, and ScriptCanvas usage.
• Framework API: Unit Controllers — Controller components, possession API, and C++ extension.
• Framework API: Input Reader — Profile binding, action event reading, and C++ extension.
• Framework API: Input Reactor — InputDataComponent schema, reactor base class, and C++ extension.
• Framework API: Mover Context — Context state, mode authority, and C++ extension.

Component Reference

GS_InputDataComponent

Stores the current input state for a unit as a name-value map. Receives input from the controller via InputDataRequestBus.

Data: AZStd::unordered_map<AZStd::string, float> inputEventStates

The owning controller reference is established when a controller takes possession, observed through the GS_Core PossessionEmissionBus (see Player Input Reader).

Reactors

Reacting to input is a GS_Core mechanism. A unit carries a GS_InputReactorComponent holding a reactor profile asset — a list of authored reaction types — and the component classifies each incoming event’s phase (pressed, held, released, analog) before dispatching it to whichever reactors subscribed to that event name.

GS_Unit supplies the reaction types for the movement domain:

See Unit Input Reactors for their authored fields, and Input Reactors for the component, profiles, phases and how to write a reaction type of your own.

GS_PlayerControllerInputReaderComponent

Extends GS_Core::GS_InputReaderComponent. Sits on the controller entity. Routes input to the possessed unit on HandleFireInput. Updates its possessedUnit reference when OnPossessedUnit fires on the GS_Core PossessionEmissionBus (controller entity). See Player Input Reader for full details.

API Reference

Request Bus: InputDataRequestBus

Commands sent to a specific unit’s input data component. ById bus — addressed by unit entity ID.

Notification Bus: InputDataNotificationBus

Events broadcast to reactor components on the unit. ById bus — addressed by unit entity ID.

See Also

For detailed component pages:

• Input Reactor — Reactor base classes and concrete keyboard/joystick implementations
• Player Input Reader — Controller-side input reading component

For related components:

• Unit Controllers — The controller that routes input to the unit
• Mover Context — Receives SetMoveInputAxis calls from reactors
• GS_Unit Overview

Get GS_Unit

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