GS_Unit ships the reactor types that turn input events into unit movement. They are ordinary Input Reactors — GS_Core owns the mechanism, and GS_Unit supplies the reactions that belong to the movement domain.
Each one writes to the unit’s Mover Context, which is what the movement system reads. Reactors never move a unit themselves; they set intent, and the movers act on it.
For usage guides and setup examples, see The Basics: GS_Unit.
Contents
Setup
- Create an Input Reactor Profile asset.
- Add the reactor types your unit needs, and fill in the event names each one listens to — they must match the event names in your Input Profile.
- Add the Input Reactor component to your unit and assign the profile.
The event names are authored rather than fixed, so a project that calls its jump event "Jump" and one that calls it "Ability_Jump" both work without code changes.
Shipped Reactor Types
KeyboardMovement_InputReactor
Maps four directional event names to the mover context’s X and Y axis input.
| Field | Purpose |
|---|---|
| Move Up Event | Event name for forward movement. |
| Move Down Event | Event name for backward movement. |
| Move Left Event | Event name for left movement. |
| Move Right Event | Event name for right movement. |
Release handling is stacking-aware: if a player is holding both left and right and releases one, movement re-routes to the direction still held rather than stopping. This is what makes keyboard movement feel correct when a player rolls between direction keys, and it is the reason this reactor keeps per-instance state.
JoypadMovement_InputReactor
Routes two analog axis event values straight to the mover context’s X and Y axis input.
| Field | Purpose |
|---|---|
| X Axis Event | Event name for the horizontal stick axis. |
| Y Axis Event | Event name for the vertical stick axis. |
Because stick input arrives as an analog value, this reactor passes it through directly — the magnitude of the stick deflection becomes the magnitude of the movement input, so walking and running fall out of how far the player pushes.
Jump_InputReactor
Drives the mover context’s jump state.
| Field | Purpose |
|---|---|
| Jump Event | Event name for jumping. |
It sets the state when the event is pressed and clears it when released — a clear illustration of why input phases exist, since the whole reactor is those two responses.
Choosing Between Keyboard and Joypad
Both movement reactors write to the same mover context axes, so a unit can carry both and respond to whichever device the player is using. The keyboard reactor only reacts to its four discrete events and the joypad reactor only to its two analog ones, so they do not fight over the same input.
That is the usual setup: one profile with both movement reactors and a jump reactor, assigned to your player unit.
See Also
For the mechanism these build on:
- Input Reactors — the component, profiles, phases, and how to write your own reactor type
- Input Profiles — where event names are defined
For related systems:
- Player Input Reader — feeds events to the reactor
- Movement — what the mover context drives
For conceptual overviews and usage guides:
Get GS_Unit
GS_Unit — Explore this gem on the product page and add it to your project.