input-systemslisted

# Input Systems ## Purpose Input is where players touch the game, and it is routinely built as the most throwaway part of a codebase: raw key checks scattered through gameplay code. That structure makes controller support a rewrite, rebinding impossible, and context bugs — the pause menu accepting a jump input — inevitable. The fix is one idea: **gameplay code responds to *actions*, never to devices.** ## When to use - Setting up input at the start of a project. - Adding controller, touch, or a second device type to something built for one. - Implementing rebinding or accessibility options. - Controls feel unresponsive, or inputs are dropped. - Input fires in the wrong context — gameplay reacting while a menu is open. ## When NOT to use - Camera control specifically, beyond input reading. That is a gameplay and feel problem in its own right. - Networked input transmission. Use `multiplayer-networking`; a client sends input as a request, and the server validates it. - Engine-specific configuration. Use the platform skill — `unreal-enhanced-input`, `unity-input-system`, `godot-project-conventions`, `roblox-character-systems`. ## Required context | Fact | Why it matters | |---|---| | Which devices must be supported | Keyboard, gamepad, touch and motion have different shapes | | Whether rebinding is required | If yes, the action layer is mandatory rather than merely wise | | Platform certification requirements | Consoles have mandatory input and accessibility req