Unity Input System Integration

What the system is for

Input in Unity has improved a lot with the Input System package, but every project still ends up writing the same connective code. PlayerInput components, action assets, join logic, UI navigation and gameplay actions all need to agree on which device is primary, which player is in which slot and which screen owns input at any moment.

The Input Gateway in Serenity centralizes that routing. It exposes typed services for player input, join behavior and UI routing, and keeps menus, gameplay and multi-player join from stepping on each other.

The Unity problem

A small Unity project can get away with a single PlayerInput component. A real project cannot. The settings menu must accept input even when gameplay is paused. UI navigation must work on gamepad as well as keyboard and mouse. The pause modal must not let gameplay actions through. Multi-player join needs a defined moment for new devices to enter the session, and a defined moment when they are rejected. None of that is solved out of the box.

Without a routing layer, those concerns are answered ad hoc per scene. The result is input bugs that only appear on specific devices, in specific menus or in specific transitions between gameplay and UI.

How Serenity approaches it

Serenity exposes input through IPlayerInputService and IPlayerInputJoinService for player input and join behavior, IUiInputRouter for routing UI input, IPrimaryDeviceSelector for tracking which device is primary and IPrimaryInputGate for gating primary input flow. Player slots are modeled by IPlayerInputSlots and PlayerInputSlot, with PrimaryJoinInfo describing join state.

Behavior is configured through enums such as InputDeviceKind, PlayerInputJoinBehavior and PlayerInputUiInteractionMode, plus settings interfaces IPlayerInputServiceSettingsDefinition, IPlayerInputRoutingSettings, IPlayerInputDeviceFilterSettings and IPlayerInputJoinGateSettings. Factories provide creation points so the Unity implementation can be replaced.

How it fits into Serenity

Input Gateway lives in the Serenity.InputGateway namespace and follows the foundation's layered structure. The Domain layer defines enums, interfaces and structs. The Application layer exposes the services and factory interfaces. Settings for join, routing and device filtering live behind dedicated interfaces so the implementation can change without touching consumers.

Input Gateway cooperates closely with the Menu System for gamepad and keyboard navigation, with the Modal System for input gating when a modal is open, with Game Mode so the active mode can influence routing, and with the Event Dispatcher for any input-related signals that the project chooses to publish.

Practical workflow

1. Configure your Unity Input Actions asset as usual and assign it to the project.
2. Set up the player input service settings to define routing and join behavior.
3. Decide which UI interaction mode applies through PlayerInputUiInteractionMode.
4. Let the input installer register the services through the initialization pipeline.
5. Use IUiInputRouter from menus and modals so they receive input only when they should.
6. Use IPlayerInputJoinService to accept or reject devices joining the session.

What you get

• Player input service IPlayerInputService and join service IPlayerInputJoinService
• UI input router IUiInputRouter for screen-aware input routing
• Primary device selector IPrimaryDeviceSelector and primary input gate IPrimaryInputGate
• Player slots and join info described through IPlayerInputSlots and PrimaryJoinInfo
• Configurable enums InputDeviceKind, PlayerInputJoinBehavior and PlayerInputUiInteractionMode
• Settings interfaces for routing, device filtering and join gating
• Factories that keep the Unity implementation replaceable
• Integration with menus, modals and game mode through shared signals

When to use this

• Projects that need both menu navigation and gameplay input handled consistently across devices.
• Games that support gamepad, keyboard and mouse and need clean routing between them.
• Multi-player projects that need defined join behavior and player slots.
• Codebases that want input to be gated by the current screen or game mode instead of by ad hoc booleans.

Related systems

• Unity Menu System Declarative menus, shared UI themes and predictable navigation, configured as assets instead of hand-wired GameObjects.
• Unity Modal System Reusable confirmation, alert and prompt modals driven by typed signals and shared parameters.
• Unity Game Mode System Typed game state transitions with signals, pause strategies and a readiness gate that other systems can subscribe to.
• Unity Event Dispatcher Typed signals dispatched through a service, with auto-registration support and no static singletons.