input-systems

Architect game input — action mapping (abstracting keys into named actions), rebinding with conflict detection and persistence, multi-device support (keyboard, gamepad, touch), analog deadzones, and feel features like input buffering and coyote time, plus accessibility. Engine-neutral. Use when the

By gamedev-skills · 2,803 installs

npx skills add gamedev-skills/awesome-gamedev-agent-skills --skill input-systems

Source repository · Upstream listing

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 1. Define actions, not keys. Gameplay asks "is jump pressed?", never "is Space pressed?". Actions are the stable contract; bindings are data. 2. 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. 3. 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. 4. Filter analog input. Apply a deadzone to sticks/triggers so resting drift reads as zero, and scale sensitivity/curve to taste. 5. 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). 6. 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 . 7. 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 4.7, Unity 6.3 LTS, Unreal 5.8): Godot InputMap + Input.is action just pressed (valid in process and physics process ); Unity Input System InputAction / action maps; Unreal Enhanced Input Input Actions + Input Mapping Contexts . 2. Analog deadzone and sensitivity Keep the response curve (exponent) separate from sensitivity (a plain gain on the result, usually a camera turn rate) and expose both. Godot's get vector already does the deadzone and rescale above, using the average of the four actions' deadzones (0.2 by default per action) unless you pass one. 3. Input buffering + coyote time (forgiving, responsive feel) 4. Rebinding with conflict detection Keyboard bindings use the physical key ( physical keycode , with keycode left at 0, which is what makes Godot match by position), so WASD stays in the same place on AZERTY or Dvorak; show the label for the player's layout with DisplayServer.keyboard get label from physical . Unity Input System action.PerformInteractiveRebinding() and SaveBindingOverridesAsJson() / LoadBindingOverridesFromJson() ; Unreal Enhanced Input User Settings (enable under Project Settings ▸ Enhanced Input) with player mappable keys on the mapping context. 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. WASD lands in the wrong place on AZERTY/QWERTZ : bindings stored by key letter follow the layout. Store physical key positions and display the layout's label. A rebound gamepad button works only for player 1 : the captured event carried pad 0's device ID. Store bindings for all devices (Godot device = 1 ) unless the game assigns pads to players on purpose. 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 uses InputMap + the Input singleton). 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.