Templates

GS_Play ships two kinds of template. Project templates give you a working project with the managers already wired up. Component templates scaffold the classes you write when extending the framework.

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

Project Templates

Both appear in o3de create-project and in O3DE Project Manager once the gem is registered, and both ship inside the gem archives.

Both ship the same starter level, GS_Play_Basic.

Why the manager collection matters

The single most useful thing a project template does is ship a level that already aggregates the manager prefabs into a Managers_Collection.

GS managers only run if they are present in the loaded level. A blank level means no managers, and nothing tells you why. The templates remove that problem by handing you a level where the wiring is done.

That gives you two ways in, depending on what you want:

• A project template — the batteries-included path, with the whole lifecycle already assembled.
• Headless managers — for deploying one feature into a project that is not built on GS_Play.

Editor-Only Environment

GS_Core ships an ==_EDITOR_ONLY_ENVIRONMENT_== prefab whose contents exist while you work but never at runtime — lighting, sky and reference setup you want while authoring a level and do not want to ship in it.

The leading == sorts it to the top of the entity outliner, so it stays out of the way of your actual level contents.

Component Templates

The classes you write when extending GS_Core are generated through the ClassWizard CLI. The wizard handles UUID generation, cmake file-list registration, and module descriptor injection automatically. Never create these files from scratch.

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

<GemPath> is the full path to your gem root. <SymbolName> becomes ${Name} — the prefix on all generated filenames and class names.

Contents

• Project Templates
• Editor-Only Environment
• Component Templates
• Manager Component
• Saver Component
• InputReader Component
• InputReactor Component
• Physics Trigger Component

Manager Component

Template: GS_ManagerComponent

Creates a standard game component with an optional EBus interface header. This is the baseline component pattern for all GS_Play manager-style objects — systems that own state and expose it to other components via a request bus.

Generated files:

• Source/${Name}ManagerComponent.h/.cpp
• Include/${GemName}/${Name}Bus.h (optional — the EBus interface)

CLI:

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

# Skip the EBus header if no bus is needed:
python ClassWizard.py --template GS_ManagerComponent --gem <GemPath> --name <Name> \
    --input-var skip_interface=true

Input vars:

Post-generation: None — cmake registration and module descriptor are fully automatic.

See also: GS_Managers — the built-in manager system this component integrates with.

Saver Component

Template: SaverComponent

Creates a component that participates in the save system. Handles serializing and restoring a specific block of game state when the save system broadcasts its save/load events.

Generated files:

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

CLI:

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

Post-generation: Implement BuildSaveData() and ProcessLoad() bodies with save record reads/writes via GS_Core::SaveSystemRequestBus. Set GetSubComponentName() to a unique string so save keys do not collide with other savers.

See also: GS_Save / Savers — full extension guide with header and implementation examples.

InputReader Component

Template: GS_InputReaderComponent

Sits on the Controller Entity. Reads raw hardware input, resolves it through the active input profile, and feeds the resulting named events to the target entity’s Input Reactor.

Generated files:

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

CLI:

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

Post-generation: Bind the hardware input channels you care about in Activate(), and feed resolved events to the target entity through InputReactorRequestBus.

See also: Input Options — the full input pipeline.

InputReactor Component

Template: InputReactor

Scaffolds a new reaction type — a class that declares which named input events it listens to and what to do when they fire. Reflect it and it appears in the reactor profile’s type dropdown alongside the shipped reactors.

CLI:

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

Post-generation: Return your event names from GetSubscribedEvents(), and handle them in OnInputEvent() — branching on the event phase where press and release mean different things.

See also: Input Reactors — the mechanism, and Unit Input Reactors for worked examples.

Physics Trigger Component

Template: PhysicsTriggerComponent

Creates a component that wraps a PhysX trigger volume. Responds to TriggerEnter / TriggerExit events to fire game logic when entities enter or leave a physics shape.

Generated files:

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

CLI:

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

Post-generation: Implement TriggerEnter / TriggerExit / TriggerHold bodies. Requires a PhysX Shape component on the same entity with Trigger mode enabled. Stack multiple trigger components on one entity for compound logic.

See also: Physics Trigger Volume — full extension guide with header and implementation examples.

See Also

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

• Framework API: GS_Core

For all ClassWizard templates across GS_Play gems:

• Templates List

For getting a project running:

• GS_Managers — what the template’s managers do
• Headless Managers — the alternative to a full manager stack

Get GS_Core

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