Unity input action maps: contexts, control schemes and persistent rebinding

Name intentions before keys

Input code becomes easier to maintain when gameplay asks for an intention such as interact, steer or confirm. A physical key is one way to express that intention. Begin with a small list of intentions and identify which ones should be available together. This prevents a menu shortcut from accidentally remaining a movement command after the interface changes.

Distinguish the layers

An action represents an input intention, a binding connects it to controls, and an action map groups actions that can be enabled together. [1] Control schemes associate binding groups with device requirements; they do not replace your gameplay-context policy. [2] These concepts follow Input System 1.14. Keep context names separate from device names so gamepad users and keyboard users can enter the same game state.

Give one component responsibility

Let one context owner decide which gameplay and interface maps are active. Other components consume actions rather than enabling competing maps independently. With PlayerInput, use the actions belonging to that player; multiple components can have private copies of a shared action asset. [3] Record map transitions alongside pause and possession transitions so input problems can be reproduced from a short event trace.

Example: operating a cargo crane

A character walks to a crane and enters its seat. Disable the walking map, enable the crane map and keep a deliberately chosen pause action available. Leaving the seat reverses that transition. A gamepad stick and keyboard bindings both express the crane’s movement intention without changing crane gameplay code. During a rebind screen, suspend the affected action and show which binding is being changed. Define cancellation, reject disallowed controls, handle conflicts according to a visible policy and restore the intended map state on every exit path. Test leaving the screen through its cancel button as well as by closing the entire menu.

Persistence and limits

Binding overrides can be serialised with SaveBindingOverridesAsJson and restored with LoadBindingOverridesFromJson. [2] Store that data in your chosen save system and provide a reset-to-defaults path. Version the settings when shipped bindings change, because an old override may no longer describe the intended layout. Test two local players, device reconnection, held controls during map switches and repeated rebind sessions. A correct binding path does not prove that the correct player owns the device, that the map is enabled or that the interface displays the effective binding.

Sources

1. Input System 1.14: Actions — Unity Technologies.
2. Input System 1.14: Action bindings — Unity Technologies.
3. Input System 1.14: Player Input component — Unity Technologies.