One-Button Games: Why the Best Browser Designers Use Less

There's a game-design rule I think about a lot: the fewer buttons you give a player, the more your design has to do with the rest of the game. Tetris is four operations on a grid. Canabalt (2009, still the genre-defining endless runner) is one button. Super Hexagon is two buttons. None of them have ever felt shallow to me. Quite the opposite. They feel pared down to exactly what they need.

Browser games have a weird relationship with this rule because the format itself rewards it. A player who just clicked through from a Google search has zero patience for a tutorial. They want to be playing within three seconds. A game that asks them to learn six buttons before anything fun happens is a tab close, every time. One button is an invitation. Three buttons is a threshold. Five is a wall.

One button is not actually one input

Where this gets interesting is that 'one button' doesn't mean one option. A tap is different from a press-and-hold. A double-tap is different from both. Releasing the button at different points in a jump arc gives you different jump heights. Pressing the button while moving versus while standing still produces different actions. The good single-button designs squeeze maybe a dozen distinct player actions out of one input, and the player learns the vocabulary by just playing instead of reading a tutorial.

I'll give you a concrete example. The first time I played a precision platformer called Run3 on my bus commute (about three years ago, I think) it took me maybe ninety seconds to figure out the press-vs-hold-vs-tap-in-air thing. I don't remember a tutorial. The level design taught me, by giving me obstacles that required a longer jump and then obstacles that required a shorter one. Each level introduced one new thing about the button. By stage four I was doing combinations I couldn't have explained.

That kind of teaching is impossible if you start with six buttons. The level designer has too many variables to control for. With one button the designer has a constrained problem space and can shape difficulty really precisely.

It forces honesty about the rest of the game

Here's the part of the rule that I think is actually important. If your game only has one input, every other element has to do real work. Visual telegraphing of obstacles has to be unambiguous. The camera has to show enough of the upcoming environment to allow timing decisions. Level pacing has to escalate complexity from inside the constrained vocabulary, not by adding new actions. Audio cues for hits, jumps, and landings have to be tight enough that you can play partly by ear.

I've worked with a couple of indie developers who tried one-button design for the first time and were sort of shaken by it. The constraint reveals where they'd been using input variety to mask other weaknesses. A platformer with five different buttons can hide a sloppy jump arc behind 'interesting' controls. A one-button platformer has nowhere to hide. The jump either feels right or it doesn't.

It doesn't work for everything

I'm not going to pretend the format suits every game. Strategy games don't compress into one input. RPGs need stat menus. Anything with deep state-space exploration (look at Hollow Knight or Slay the Spire) has too many decision dimensions for a single-axis input. The one-button approach is for games whose core is timing-based execution, not decision-based exploration.

Within that domain though, it's the most productive constraint I know of in modern arcade game design. Browser games have rediscovered it almost by accident, and the results are tighter than the all-the-keys games next to them in the same catalogues.

Try a couple. The endless-runner category on this site has several one-button entries. So does platformer. Even some of the puzzle games have stripped down to a single tap. If you've been playing games with elaborate control schemes lately, the change is honestly refreshing.