Remapping must cover every actionable key, not only common ones
Aliases: key binding · control accessibility · input customization · remapping
What it is
Complete remapping lets players replace every actionable input affecting progression, state, navigation, or safety, not only movement and attack. One nonreplaceable menu, confirm, repeated press, camera, or interaction key can make a custom scheme fail in actual play.
Why it happens
Players remap because a default arrangement creates a continuing barrier. Changing frequent actions while retaining an inaccessible consequential one only postpones the barrier to a higher-pressure moment. Complete coverage lets a scheme be organized around reach, device, and muscle memory, and gives players confidence no mandatory node will demand a default action.
Where it stops holding
Reserved system keys and hardware limits may resist rebinding, but need advance disclosure and a viable alternative. Scope is defined by commands players must issue in a complete flow, not internal debugging or passive display input. Defaults still need to work.
Applying it
- Audit inputs from both event and player-flow views: combat, movement, camera, menus, confirm, cancel, interaction, communication, and assistance need configuration or an alternative.
- After remapping, test key flows to find hard-coded default labels in UI and teaching.
- Verification: move every default key and complete a core session from launch to finish; any blocked step is a coverage gap.
Related
- Same group: W3.04.2 Some chord mappings conflict with system shortcuts and need detection · W3.04.3 Controller and keyboard-mouse remaps need independent saving · W3.04.4 A hidden remapping entry lets the default layout deter players
- Nearby: W3.03 Control mapping · W8.04 One-handed and switch-device operation ·
JAccessibility and inclusion - Search terms:
complete remapping·key binding·control accessibility·input customization