Scylla Input

6 min read

Scylla Input gives you a complete input layer on top of Unity’s Input System: context stacking, input buffering, runtime rebinding with conflict detection, and button-prompt resolution that updates automatically when the player switches devices.

Scylla Input is the framework’s input module. It wraps Unity’s Input System behind a single coordinated facade with action management, context stacking, input buffering, runtime rebinding, control-scheme detection, and button-prompt resolution.

Summary

Scylla Input turns Unity’s Input System into a complete input layer for a game, not just binding plumbing. 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 only. 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 you’ll actually want to tune: 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 you can adopt them one at a time as the requirements appear.

Features

  • 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. You call TryConsumeBuffered at the moment the action becomes legal again, which 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: per-action rows, per-control-scheme columns, click to rebind, red highlight on conflict, instant save 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/cancelled, 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 behaviour without rebuilding the game. See Configuration.

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 you have one entry point (ScyllaInput.Instance.ActionManager.GetAction("Attack")) and so the lifecycle is predictable. You interact with 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. Your 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 honour 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.

Settings

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

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.
Updated on July 9, 2026