input-systems

1# Input systems
2 
3Never wire gameplay to raw keys. Map physical inputs (a key, a button, a touch)
4to named **actions** (`jump`, `interact`, `move`), and let gameplay read actions.
5That one indirection gives you rebinding, multi-device support, and accessibility
6almost for free. This skill is the engine-neutral architecture; bind it to
7`unity-input-system`, `unreal-enhanced-input`, or Godot's `InputMap`.
8 
9## When to use
10 
11- Use to design an input layer: actions, bindings, multiple devices, and a
12  rebinding UI with conflict detection and saved bindings.
13- Use to add analog handling (deadzones, sensitivity) and game-feel features
14  (input buffering, coyote time).
15- Use to make controls accessible (full remapping, hold-vs-toggle, sensitivity,
16  no required simultaneous presses).
17 
18**When *not* to use:** for an engine's concrete input package/API, use
19`unity-input-system`, `unreal-enhanced-input`, or Godot's InputMap. For the
20movement/jump *physics* the buffer feeds, see `physics-tuning` and the engine
21movement skill. Persisting bindings to disk is `save-systems`.
22 
23## Core workflow
24 
251. **Define actions, not keys.** Gameplay asks "is `jump` pressed?", never "is
26   Space pressed?". Actions are the stable contract; bindings are data.
272. **Bind per device.** Each action holds bindings for keyboard, gamepad, and
28   touch. The active device is whichever last sent input; swap UI prompts to match.
293. **Read the right edge.** Use *pressed-this-frame* (edge) for discrete actions
30…