Templates

All GS_Unit extension types are generated through the ClassWizard CLI. The wizard handles UUID generation, cmake file-list registration, and module descriptor injection automatically.

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

python ClassWizard.py \
    --template <TemplateName> \
    --gem <GemPath> \
    --name <SymbolName> \
    [--input-var key=value ...]

Contents

• Unit Controller
• Input Reactor
• Mover Component
• Grounder Component

Unit Controller

Template: UnitController

Creates a Controller component that lives on the Controller Entity (the player or AI controller, not the Unit Entity itself). Manages which Unit is currently possessed, and coordinates possession/unpossession events to sibling controller-side components.

Generated files:

• Source/${Name}ControllerComponent.h/.cpp

CLI:

python ClassWizard.py --template UnitController --gem <GemPath> --name <Name>

Post-generation: Implement OnPossess(unitEntityId) and OnUnpossess() to route activation to the correct input readers and other controller components. The controller entity is persistent; the unit entity is swappable.

See also: Unit Controllers — full extension guide with header and implementation examples.

Input Reactor

Template: InputReactor

Sits on the Unit Entity. Subscribes to named input events from InputDataNotificationBus (broadcast by an InputReaderComponent on the Controller side) and translates them into MoverContextRequestBus calls.

Generated files:

• Source/${Name}InputReactorComponent.h/.cpp

CLI:

python ClassWizard.py --template InputReactor --gem <GemPath> --name <Name>

Post-generation:

• Register event name strings in inputReactEvents in Activate().
• Implement each OnInputEvent(name, value) handler to call the appropriate MoverContextRequestBus method.
• Multiple reactors can coexist on a Unit, each handling different input channels.

See also: Input Reactor — full extension guide with examples.

Mover Component

Template: Mover

Creates a Mover component that drives an entity’s movement each tick. Activates when GS_MoverContextComponent switches to the matching mode name, then calls HandleMovement() and HandleRotation() while active.

Two base classes available via --input-var:

Generated files (Physics Mover):

• Source/${Name}PhysicsMoverComponent.h/.cpp

Generated files (Base Mover):

• Source/${Name}MoverComponent.h/.cpp

CLI:

# Physics Mover (default):
python ClassWizard.py --template Mover --gem <GemPath> --name <Name> \
    --input-var mover_base="Physics Mover"

# Base Mover:
python ClassWizard.py --template Mover --gem <GemPath> --name <Name> \
    --input-var mover_base="Base Mover"

Post-generation:

• Set m_moveModeName and m_rotateModeName strings in Activate() to match the mode names configured in your MoverContext.
• Implement HandleMovement() and HandleRotation(). The Physics Mover template comes pre-filled with spring-damper stubs using AccelerationSpringDamper and QuaternionSpringDamper.
• In CheckCanOperate(), lazy-fetch any additional context pointers your mover needs.
• One Mover per movement mode. All Mover components on a Unit Entity coexist — the MoverContext activates only the matching one at a time.

See also: Movers — full mover architecture and extension guide with code examples.

Grounder Component

Template: Grounder

Creates a Grounder component that determines ground state (Falling / Grounded / Sliding) each tick and reports it back to GS_MoverContextComponent. Active when the MoverContext switches to the matching grounding mode name.

Two base classes available via --input-var:

Generated files (Physics Ray Grounder):

• Source/${Name}PhysicsRayGrounderComponent.h/.cpp

Generated files (Base Grounder):

• Source/${Name}GrounderComponent.h/.cpp

CLI:

# Physics Ray Grounder (default):
python ClassWizard.py --template Grounder --gem <GemPath> --name <Name> \
    --input-var grounder_base="Physics Ray Grounder"

# Base Grounder:
python ClassWizard.py --template Grounder --gem <GemPath> --name <Name> \
    --input-var grounder_base="Base Grounder"

Post-generation:

• Set m_groundModeName in Activate().
• For Physics Ray Grounder: The base class handles the raycast, spring correction, and gravity. Override HandleGrounding() and GroundingStateChange() only to add custom reactions — call the base first.
• For Base Grounder: Implement HandleGrounding() with your detection method. Call GroundingStateChange(0/1/2) when state changes (0 = Falling, 1 = Grounded, 2 = Sliding), and SetGroundNormal() on the MoverContext when on a surface.
• Typically one grounder per unit type. Swap the grounder via mode name for units that switch between ground-based and other locomotion.

See also: Grounders — full grounder architecture and extension guide with code examples.

See Also

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

• Framework API: GS_Unit

For all ClassWizard templates across GS_Play gems:

• Templates List

Get GS_Unit

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