This is the multi-page printable view of this section. Click here to print.

Return to the regular view of this page.

Options & Input

How to work with the GS_Play options system — player settings with profiles and presets, plus input profiles, groups and runtime binding management.

The Options system covers two things a project needs and rarely wants to write itself:

  • Settings — the options a player changes: volume, graphics, resolution, accessibility. You declare them as data and the framework applies, saves and restores them.
  • Input — group-based input binding that can be rebound and toggled at runtime without code changes.

For architecture details, component properties, and extension patterns, see the Framework API reference.

Options Manager component in the O3DE Inspector

 

Contents


Options Manager

The Options Manager is the singleton that owns both halves of this system. It holds your option profiles and presets, and the active Input Profile. It responds to the Game Manager lifecycle automatically.

Assign three things to it: your option profiles, any presets, and your input profile.


Settings

Settings are the options a player changes — volume, graphics, resolution, accessibility. You declare them as data in an Options Profile asset, and the framework applies, saves and restores them.

Settings API


Input Profiles

Input Profile asset in the O3DE Asset Editor

An Input Profile is a data asset created in the O3DE Asset Editor. It contains named input groups, each holding a set of event mappings. Each event mapping binds a gameplay event name to one or more raw input bindings (key presses, axis movements, button presses) with configurable deadzones.

The key advantage over raw O3DE input bindings is the group system. Groups can be enabled and disabled independently at runtime — a pause menu can suppress gameplay input by disabling the “Gameplay” group, without tearing down and rebuilding bindings.


Enabling and Disabling Input Groups

ScriptCanvas

Enabling, Disabling, and Checking State of Input Groups in Script Canvas


How Input Flows

StageWhat Happens
1 — Raw InputO3DE’s input system captures key/axis/button events.
2 — Input ReaderThe GS_InputReaderComponent on the entity matches raw input against the active Input Profile’s event mappings.
3 — Event MappingMatched input fires a named gameplay event (e.g., “Jump”, “MoveForward”).
4 — ConsumerOther components on the entity (controllers, reactors) handle the gameplay event.

Input Readers filter by group — if a group is disabled, none of its event mappings fire.


Quick Reference

NeedBusMethod / Event
Disable an input groupInputReaderRequestBusDisableInputGroup(groupName)
Enable an input groupInputReaderRequestBusEnableInputGroup(groupName)
Check if group is disabledInputReaderRequestBusIsGroupDisabled(groupName)
Get the active profileOptionsManagerRequestBusGetActiveInputProfile

Glossary

TermMeaning
Input ProfileA data asset containing named input groups with event mappings
Input GroupA named collection of event mappings that can be enabled or disabled at runtime
Event MappingA binding from a gameplay event name to one or more raw input sources
Input ReaderA component that matches raw input against the active Input Profile

For full definitions, see the Glossary.


See Also

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


Get GS_Core

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

1 - Settings

How to declare player settings as data, read and write them from your game, and offer quality presets.

Settings are the options a player changes — volume, graphics quality, resolution, accessibility choices. GS_Play lets you declare them as data and handles the rest: applying each one to the engine, saving them, and restoring them next launch.

You do not write loading code, saving code, or apply code. You author what the options are and what each one drives.

For architecture details and the full API, see the Framework API reference.

 

Contents


Declaring Settings

Settings are authored as data, not code. Create an Options Profile asset and add an option for each thing your game exposes.

Every option carries:

FieldWhat it is
KeyThe name your code and presets use, e.g. audio.master.
Display NameWhat the player sees.
CategoryWhich page it belongs on — Graphics, Audio, Display, Gameplay, Accessibility, Controls.
DescriptionTooltip text.
Apply targetWhat it actually does when changed.

Pick the option kind for the widget you want — a toggle, a slider with min/max/step, a dropdown with labelled entries, or a colour picker.

The apply target is the part worth pausing on. It is what connects the option to the engine: a console variable, the window mode, the resolution, an audio channel’s volume — or nothing at all, if the value is just something your own game code reads.

You can assign more than one profile. They merge by key, so a project can layer its own options over a supplied set.


Reading and Writing Settings

Setting a value applies it, saves it and notifies listeners in one call. You never have to apply or save separately.

NeedMethod
Read a valueGetOptionBool / GetOptionFloat / GetOptionInt / GetOptionString
Change a valueSetOptionBool / SetOptionFloat / SetOptionInt / SetOptionString
Restore one optionResetToDefault
Restore everythingResetAllToDefault
Get every option in a categoryGetOptionsByCategory
React to any changeOnOptionChanged on the notification bus

GetOptionsByCategory is how you build a settings screen without hard-coding it — ask for the Graphics options and build a row per key.

A tip worth taking: the ImGui debug menu renders your entire option catalog live, with the right widget for each option. Author an option, press play, and drive it before you build any UI for it.


Presets

A preset is a named set of values — Low, Medium, High. Create a preset asset, list the keys it sets and the values it sets them to, and assign it to the Options Manager.

Applying a preset overwrites those options, applies and saves in one action.

Presets have no state of their own. A preset counts as active only while every value it names still matches, so the moment a player nudges one slider, the active preset becomes Custom. That is the familiar behaviour, and it happens for free.


Quick Reference

NeedBusMethod / Event
Read a settingOptionsManagerRequestBusGetOptionFloat / Bool / Int / String
Change a settingOptionsManagerRequestBusSetOptionFloat / Bool / Int / String
Restore one settingOptionsManagerRequestBusResetToDefault
Restore everythingOptionsManagerRequestBusResetAllToDefault
List a category’s optionsOptionsManagerRequestBusGetOptionsByCategory
Apply a presetOptionsManagerRequestBusApplyPreset
Know which preset is activeOptionsManagerRequestBusGetActivePresetName
React to a setting changeOptionsManagerNotificationBusOnOptionChanged

Glossary

TermMeaning
Options ProfileAn asset declaring the settings a game exposes
Apply TargetWhat an option does to the engine when its value changes
KeyThe stable name a setting is stored and referred to by
PresetA named set of values, e.g. Low / Medium / High
CustomThe active preset name when values no longer match any preset

See Also

For the full API:

For related systems:


Get GS_Core

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