Input systems
Never wire gameplay to raw keys. Map physical inputs (a key, a button, a touch)
to named actions (jump, interact, move), and let gameplay read actions.
That one indirection gives you rebinding, multi-device support, and accessibility
almost for free. This skill is the engine-neutral architecture; bind it to
unity-input-system, unreal-enhanced-input, or Godot's InputMap.
When to use
- Use to design an input layer: actions, bindings, multiple devices, and a rebinding UI with conflict detection and saved bindings.
- Use to add analog handling (deadzones, sensitivity) and game-feel features (input buffering, coyote time).
- Use to make controls accessible (full remapping, hold-vs-toggle, sensitivity, no required simultaneous presses).
When not to use: for an engine's concrete input package/API, use
unity-input-system, unreal-enhanced-input, or Godot's InputMap. For the
movement/jump physics the buffer feeds, see physics-tuning and the engine
movement skill. Persisting bindings to disk is save-systems.
Core workflow
- Define actions, not keys. Gameplay asks "is
jumppressed?", never "is Space pressed?". Actions are the stable contract; bindings are data. - Bind per device. Each action holds bindings for keyboard, gamepad, and touch. The active device is whichever last sent input; swap UI prompts to match.
- Read the right edge. Use pressed-this-frame (edge) for discrete actions (jump, interact) and held (level) for continuous ones (move, aim). Confusing the two causes double-fires or missed presses.
- Filter analog input. Apply a deadzone to sticks/triggers so resting drift reads as zero, and scale sensitivity/curve to taste.
- Buffer for feel. Remember a pressed action for a short window so a slightly early press still fires (input buffering); allow a jump shortly after leaving a ledge (coyote time).
- Make rebinding first-class. A UI that captures the next input, detects
conflicts, and persists bindings — and a reset-to-default. Save via
save-systems. - Verify on every device and with rebinds: keyboard, gamepad, touch; rebind an action mid-game and confirm gameplay and prompts follow.
Patterns
1. Actions over raw keys; edge vs held
Engine equivalents: Godot InputMap + Input.is_action_just_pressed; Unity
Input System InputAction / action maps; Unreal Enhanced Input Input Actions +
Input Mapping Contexts.
2. Analog deadzone and sensitivity
3. Input buffering + coyote time (forgiving, responsive feel)
4. Rebinding with conflict detection
Pitfalls
- Hardcoding keys in gameplay blocks rebinding, locks out gamepad/touch, and scatters input logic. Read named actions only.
- Edge vs held confusion: using a held check for jump re-fires every frame; using an edge check for movement drops held input. Match the check to the action.
- Per-axis deadzones clip diagonal stick input and snap movement to the axes. Use a radial deadzone on the vector magnitude.
- No buffering/coyote time makes tight platformers feel unfair even when the physics are correct — players "clearly pressed jump". Add small windows.
- Rebinding without conflict handling lets two actions share a key, or strands the player by unbinding menu access. Detect conflicts; guarantee a way back.
- Not swapping prompts on device change shows "Press Space" to a gamepad player. Track the last-used device and switch glyphs.
- Ignoring accessibility: required simultaneous presses, no remap, fixed sensitivity, hold-only actions. Offer remap, toggle-vs-hold, and sensitivity.
- Reading input in the wrong loop: poll held state in the physics step for consistent movement; capture discrete presses so none are missed between frames.
References
references/buffering-and-accessibility.md— buffering/coyote tuning, jump feel (variable height, apex), device detection and prompt swapping, touch controls, and an accessibility checklist (remap, toggle/hold, sensitivity, latency).
Related skills
unity-input-system,unreal-enhanced-input— concrete engine input APIs (Godot usesInputMap+ theInputsingleton).save-systems— persist custom key bindings and input settings.physics-tuning— the movement the buffer/coyote windows feed into.platformer,fps-shooter— genres whose feel depends on input handling.
