Eonevolve Learning
Unity and DevelopmentUnity and codeIntermediate~6 min

Reading Player Input: Devices, Actions, and Bindings

Snapshot

~75 sec

Read input as a named action ("Jump", "Move") bound to one or more physical bindings (a key, a button, a stick), instead of checking a specific key directly. That one separation is what lets the same gameplay code work on keyboard, gamepad, and touch.

You will learn

  • Separate an input action's name from the device binding that triggers it.
  • Explain why hardcoding `Input.GetKeyDown` couples gameplay to one device.
  • Subscribe to an action's `performed` event instead of polling a key every frame.

Target outcome

You can react to a named action instead of a specific key, so adding a new device needs a binding change, not a code change.

Visual walkthrough

Visual walkthrough

~6 min

  1. Three layers between a button and gameplay

    • Binding

      One physical control (spacebar, gamepad South button, screen tap) mapped to an action.

    • Action

      A named intent ("Jump", "Move") that gameplay code reacts to, regardless of which binding triggered it.

    • Action map

      A named group of actions active together, such as "Gameplay" or "Menu."

  2. React to the action, not the key

    Invented jump handler. The script never checks a specific key - it subscribes to the named action and lets the input binding decide which physical control triggers it.

    Languagecsharp
    [SerializeField] private InputActionReference jumpAction;

private void OnEnable()
{
    jumpAction.action.performed += HandleJump;
    jumpAction.action.Enable();
}

private void OnDisable()
{
    jumpAction.action.performed -= HandleJump;
    jumpAction.action.Disable();
}

private void HandleJump(InputAction.CallbackContext context)
{
    // React to the named action, not to a specific key or button.
    RequestJump();
}

    Code annotations

    1. Lines 3-6

      Subscribe for a scoped lifetime

      OnEnable attaches the handler and enables the action only while this object is active.

      Effect: The action stops reacting the moment the object is disabled, avoiding leaks.

    2. Lines 13-17

      React to intent, not device

      HandleJump only knows an action named Jump fired - not which physical control caused it.

      Effect: Rebinding the action to a gamepad button requires zero gameplay code changes.

  5. Add gamepad support

    Your jump only works on keyboard because the script checks `KeyCode.Space` directly. A player asks for gamepad support. What changes, and what does not?

    Expected reasoning

    Add a gamepad binding to the existing Jump action; the C# script does not change at all, because it already reacts to the named action rather than a specific key. If the script had checked KeyCode.Space directly, you would need a second code path for the gamepad button instead.

Go deeper