Sixty frames a second is treated as the standard everywhere, and the reasons usually given for it are the wrong ones. It is not primarily about smoothness, and it is definitely not because the eye can see sixty frames and not sixty-one.
It is about the delay between doing something and seeing the result.
Where the number comes from
Displays refresh at a fixed rate, and for a long time almost all of them refreshed sixty times a second. That rate is inherited from the frequency of mains electricity in the countries where television was developed, which is a pleasingly arbitrary origin for something so fixed.
The consequence is that sixty is a ceiling, not a target. A game that draws a hundred and twenty frames a second on a sixty hertz display has thrown half of them away unseen. A game that draws thirty has each frame shown twice.
So the goal is to produce exactly one new frame per refresh, and that is what asking the browser to call you before its next repaint achieves. It is why our builds hook into that rather than running on a timer, as described in what a game loop actually is.
Why film gets away with less
The obvious objection is that films run at twenty-four frames a second and look fine.
Two reasons they do, and neither applies to a game.
A film frame is an exposure, not an instant. The shutter is open for a fraction of a second and everything that moves during that time is smeared across the frame. That blur is a record of the motion between frames, and the eye uses it to fill the gap. A game draws a perfectly sharp snapshot of one instant, so there is nothing bridging one frame and the next, and the gaps are visible as juddering.
And a film is not interactive. Nobody is pressing a button and waiting for the film to respond.
Which brings us to the actual reason the number matters.
Latency is the real point
At sixty frames a second, a button press can wait up to sixteen milliseconds before the frame that reflects it is drawn, plus however long the display takes to show it.
At thirty, that becomes thirty-three milliseconds, and the difference is felt. Not seen, felt, as a vagueness in the controls, a sense of pressing into treacle. Players describe it as the game being unresponsive or the jump being unreliable, and they will rarely say it looks choppy, because the thing they are noticing is not visual.
This is why a fighting game cares more about framerate than an adventure game does. In our fighting build, a player is timing a hit to a fraction of a second. In our painted adventure, a character walks across a scene and nobody is counting milliseconds. Same standard, very different stakes.
Consistency beats the number
A game running at a locked fifty is much more pleasant than one alternating between sixty and forty.
The reason is that the brain adapts to a constant delay very quickly and cannot adapt to a varying one. A steady lag becomes invisible within a minute of play. A lag that changes unpredictably never does, because there is nothing stable to calibrate against.
That is why a stutter is worth more attention than an average. A game that reports sixty frames a second on average and drops one frame every second is a game that feels bad, and no summary statistic will show it.
The usual causes of a dropped frame in a browser game are memory allocation triggering a pause to clean up, decoding an image at the moment it is first drawn, and doing a large piece of work all at once instead of spreading it. All three are avoided by doing the expensive things up front: our builds decode every image as the file opens, before play begins, precisely so no frame during play pays that cost.
Sixteen milliseconds is not much
The budget per frame is about sixteen milliseconds, and realistically less, because the browser needs some of it and so does everything else running on the machine.
Everything in one turn of the loop has to fit: reading input, moving the character, resolving collisions against every platform, checking every collectible, then clearing the canvas and drawing the background, the platforms, the collectibles and the character.
For our builds that is comfortable, because there is not much of it. A platformer scene is perhaps twenty drawing operations. The chess engine is the interesting case, because thinking about a move genuinely takes time, and the solution there is to give it a time limit rather than a depth limit so it always has an answer ready before the frame is due. That approach is described in how a computer plays chess.
Faster displays
Phones with a hundred and twenty hertz displays are now common, and they genuinely improve things: lower latency, smoother motion.
A game has to be written to take advantage. Ours advance the world by exactly one step per frame, so on a faster display they would step more often per second and run fast. The fix is well understood, it is described in why our games do not use delta time, and it is a handful of lines rather than a rewrite.
Being straight about it: the builds are currently written for sixty, and that is the right target for something played once at a party on whatever device is to hand.
What this means for a commission
Framerate matters in proportion to timing. A fighting game needs it. A point-and-click adventure needs it much less.
Testing on a laptop proves nothing. A development machine is several times faster than the phone the game will actually be played on, and every performance problem is invisible on it.
And the fix is nearly always to do less, not to do it faster. Fewer things drawn, smaller images, work moved to load time. That is a design conversation, which is why it happens at the brief and not at the end.
