01 Scylla Input

18 min read

A complete input layer over Unity’s Input System: context stacking, input buffering, runtime rebinding with conflict detection, and button prompts that follow the player’s device, plus its own Input Actions editor and a set of genre presets to start from.

Summary

Scylla Input turns Unity’s Input System into a complete input layer for a game. Unity’s package handles bindings, action assets, and device backends well, but a shipping game also needs to stack input contexts when a menu opens, queue an attack pressed two frames before the previous one finished, let the player rebind anything at runtime without colliding bindings, surface the right button prompt for the active device, and route every input event through one bus the rest of the systems can subscribe to. That is what Scylla Input adds.

The architecture is a single facade, ScyllaInput, that owns a small set of named sub-managers, each focused on one concern: an action manager around the InputActionAsset registry, a context manager that stacks named contexts with priority and blocking, a buffer manager that holds recent action triggers for a few frames, a rebind manager with conflict detection and pluggable persistence, a control-scheme manager that auto-detects keyboard/mouse versus gamepad, and a hints manager that resolves the right prompt sprite for the current scheme. Every significant transition (device connected, action performed, context pushed, rebind completed, scheme changed) goes out as a typed event on the SEX (Scylla Event eXchange) bus.

Scylla Input depends on Scylla Core and Unity’s Input System package, and requires Scylla Core 1.2.0 or newer. The camera, UI, console, and any gameplay code that wants to listen for input can either query the sub-managers directly or subscribe to the input events on the bus. The module ships a ScyllaInputConfiguration ScriptableObject plus a matching JSON config file for the knobs that actually need tuning: storage backend, rebind timeout, logging filters.

Most projects that ship to players need most of what Input offers. A jam prototype might use only the action manager and never touch contexts or rebinding; a shipping action game will probably use every sub-manager, plus a few rounds of icon-set authoring for the hints. The module is intentionally additive: unused sub-managers cost nothing per frame, and a project can adopt them one at a time as the requirements appear.

Features

  • Input Actions Editor. Scylla’s own authoring window for .inputactions assets, opened from Tools/Scylla/Input/Input Actions Editor.... It writes the stock Unity file, so an asset authored here still works with PlayerInput and still opens in Unity’s own editor. A tree of maps, actions and bindings sits beside nine panels running from the asset’s own details through to generated constants, plus a matrix that shows the whole asset at once and marks the keys two actions would both answer. Twelve genre presets, from 2D platformer to flight sim, each carry maps, bindings, schemes and a matching context configuration, and the Input Wizard copies the closest one in so a project starts from a working setup. See Authoring Input Actions.
  • Action Management. IInputActionManager registers any number of InputActionAsset objects, exposes ScyllaInputAction wrappers around Unity’s actions with value-reading helpers (ReadFloat, ReadVector2, ReadValue<T>), and routes performed/started/canceled callbacks through the event bus. It includes a modifier-key disambiguation pass so an Attack action bound to Ctrl+1 does not also fire when the player presses just 1. See Actions and Bindings for the full API.
  • Input Contexts. IInputContextManager keeps a LIFO stack of named InputContext objects, each with a priority and a blocking flag. Pushing a pause menu’s context disables the gameplay action map without unregistering it; popping the context restores the gameplay bindings exactly as they were. Context transitions publish events so UI and audio code can react. See Contexts.
  • Input Buffering. IInputBufferManager queues recent action triggers within a per-action time window. Calling ConsumeBufferedAction at the moment the action becomes legal again is the canonical implementation of fighting-game combo windows, platformer coyote-time and jump buffering, and any action the player can register a few frames early. See Buffering.
  • Runtime Rebinding. IInputBindingManager exposes the low-level rebind operations and binding persistence (StartRebind, save/load), and the higher-level InputRebindManager wrapper adds the interactive state machine and conflict detection that ConfigScreen-style UIs need. Storage backends are pluggable: JSONFileBindingStorage for human-editable profiles on disk and PlayerPrefsBindingStorage for the path of least resistance. The bundled ConfigScreen demo shows the full UX: it lists one row per action, one column per control scheme, lets the player click to rebind, highlights conflicts in red, and saves instantly on accept. See Rebinding.
  • Control Scheme Detection. IControlSchemeManager watches the most recent device activity and emits a ControlSchemeChangedEvent when the player switches from keyboard/mouse to a gamepad (or vice versa). UI and hint code subscribe to this event to swap prompts and selection visuals without polling. See Control Schemes and Hints.
  • Button Prompts. IInputHintsManager resolves a ScyllaInputAction plus the active control scheme into a displayable hint (sprite, text, or both) via registered InputIconSet assets. Authoring an icon set per platform family (Xbox, PlayStation, generic keyboard) is enough to keep prompts honest across the player’s hardware mix. See Control Schemes and Hints.
  • Event-Driven Notifications. Every meaningful Input transition publishes a typed event through the SEX bus: device connect/disconnect, input enabled/disabled, action performed/started/canceled, context pushed/popped/changed, bindings loaded/saved, rebind started/completed/canceled, input buffered/consumed, control scheme changed, hint changed. Other modules listen instead of polling, which keeps the input layer decoupled from its consumers.
  • Configuration. ScyllaInputConfiguration is the ScriptableObject that holds the module’s knobs, grouped into binding storage, rebind, and logging sections. The runtime JSON config file mirrors the same shape, so a player or QA build can override behavior without rebuilding the game. See Configuration.

Concepts

Scylla Input builds on Unity’s Input System, so most of its vocabulary comes from there. Several of the terms sound alike, and control schemes, binding groups and layouts in particular are easy to mix up. This section explains what each one is and what it is used for. The other Input pages use these terms without introducing them again.

The examples refer to a third-person action game with on-foot and driving modes, a pause menu, and support for keyboard and gamepad.

Action maps

An action map is a named group of actions that the game turns on and off together. A game usually has one map per mode of play, such as On Foot, Driving and Menu. Only the actions in enabled maps respond to input, which lets the same key mean different things in different modes. In the example, E enters a vehicle in the on-foot map and sounds the horn in the driving map, and the two never collide because the maps are never enabled at the same time.

The actions inside a map are the things the game listens for, such as Jump or Move. An action is named once and can be bound to any number of controls. Its type decides how it reports. A Button fires when pressed, a Value reports a reading that changes over time, such as a stick position, and a Pass Through reports every change from every control bound to it. Game code looks an action up by its map and its name, so two maps can each have their own Look.

Action maps are stored in an input actions asset (.inputactions), which is Unity’s file format for maps, actions and bindings. Actions and Bindings covers reading actions from code.

Bindings

A binding connects one control to one action. The control is identified by a control path, such as <Keyboard>/space or <Gamepad>/buttonSouth. An action can have several bindings, so Jump can sit on the space bar and on the gamepad’s south face button at the same time.

Besides its path, a binding carries its binding groups, which decide the control schemes it belongs to, and optionally processors and interactions. All three are explained below. Players can replace a binding’s control at runtime, which Rebinding covers.

Processors

A processor changes the value a control reports before the action receives it. Typical processors invert an axis, scale a value, or apply a dead zone so that a stick resting slightly off center reads as zero. A processor set on a binding affects that one control, and a processor set on an action affects every binding of the action. For example, adding an Invert Y processor to the right-stick binding of Look gives the player an inverted camera without any change to game code.

A processor does not change which control a binding uses. Two bindings with the same path but different processors still use the same physical control, so the actions editor marks bindings that carry a processor rather than treating them as different keys.

Interactions

An interaction decides when an action counts as performed. Without one, a button action performs as soon as the button goes down. With a Hold interaction it performs only after the button has been held for a set time, with Tap only when the button is pressed and released quickly, and with Multi Tap only after a set number of taps, such as a double tap. Like processors, interactions can be set on a binding or on an action.

Interactions let one control drive several actions. In the example, tapping Left Ctrl crouches and holding it for a second goes prone. Scylla’s conflict detection knows that a tap and a hold on the same key do not get in each other’s way, and the action events on the bus report which interaction triggered them.

Composites

A composite builds one binding out of several controls. The most familiar example is WASD movement: the four keys are the parts of a 2D Vector composite and together produce one movement vector. Each part has a role, such as up or negative, and the composite type decides which roles exist.

Composites also express key combinations. A Button With One Modifier composite performs Quick Save only when Ctrl is held and S is pressed. Scylla makes sure that pressing Ctrl+S does not also fire an action bound to S alone. Actions and Bindings lists the composite types and how each one takes part in that rule.

Control schemes and binding groups

These two are the easiest to confuse. They are two halves of one mechanism, and in most assets they even share the same name.

A control scheme describes one way of playing the game, such as keyboard and mouse, or a gamepad. It is declared once in the action asset and has a name, a list of the devices it requires or can use, and the name of one binding group.

A binding group is a label on a binding. Every binding lists the groups it belongs to, and that list is what assigns the binding to a scheme: a binding belongs to a scheme when it carries the scheme’s binding group. A binding can carry several groups, and a binding with no group at all belongs to every scheme. That suits controls that should work whatever the player holds, such as a pause key.

Put simply, the scheme is the definition and the binding group is the membership. The scheme says “this is the gamepad way to play, and its bindings are the ones labeled Gamepad“, while the label itself sits on each binding.

Control schemeBinding group
What it isA named way of playing, with the devices it usesA label carried by bindings
Where it is definedOnce per action asset, on the Schemes tab of the actions editorIn each binding’s group list
What it is used forRestricting input to one way of playing when it is appliedAssigning bindings to schemes, and as the columns of the Matrix and the controls screen
How many per bindingNot applicableNone, one or several

The difference has three practical consequences:

  • Columns follow binding groups. The Matrix in the actions editor and the in-game controls screen show one column per binding group. Several of the genre presets give the keyboard two groups, Keyboard and Keyboard Alt, so the alternative keyboard layout gets its own column and its own rebindable bindings.
  • Every group is live unless a scheme is applied. Scylla never applies a scheme on its own, so the bindings of all groups respond at the same time. This is what lets a player pick up a gamepad in the middle of a session without opening a menu. A game that wants only one way of playing to respond, for example a keyboard layout the player chose in the options menu, applies that scheme with SetActiveControlScheme. Bindings outside the scheme’s group then stop responding, while bindings with no group keep working.
  • A binding group needs a scheme. A group that no scheme declares still works at runtime, but Unity’s own actions editor drops it from a binding as soon as anyone changes that binding’s schemes there. The Validation panel in Scylla’s editor warns about such groups.

The word “control scheme” has a second meaning in Scylla. The control scheme manager tracks which kind of device the player used last, such as keyboard and mouse, gamepad or touch, so button prompts can show the right glyphs. It never changes which bindings respond, and it does not read the schemes declared in the action asset. Control Schemes and Hints covers that manager.

Contexts

An input context describes a situation the game can be in, such as on foot, driving or paused, and names the action maps that are enabled in it. Action maps group the actions; contexts decide which maps are on.

Contexts sit on a stack. Opening the pause menu pushes the Menu context, which enables the menu map and disables the gameplay maps. Closing the menu pops the context, and the gameplay maps come back exactly as they were. Game code only says which situation the game is in, and the context takes care of the maps.

Each context has a priority, and a context can block the contexts below it. The Console context does this, so gameplay input stops while the debug console is open. The Rebinding context goes further and consumes every input while the player assigns a new key, so the key they press reaches the rebind and nothing else.

Contexts are defined in a context configuration asset, separate from the action asset, so several action assets can share one set. Scylla ships five default contexts: Gameplay, Menu, Console, Global and Rebinding. Contexts also inform conflict detection. Contexts that share a conflict-exclusive tag are never active together, so their maps can reuse keys without being reported as conflicts. Contexts covers the stack in detail.

Layouts

“Layout” means two different things in the Input documentation.

A config layout describes how an in-game controls screen is arranged, the screen where players see and rebind their controls. It defines three things:

  • Columns. Each column shows one binding group under a header the player sees, such as “Keyboard” or “Gamepad”. A column can also limit which devices a rebind accepts, so the gamepad column only takes gamepad buttons.
  • Groups. These are the headings the screen sorts its rows under. A group is made of whole action maps or of a list of individual actions.
  • Exclusive sets. Each set names groups that are never active at the same time, so bindings they share are not reported as conflicts. A layout can take these from the contexts’ conflict-exclusive tags instead of repeating them.

The config layout is authored on the Layout tab of the actions editor and stored in the asset’s metadata sidecar, so a controls screen reads it at runtime instead of hard-coding its arrangement. An asset without an authored layout gets a derived one, with a column for each control scheme’s binding group and a group for each action map. Authoring Input Actions covers the Layout tab.

A device layout is the Input System’s description of a kind of device and the controls it has. It is the part of a control path in angle brackets: <Gamepad>/buttonSouth names the south face button of any device built on the Gamepad layout, which covers Xbox, PlayStation and Switch controllers alike. Device layouts come from Unity’s Input System. Scylla reads them when it compares bindings, which is how it knows that <Gamepad>/a and <Gamepad>/buttonSouth name the same button.

How the pieces fit together

An action asset holds action maps, the maps hold actions, and each action has bindings to controls. Processors and interactions refine what a binding reports and when it counts, and composites build one binding out of several controls. Binding groups label each binding with the control schemes it belongs to. At runtime, contexts decide which action maps are enabled, and a control scheme, when the game applies one, decides which bindings in those maps respond. The config layout arranges the result into a controls screen the player can rebind from.

Architecture

The runtime layout is a thin facade over a fixed roster of sub-managers, each owning one concern.

flowchart TB
    subgraph Scene
        BS[ScyllaBootstrap]
        SI[ScyllaInput<br/>module facade]
        BS --- SI
    end
    subgraph SubManagers [Sub-managers owned by ScyllaInput]
        AM[InputActionManager]
        CM[InputContextManager]
        BM[InputBufferManager]
        BIM[InputBindingManager]
        SM[ControlSchemeManager]
        HM[InputHintsManager]
    end
    SI --> AM
    SI --> CM
    SI --> BM
    SI --> BIM
    SI --> SM
    SI --> HM
    SEX[SEX Event Bus]
    AM -.events.-> SEX
    CM -.events.-> SEX
    BIM -.events.-> SEX
    SM -.events.-> SEX
    BM -.events.-> SEX

ScyllaInput is a Tier 1 ScyllaModule that auto-registers with the framework on Awake and brings its sub-managers up in initialization. Each sub-manager owns its own state and surface; the facade exists so the framework has one entry point (ScyllaInput.Instance.ActionManager.GetAction("Gameplay - On Foot", "Primary Attack")) and a predictable lifecycle. Gameplay code reaches the sub-managers through Scylla types (ScyllaInputAction, ScyllaInputBinding, ScyllaKey, and the module’s own enums), which keeps the rest of the framework insulated from Unity Input System version churn.

The event-bus arrow is the most important arrow in the diagram. Game code, UI code, audio code, and the camera should subscribe to Input events rather than poll the sub-managers each frame. Polling has its place inside Update loops that already need to read a vector (movement, look, aim), but every transition that fires once and matters has an event for it.

Documentation

The Input module’s sub-pages land one at a time. Each entry below is a live link to its page.

Getting started

  • Getting Started. The five-minute path to a running setup: confirm the module is attached, register an action asset, read an action, subscribe to action events, tour the demos.

Input API

  • Actions and Bindings. The action API in detail: ScyllaInputAction / ScyllaInputActionMap / ScyllaInputBinding, value reading, modifier-key disambiguation, action events, and binding introspection for UI prompts.
  • Contexts. The LIFO context stack: switching named modes (Gameplay, Menu, Pause, Dialog), scoping action maps per context, the two blocking modes, and the context events on the bus.
  • Buffering. Time-windowed input buffering for combo windows, jump leniency, and any input the player can register a few frames before the game is ready to honor it.

Customization

  • Rebinding. Runtime binding overrides: the low-level rebind operation, conflict detection, profile-based persistence with pluggable storage (PlayerPrefs or JSON-on-disk), and the higher-level InputRebindManager that builds a complete ConfigScreen data model.
  • Control Schemes and Hints. Active-scheme detection that auto-switches between keyboard/mouse and gamepad, plus the hint manager that resolves action IDs into the right display string and prompt icon for whichever device the player just touched.

Authoring

  • Authoring Input Actions. The Input Actions editor: editing .inputactions assets in place, the metadata sidecar that carries notes and the controls-screen layout, live conflict detection that understands context exclusivity, generated constants, and moving a whole setup into another project as a bundle.

  • Devices and Bridges. Which device the player is holding, device connect and disconnect events, and the swappable input backend.

Settings

  • Configuration. The ScyllaInputConfiguration ScriptableObject and its companion JSON config file: every knob the Input module exposes, organized into five setting groups, plus the separate ScyllaInputContextConfiguration that ships the default context set.

  • Preferences. The two user-scoped editor settings under Edit > Preferences > Scylla > Input.

Reference

  • API Reference. The full C# API surface for Scylla.Input, generated from XML doc comments by DocFX. Trust this over any signature listed in the prose pages.
  • Changelog. What shipped in each release, newest first.
Updated on October 7, 2026