Why Platformers Feel Wrong: The 14 Milliseconds That Ruin Everything
Mark Rivers•13 min readYou've felt it. You know exactly what I'm talking about, even if you've never been able to articulate it. You load up a platformer in your browser, you press the jump button, and something feels... off. The character jumps, sure. The animation plays. The physics are technically correct. But the entire experience feels like you're controlling a character through a thick layer of peanut butter.
Meanwhile, you boot up Super Mario Bros. on a decades-old NES emulator and every jump feels like a handshake with God. Crisp. Immediate. Alive.
What is the difference? What makes one platformer feel transcendent and another feel like controlling a puppet through a sock? The answer lives in the invisible, unsung engineering decisions that separate great game feel from mediocre game feel—and most of those decisions happen in a window of time shorter than a human blink.
The Input Latency Problem
When you press a button in a browser game, the following sequence occurs:
- Your brain decides to jump (this takes approximately 150-200ms on its own).
- Your finger physically presses the key (~10ms mechanical actuation).
- The keyboard sends an electrical signal to your computer's USB controller (~1ms).
- The operating system's input stack processes the keystroke (~2-4ms).
- The browser's event loop receives the
keydownevent (~4-8ms depending on frame timing). - The game's JavaScript code processes the event and updates the game state (~1-2ms).
- The renderer draws the new frame (~16ms for 60fps, ~8ms for 120fps).
- The monitor displays the frame (~4-8ms for a typical LCD panel).
Add those up and you get a minimum input-to-screen latency of roughly 38-45 milliseconds on a well-optimized system. For a native game running on dedicated hardware with a high-refresh monitor, that number drops to around 20-25ms. For a poorly optimized browser game? It can balloon to 80-120ms.
And here's the devastating part: human perception can detect input latency differences as small as 14 milliseconds. A study published in the journal Computer Graphics Forum found that players could reliably distinguish between 50ms and 64ms of input delay in first-person games. In platformers, where the relationship between button press and character response is even more visceral, the threshold is likely even lower.
"The difference between a platformer that feels 'good' and one that feels 'bad' is often invisible to the eye but screaming-loud to the hands."
This means that browser platformers are fighting physics itself. The additional layers of abstraction between input and screen—the browser event loop, the JavaScript garbage collector, the compositor thread—introduce latency that native games simply don't have.
The Secret Sauce: Coyote Time
Now here's where things get interesting. The best platformers don't just minimize latency—they lie to you about when your inputs happened.
Coyote Time (named after Wile E. Coyote, who famously runs off cliffs and doesn't fall until he looks down) is a technique where the game allows you to jump for a brief window after your character has already walked off a platform edge. In Celeste, this window is 6 frames (~100ms). In Hollow Knight, it's roughly 80ms. In Super Meat Boy, it's about 60ms.
Without coyote time, you would need frame-perfect precision to jump at the exact last pixel of a platform edge. With coyote time, the game secretly says: "Okay, you pressed jump 80 milliseconds after falling off the ledge. That's close enough. I'll pretend you were still on the ground."
The player never knows this is happening. They simply feel like the game is responsive and fair. The lie is invisible, and it makes the game feel like an extension of your body.
Jump Buffering: The Other Lie
Coyote time handles "I pressed jump too late." Jump buffering handles the opposite problem: "I pressed jump too early."
Jump buffering allows you to press the jump button while still in the air, and if you land within a small time window (typically 60-100ms), the game will execute the jump immediately upon landing. Without this, you would need to wait until the exact frame your character touches the ground before pressing jump. With it, you can press jump slightly before landing and the game will "buffer" that input and execute it at the first legal moment.
Here is the staggering truth: almost every platformer that has ever been described as having "tight controls" uses both coyote time and jump buffering. They are not optional features. They are requirements for a game that feels good. And many browser platformers omit them entirely, because their developers don't know these techniques exist.
The Acceleration Curve Problem
Beyond input latency and timing forgiveness, there is a third critical dimension: how your character accelerates.
In real physics, objects accelerate gradually. If you push a box across the floor, it doesn't instantly reach full speed—it ramps up. Most beginner game developers implement their character movement this way, using realistic acceleration and deceleration curves. This feels terrible.
The reason it feels terrible is that realistic acceleration creates a disconnect between input and visual feedback. You press "right" and your character starts moving slowly, then speeds up. The moment of maximum uncertainty—when you first press the button and the character barely moves—is exactly the moment when the player is most anxious about whether the game received their input.
Great platformers solve this with asymmetric acceleration curves:
- Horizontal acceleration: Nearly instant. When you press right, the character reaches 80-90% of maximum speed within 2-3 frames.
- Horizontal deceleration: Slightly delayed. When you release the button, the character slides for 3-5 frames before stopping. This creates a sense of momentum and weight without sacrificing responsiveness.
- Vertical acceleration (gravity): Asymmetric between rising and falling. The character rises at a moderate speed but falls faster than they rose. This creates snappy jumps that feel decisive rather than floaty.
Super Mario Bros. famously uses a gravity multiplier of approximately 2.5x when the character is falling compared to when they are rising. This is physically incorrect—in reality, gravity is constant regardless of direction—but it feels right because it makes jumps feel punchy and controllable.
What Browser Games Get Wrong
Armed with this knowledge, here is a checklist of what I see go wrong in browser platformers:
- No coyote time. The player walks off a ledge by 1 pixel and can no longer jump. The game feels punishing and unfair.
- No jump buffering. The player mashes the jump button during a fall and nothing happens upon landing. The game feels unresponsive.
- Linear acceleration. The character ramps up speed gradually, making early frames of movement feel sluggish.
- Symmetric gravity. The character rises and falls at the same speed, making jumps feel floaty and imprecise.
- requestAnimationFrame inconsistency. Many browser games tie their physics to
requestAnimationFramewithout delta-time correction, meaning that the game runs differently on 60Hz and 144Hz monitors.
Every single one of these is solvable. They require no special hardware. They require no advanced technology. They require only awareness that these problems exist and the willingness to spend an extra 50 lines of code fixing them.
The 14-Millisecond Lesson
The core lesson of game feel is humbling: the difference between "magical" and "mediocre" is not about graphics, story, or budget. It is about the invisible gap between intention and response. The 14 milliseconds that your brain can detect but your eyes cannot see. The phantom jump that coyote time grants you. The buffered input that the game quietly holds until the perfect moment to execute it.
These are not features. They are acts of empathy—small kindnesses from the developer to the player, saying: "I know your hands are imperfect. I will meet you halfway."
The next time a browser platformer feels wrong, you'll know exactly why. And the next time one feels right, you'll know that someone cared about those 14 milliseconds.

Mark Rivers
Lead Puzzle Analyst
Mark Rivers has completely ruined his sleep schedule analyzing hitbox frames in puzzle games. When he isn't getting crushed by virtual watermelons, he writes deep structural critiques of mechanics you didn't even notice.