IN THIS ARTICLE
Templates
Note:This page assumes you’ve read the Template Descriptor Format. It shows how that schema is applied across every built-in template – then links to a full breakdown of each one.
Each template defines a set of source files to generate, variables to collect from the user, and commands to run for build integration.
How Templates Work
A template is a directory containing a template.json descriptor and a Template/ subdirectory with source file scaffolds. When the wizard processes a template, it does the following:
- Reads the descriptor to determine what input variables to collect and what commands to run.
- Collects user input via the GUI or CLI flags, resolving all
${Variable}tokens. - Stages source files from the
Template/subdirectory, applying variable substitution to file names and content. - Evaluates conditions to include or exclude optional files (e.g., interface headers, editor adapters).
- Runs cleanup when conditional files are excluded – scrubbing references like
#includelines and EBus wiring from remaining files. - Executes commands from the
process_commandsarray to integrate the generated files into the build system.
Template Directory Structure
Templates/
MyTemplate/
template.json -- Descriptor file (must contain a "class_wizard" block)
Template/ -- Source files for o3de create-from-template
Source/
${Name}MyType.cpp
${Name}MyType.h
Include/
${GemName}/
${Name}Interface.h
preview.png -- Optional icon for GUI display
Template Discovery
The WizardTemplateScanner scans for template.json files in three locations:
| Priority | Source | Path Pattern |
|---|---|---|
| 1 (highest) | Engine | <engine_path>/Templates/*/template.json |
| 2 | Project | <project_path>/Templates/*/template.json |
| 3 | Gems | <gem_path>/Templates/*/template.json |
Only templates containing a class_wizard block are recognized. Templates are deduplicated by resolved directory path and sorted alphabetically by display name.
Gem paths are resolved via the O3DE manifest API.
Creating Custom Templates
You can create custom templates by placing a properly structured template directory in any of the three discovery locations. A minimal template needs:
- A
Templates/<YourTemplate>/template.jsonwith aclass_wizardblock - A
Templates/<YourTemplate>/Template/directory with your source files ${Variable}tokens in file names and content for substitution
See the Template Descriptor Format for the full JSON schema.
Template Quick Reference
| Display Name | CLI --template Value | Source | Suffix | Key Features |
|---|---|---|---|---|
| Basic Component | default_component | Engine | Component | Optional interface, optional editor adapter |
| Level Component | level_component | Engine | LevelComponent | Level entity attachment, optional interface/editor adapter |
| System Component | system_component | Engine | SystemComponent | System entity, registered in both runtime and editor modules |
| LyShine Component | lyshine_component | Engine | Component | UI canvas integration, Gem::LyShine dependency |
| Data Asset (also known as Generic Asset) | data_asset | Engine | Asset | GenericAssetHandler registration, dedicated system component |
| Attimage | attimage | Engine | (none) | Attachment image data file, no CMake/module registration |
Each row links to a full breakdown of that template’s input variables, generated files, and commands. All of them follow the schema described in the Template Descriptor Format, including its Variables and Cleanup Hints sections.