There’s a quiet, creeping assumption in modern game design that the only thing standing between a player and a transcendent experience is a menu of toggles. Invincibility modes. Auto-platforming. Damage sliders that reduce a boss’s bite to a gentle nibble. The language around these features has coalesced around the word “accessibility,” and in that rhetorical shift, we’ve lost the thread. Accessibility, in its truest sense, is about removing barriers unrelated to the core challenge—think colorblind modes, rebindable controls, subtitle sizing, or hardware-agnostic input. What we’re actually talking about with many of these new “accessibility” options is difficulty circumvention. And when we conflate the two, we risk erasing the very thing that makes a game a game: its mechanics.
I’m not here to gatekeep. I’m here because I take games seriously as systems of interactive logic, and I believe that flattening those systems under the guise of inclusivity does a disservice to everyone—especially the players these options claim to serve. This isn’t a purity test. It’s a mechanics-first analysis of what happens when we mistake removing challenge for providing access.
The Input Barrier vs. The Comprehension Barrier
Let’s start with a distinction that gets muddied in almost every online debate. There are two fundamentally different types of barriers in a game: input barriers and comprehension barriers. Input barriers are physical or sensory—the inability to press a button rapidly, to hear an audio cue, to distinguish red from green. Comprehension barriers are cognitive or experiential—not understanding a rule, not recognizing a pattern, not having the timing down yet. The first is a hardware problem. The second is the game itself.
True accessibility addresses input barriers. It says: “If your hands can’t maintain a sustained grip on a standard controller, here’s a way to remap every function to a single switch interface.” That’s brilliant, necessary work. The Xbox Adaptive Controller and software like Microsoft’s copilot mode are genuine triumphs of inclusive design. They don’t alter the game’s rules; they alter the pipeline between the player’s intent and the game’s simulation. The challenge remains intact. The means of meeting it are what change.
What we’re seeing now, however, is a different beast. Options that let you skip entire combat encounters, automate parry timing, or make your character unkillable aren’t bridging an input gap. They’re dismantling the comprehension barrier—the very thing that makes a game worth playing. If a player never has to learn a boss’s attack patterns because they can toggle “no damage mode,” they haven’t been made more able. They’ve been denied the opportunity to engage with the system at all.
The Retro Laboratory: When Constraints Were the Teacher
Old games didn’t have accessibility menus. They had something better: a ruthless commitment to teaching through mechanics. Take Super Metroid on the SNES. The game never tells you how to wall jump. It places you in a pit with three little creatures who demonstrate the technique, then leaves you to figure out the timing. You can’t leave until you do. It’s a comprehension barrier, yes, but it’s also a perfectly designed tutorial—one that respects your intelligence enough to let you fail.
I’ve spent hours in that pit. Not because the game was broken, but because I was. My thumbs hadn’t internalized the rhythm. When I finally escaped, I didn’t feel relieved that the ordeal was over. I felt like I’d learned something. That knowledge became part of my toolkit, and the game rewarded me with secret areas that demanded the same skill. The challenge was the content.
Compare this to a modern title that offers a “skip puzzle” button. The player who uses it hasn’t gained anything. They’ve consumed a narrative beat, maybe, but they’ve missed the mechanical conversation. The game becomes a delivery system for cutscenes, not an interactive system. And if the mechanics are the point—if we’re talking about a game built around its combat or platforming—then removing them doesn’t make the game more accessible. It makes it a different product entirely.
Celeste’s Assist Mode: A Case Study in Intentionality
Celeste is often held up as the gold standard for accessibility, and for good reason. Its Assist Mode lets you adjust game speed, give yourself extra dashes, or become invincible. But what’s often missed in the praise is how carefully the developers framed these options. The menu explicitly states that Assist Mode is not the intended experience. It’s a deviation. The game doesn’t pretend that invincibility is just another way to play; it acknowledges that you’re altering the core challenge.
This matters because it preserves the integrity of the design. The default mode remains the benchmark. Players who use Assist Mode know they’re stepping outside the intended mechanical conversation, and that’s fine—it’s their choice. But the game doesn’t lie to them about what they’re doing. It doesn’t rebrand difficulty removal as “accessibility” to avoid hurting feelings. It trusts players to understand the difference.
Contrast this with a game that offers no such framing, where a “story mode” trivializes combat without comment. The player who finishes that mode might believe they’ve experienced the game. But have they? If the game’s systems are built around resource management, positioning, and timing, and those are all rendered moot, what exactly was experienced? A walking simulator with extra steps. There’s nothing wrong with walking simulators—but that’s not what was sold.
Mechanical Erosion and the Death of Mastery
When difficulty options are presented as equivalent, something insidious happens: the mechanical language of a game becomes optional. And when mechanics are optional, they’re devalued. Why spend hours learning a boss’s tells when you can toggle god mode and be done in minutes? The social contract of shared experience—the “I beat Ornstein and Smough too!” moment—dissolves. The community fractures into those who engaged with the systems and those who bypassed them, often without a clear way to tell who did what.
This isn’t elitism. It’s a recognition that games are defined by their rules. A chess puzzle isn’t “accessible” if you can move any piece anywhere regardless of turn order; it’s just not chess anymore. The same applies to a precision platformer with infinite jumps, or a survival horror game with unlimited ammo. The rules are the game. Change the rules, and you’ve changed the game. The question isn’t whether players should be allowed to modify rules—they should, and mods have done this for decades—but whether developers should present those modifications as equally valid ways to play.
There’s a parallel here with the fighting game community, which has long understood that input execution is part of the skill test. A “one-button special move” option might let more people see the animations, but it fundamentally alters the neutral game, the risk-reward of throwing out a DP, and the mental stack of the opponent. The FGC doesn’t reject accessibility; it builds characters with simpler inputs (Ed in Street Fighter V, for instance) while preserving the mechanical integrity of the system. That’s design. That’s intentionality. That’s respecting the player enough to say, “This is the game. Here’s how we can help you play it.”
What We Lose When We Can’t Fail
Failure is the primary teacher in any well-designed game. When you die to a boss, the game is communicating: “You didn’t understand the pattern. Try again.” Each death is a data point, a piece of feedback that refines your mental model. Remove the possibility of failure, and you remove the feedback loop. The player drifts through, unchallenged, unengaged, and ultimately unfulfilled.
This isn’t just my opinion. It’s observable in the way players talk about games they’ve “beaten” on story mode versus those they’ve mastered. The former conversations are about plot beats and visuals. The latter are about mechanics—the exact timing of a parry, the spacing required to dodge a specific attack, the resource trade-offs that made a victory feel earned. Those are the conversations that build communities, that fuel speedrunning and challenge runs, that keep a game alive for years after its release. When we strip out the possibility of failure, we also strip out the vocabulary of mastery.
Case File: Hades and the God Mode Gambit
Supergiant’s Hades offers a fascinating middle ground. Its “God Mode” grants a stacking damage resistance buff each time you die, starting at 20% and capping at 80%. You still have to learn enemy patterns. You still have to manage your dash i-frames and boon synergies. But the punishment for mistakes is softened, and the game meets you where you are. Crucially, God Mode is presented as a distinct option, not the default. The game’s systems remain intact. The feedback loop is preserved, just with a wider margin for error. It’s a design solution, not a design deletion.
Compare this to a hypothetical “skip boss” button. In Hades, bosses are the culmination of everything you’ve learned in a run. Skipping them would gut the game’s structure. God Mode, by contrast, says: “We’ll give you more room to learn, but you still have to learn.” That’s the line. That’s the difference between accessibility and removal.
Hardware Teardowns and the Physicality of Play
I’ve spent more hours than I care to count with a screwdriver in hand, cracking open controllers to understand why a d-pad feels mushy or why a specific microswitch fails after 10,000 presses. The physical layer of input is where accessibility and challenge first shake hands. A controller with high actuation force might be inaccessible to someone with motor impairments, but a controller with zero tactile feedback is a nightmare for anyone trying to hit a frame-perfect parry. The solution isn’t to remove the parry—it’s to design a switch that requires less force while preserving the crisp actuation point that makes timing possible.
Retro hardware is a goldmine for this kind of thinking. The original NES controller’s d-pad uses a rocker design with a central pivot, which gives it a distinct “roll” feel that modern membrane d-pads often lack. That pivot isn’t just nostalgia bait; it’s a mechanical choice that reduces accidental diagonals, a critical factor in games like Contra or Castlevania where an unintended duck could mean death. When we talk about preserving challenge, we’re also talking about preserving the physical interfaces that make precise play possible. A mushy d-pad is an accessibility problem. A well-designed d-pad is a tool for mastery.
Modern controllers have their own lessons. The DualSense’s adaptive triggers can simulate the resistance of a bowstring or the kick of a firearm, adding a layer of mechanical feedback that enhances immersion. But they can also be disabled. That’s a genuine accessibility option—it removes a physical barrier without altering the game’s rules. The trigger still functions; it just doesn’t fight back. The timing window for a shot remains the same. The game’s challenge is preserved.
Design Solutions, Not Difficulty Sliders
So what does a mechanics-respecting approach to accessibility look like? It starts with asking: What is the core challenge of this game, and how can we preserve it while lowering input barriers? For a rhythm game, the core challenge is timing. Audio cues can be supplemented with visual indicators for deaf players. For a precision platformer, the core challenge is spatial execution. Assist modes might offer slower game speeds or visual telegraphs for upcoming obstacles, but they shouldn’t automate the jump itself. The player must still execute. The player must still learn.
This requires developers to articulate—publicly, in their menus and documentation—what the intended experience is. Not as a gatekeeping measure, but as a map. “Here’s the game we designed. Here’s what we tuned every enemy placement and jump arc to achieve. If you need to deviate from that, here are your options, and here’s what they change.” That transparency respects the player’s agency. It says: “We trust you to make an informed choice.”
It also protects the game’s identity. A Dark Souls with an invincibility toggle isn’t Dark Souls anymore. It’s a tour of Lordran. That might be a valid experience for someone, but it’s not the experience the game was built to deliver. Labeling it as such isn’t exclusionary; it’s honest.
The Community’s Role in Preserving Challenge
Players aren’t passive consumers in this equation. The communities that form around challenging games—the speedrunners, the hitless runners, the modders who create even harder difficulty modes—are proof that challenge is a feature, not a bug. These communities don’t exist despite the difficulty; they exist because of it. When developers sand off every rough edge in pursuit of a broader audience, they risk losing the very people who will evangelize the game for years.
I’ve seen this play out in the Celeste community, where the base game’s B-sides and C-sides offer some of the most demanding platforming in the genre. The Assist Mode didn’t dilute that community; it grew it, because the framing was clear. The hardcore players had their mountain to climb, and newcomers had a path to eventually join them. The key was that the mountain remained. Its peak wasn’t lowered; a gondola was simply added for those who needed it, with a sign that said, “The view from the top is different if you climb.”
FAQ: Accessibility, Challenge, and Game Design
What’s the difference between accessibility and difficulty options?
Accessibility options remove barriers unrelated to the core challenge—things like colorblind modes, rebindable controls, subtitle options, or hardware adaptations. Difficulty options alter the game’s rules, such as enemy health, damage output, or the availability of checkpoints. The former preserves the intended experience; the latter changes it. The confusion arises when difficulty options are marketed as accessibility features, which can mislead players about what they’re actually modifying.
Does offering easier modes ruin a game for hardcore players?
Not inherently. The risk comes from poor framing. If a game presents an “easy mode” as equivalent to the default experience, it can devalue the mastery that hardcore players invest in. But if the modes are clearly distinguished—with the default labeled as the intended design—the hardcore community can thrive alongside more casual players. Celeste and Hades are strong examples of this balance. The problem arises when the existence of easier modes leads developers to neglect the tuning of the core experience, assuming that players who want challenge will simply self-impose restrictions.
Can a game be too hard to be accessible?
This question often conflates two issues. A game can be too hard for a specific player’s skill level, but that’s a matter of difficulty, not accessibility. A game is inaccessible if it fails to accommodate physical, sensory, or cognitive disabilities that prevent a player from engaging with its systems at all. A colorblind player who can’t distinguish enemy indicators isn’t facing a difficulty problem; they’re facing an accessibility problem. A player who hasn’t yet developed the timing for a parry is facing a difficulty problem. The solutions for these are different, and treating them as the same does a disservice to both groups.
What should I look for in a game’s accessibility menu to know if it respects the core design?
Look for transparency. A well-designed menu will explain what each option does and, ideally, note whether it deviates from the intended experience. Options that address input, display, or audio barriers without altering game rules (like remapping, color filters, or visual audio cues) are strong signs. Be wary of menus that lump invincibility toggles or auto-combat under “accessibility” without context. The best implementations, like those in The Last of Us Part II, offer granular control while clearly communicating the trade-offs.
Where Do We Go From Here?
The conversation around accessibility in games is too important to be sloppy. We need to insist on precise language. We need to celebrate developers who solve input barriers without dismantling their games’ mechanical cores. And we need to push back—hard—against the idea that removing challenge is a form of inclusion. It’s not. It’s a form of erasure.
On this blog, I’ll continue to tear down controllers, measure input lag, and analyze frame data—not because I think everyone should be a speedrunner, but because I believe that understanding how games work at a mechanical level is the first step toward making them work for more people without losing what makes them special. The goal isn’t to keep anyone out. It’s to build better doors.
Next up: a deep-dive into the input latency of wireless versus wired controllers on original SNES hardware, with oscilloscope readings and a breakdown of why your childhood muscle memory might be lying to you. Subscribe so you don’t miss it.
