When we started building Camins, we wrote a short document called the Motor Commitment — a list of things we would not compromise on, no matter how much they complicated the design. The list had four items. By the time we finished the game, it had fourteen.
This piece is not about that list. It's about what we learned trying to keep it.
Control Remapping Is the Start, Not the End
Every serious conversation about motor accessibility in games begins and ends at the same place: let players remap their controls. It is the single most impactful feature you can implement, and the fact that many games still do not offer it in 2025 is genuinely difficult to explain. We're not saying studios that skip remapping are negligent — shipping games is hard, scope is real, and remapping is more engineering work than it looks. But we are saying that when remapping is missing, everything else you do for accessibility sits on a shaky foundation.
In Camins, full remapping was in scope from week one. Every action — movement, camera, interaction, pause, UI navigation — is independently remappable, and the remapping screen itself is navigable by keyboard, gamepad, or single-switch input. We tested it last, which was a mistake we will not repeat: remapping reveals assumptions baked into your input architecture that are very expensive to refactor late in development.
The lesson here was operational, not philosophical: if motor accessibility is a first-class concern, then input architecture needs to be designed with that constraint from the first day of prototyping — not retrofitted after the gameplay loop is locked.
Timing and Dexterity Pressure Are Separate Problems
A common conflation in accessibility discussions is treating timing pressure and dexterity requirements as the same problem. They are not, and solving one does not solve the other.
Timing pressure is about whether a player has enough time to respond to a game event. Dexterity requirements are about whether the physical act of executing a control input is achievable. A player with essential tremor may have no difficulty perceiving a slow-moving puzzle mechanic but may find precise cursor positioning genuinely painful or impossible. A player managing fatigue from a chronic condition might navigate fine when rested but need movement speed reduced on difficult days.
In Camins, we addressed both separately. Timing was handled by removing it almost entirely — there are no timers in Camins, no escalating pressure, no penalties for pausing mid-action. Dexterity was addressed through adjustable movement speed (a slider from 40% to 160% of default), interaction zones sized generously around puzzle objects (we call these "landing areas" internally — the effective radius you need to be within to trigger an interaction, which we ended up making about twice as large as our initial instinct), and an option to reduce the precision required for path-tracing actions.
The important design insight was that some players need slower timing but fine motor precision, while others need fast feedback but cannot maintain precise cursor control. You cannot design a single slider that serves both. You need multiple independent adjustments.
One-Switch and Single-Button Play: Where Things Get Hard
The Game Accessibility Guidelines — a publicly available reference maintained by a collaborative group of accessibility researchers and practitioners — defines several tiers of motor accessibility support. The foundational tier includes remapping and adjustable timing. A more advanced tier addresses one-switch play: the ability to play using a single input device, often via a scanning interface where the game cycles through available actions and the player selects by pressing one button at the right moment.
We did not ship Camins with full one-switch support in the first release. We're not going to claim otherwise. What we did do is design the game's interaction model so that one-switch support is architecturally feasible to add — meaning the game has a discrete action model (there is always a finite, navigable set of available player actions at any given moment) rather than a continuous-input model that would make scanning genuinely difficult to retrofit.
This is a meaningful distinction. Many games that aspire to motor accessibility end up with designs that are technically remappable but would require near-complete redesign to support scanning. Thinking about this early, even if you do not implement it in v1, shapes the design in ways that are hard to undo.
Fatigue Is an Underspecified Problem
Most motor accessibility documentation addresses discrete capability — can a player perform this specific action? — rather than cumulative fatigue. For players managing conditions that cause physical fatigue (multiple sclerosis, long-term fatigue syndromes, certain pain conditions), the question is not only whether they can perform an action, but whether they can perform it repeatedly over a thirty-minute play session without accumulating a physical cost that makes the experience harmful rather than restorative.
Pausa, our shorter game, was designed with this explicitly in mind. It's a game about breathing — its core interaction is slow, deliberate, and low-frequency. But we encountered the fatigue problem in Camins too. Our early puzzle designs required players to retrace paths frequently when they made a wrong turn, which imposed a repetitive motor cost. We redesigned the undo system to be more generous (three levels of undo, each reversing a complete path decision rather than a single step) specifically to reduce the repetition burden for players who find repeated motions tiring.
This is the kind of change that does not appear in an accessibility features list but materially affects the experience for players it is designed for.
What Testing Actually Looks Like for a Small Studio
The honest answer is that we do not have a formal accessibility testing panel. We are a small independent studio, and the infrastructure for rigorous user research with participants representing different motor accessibility needs is not something we could build in the first year of operation. We're not saying that's acceptable as a long-term position — it isn't — but we are saying that waiting for perfect testing conditions before shipping an accessible game is not the right answer either.
What we did was thorough playtesting with the adjustable options ourselves — deliberately playing Camins at minimum movement speed, with simulated input restrictions — combined with community feedback from the broader accessible gaming space and guidance from public resources including the Game Accessibility Guidelines and AbleGamers' Controller Support documentation. We treated every piece of post-launch feedback about control difficulty as a high-priority data point, and we shipped a patch within the first six weeks of launch that expanded the precision of landing areas and added a full-screen cursor option after several players noted difficulty with precision targeting on their setups.
Iterating after launch is not a substitute for getting it right before launch. But it is real work, and it is how we expect to improve.
The Design Philosophy Underneath All of This
There is a version of accessible game design that treats accessibility as a set of features to checklist and ship. We have seen games that have remapping, adjustable timing, colorblind modes, and subtitles — and that still feel like the accessible options were bolted onto a design that was never conceived with a wide range of players in mind.
The version we are trying to build starts from a different premise: that designing for a wide range of motor capabilities makes better games, not just more accessible ones. Generous interaction zones feel good. Adjustable game speed benefits players who want to go faster too, not just those who need slower. Undo systems that are thoughtful about fatigue also benefit players who are learning the puzzle logic and want to experiment without punishment.
This is the principle we try to articulate when we talk about what Games4ALiving is building: not games that make accommodations, but games that are genuinely designed for the range of people who want to play them. Camins is our first attempt at that. It is not perfect. The Motor Commitment document now has fourteen items, and we have fully honored maybe eleven of them. The remaining three are on the roadmap.