One-handed play needs a redesign, not fewer buttons

What it is

Cutting a two-handed control scheme's buttons in half is not a one-handed scheme. The real constraints of one-handed play are: fewer available inputs, no simultaneous two-button presses, and all operation concentrated in one hemisphere. One-handed redesign reallocates inputs around these constraints—which actions merge, which split onto timing layers (press and release bound to different actions), which become sequential inputs, and which hand over to assists (auto-aim, auto-sprint). Fewer buttons is one outcome, not the scheme itself.

Why it happens

A two-handed scheme's information architecture assumes two hands exist: left for movement, right for camera and actions, with two-hand division of labour lowering each hand's cognitive load. A one-handed player loses not "a hand" but the entire division structure—every action crowds into one input stream, simultaneous operations (moving while aiming and shooting) become sequencing problems, and operation priority must be decided explicitly by the input scheme. Simply cutting buttons ignores that structural problem: the removed functions still need to be performed, only now their execution path is undefined. A working one-handed scheme starts from the action inventory and reallocates by frequency and timing demand onto the available inputs, with assists taking over the most timing-critical parts when necessary.

Where it stops holding

Redesign does not mean unlimited assistance. When automatic systems take over too much (auto-aim plus auto-dodge plus auto-sprint), the player's operating space shrinks to "choose when to trigger," and the game turns from action into selection—right for some players, a loss of the game for others. Effectiveness also depends on genre: turn-based and strategy games mainly need input remapping for one-handed adaptation, while real-time competitive play involves timing fairness and needs separate handling for casual versus ranked contexts. One-handed schemes are not disability-exclusive either—players with an injured arm, parents holding a child, and commuters on a phone all use the same options, so framing them as "accessibility options" rather than a "disability mode" matches actual usage far better.

Applying it

• Start from the complete action inventory (not the default layout), mark each action's frequency, timing demand, and concurrency relations, then reallocate inputs for the one-handed scheme.
• Offer fully customisable button mapping so any action can bind to any input, including stick-direction combos, long/short presses, and trigger stages.
• Verification: have a one-handed player (or a tester using only one hand) complete a core chapter and log every action that cannot be performed or must be dropped. Each blocker is one correction to the input allocation scheme.

Related

• Same group: W8.04.2 Switch access relies on scanning—scanning speed must be adjustable · W8.04.3 Simultaneous key presses need sequential-input alternatives · W8.04.4 One-handed modes must keep every core action, not amputate features
• Nearby: J1.02 Motor accessibility · W8.01 Difficulty options and customisation · C3.03 Fine motor control
• Search terms: one-handed gaming · button remapping · motor accessibility · input flexibility