Open any tutorial on game programming and within a few pages you will be told to multiply your movement by delta time. It is close to universal advice, it is good advice, and our builds ignore it deliberately.
This is the argument for both sides, and why we land where we do.
The problem delta time solves
A game moves its character a certain distance each frame. Say four units.
On a machine rendering sixty frames a second, that is two hundred and forty units per second. On a machine rendering thirty, it is one hundred and twenty, and the game runs at half speed. On a modern phone refreshing at a hundred and twenty, it runs at double.
This was a real and famous problem. Games from the eighties tied to processor speed became literally unplayable on faster machines, which is why old PCs shipped with a turbo button that made them slower.
Delta time fixes it. Measure how long the last frame took, and express speeds per second rather than per frame. Move the character at two hundred and forty units per second multiplied by the frame duration. A slow frame moves it further, a fast frame moves it less, and the distance covered per second stays constant on any hardware.
That is correct, and for most games it is the right answer.
What it costs
It costs you the ability to say what will happen.
With delta time, no two runs of the game are identical. Frame durations vary by fractions of a millisecond depending on what else the machine is doing, so the character's position after two seconds of holding right is very slightly different every single time. Usually that does not matter.
It matters when you want to test the game by playing it.
Our acceptance test for a platformer does not look at the screen. It drives the game: presses right for a number of steps, presses jump, advances the world, and asserts that the character has reached a particular platform. If each step advances the world by a variable amount, that test becomes a test of the machine it happens to be running on. It passes on a quiet laptop and fails in CI when something else is compiling, and there is no bug to find.
Delta time also has a genuinely nasty failure mode. A frame that takes a long time, because a tab was backgrounded or a garbage collection ran, produces a very large delta, which moves everything a very long way in a single step. Characters teleport through walls. The usual mitigation is to clamp the delta to a maximum, which means that in exactly the situation delta time exists to handle, you stop handling it.
What we do instead
Every frame advances the world by exactly one step. The constants are expressed per frame: a gravity of 0.88, a top speed of 7.6, a coyote window of eight frames. There is no multiplication by anything.
The consequence on a slow machine is that the game runs slightly slow rather than skipping. That is a much gentler failure than teleporting through a wall, and for a game that is being played once at a birthday party on someone's phone, running at fifty-eight frames a second instead of sixty is not a defect anyone will report.
The consequence for us is that the game is deterministic. The same presses produce the same result, every time, on every machine. Which means a test can play a level and assert it is completable, and that assertion means something. That is the whole reason, and it is covered further in proving a game is actually finished.
The honest caveat
A naive fixed step does run fast on a high refresh rate display, and phones with 120Hz screens are common now. We are not pretending that away.
The standard fix, and the one to reach for if this ever bites, is a fixed step with an accumulator. Keep a running total of elapsed time, and each frame run the physics step a whole number of times, however many fit into the accumulated time. The step itself is still fixed and still deterministic, and the pace is now correct on any display. You get both properties at the cost of about six lines.
That is the right long-term shape, and it is on the list. The reason it is not urgent is that our builds are simple enough that a frame never takes meaningfully longer than the display gives it, which is a direct consequence of keeping a whole game inside one small file.
The rule underneath
The general principle is worth stating on its own, because it applies well beyond games.
Determinism is a feature. Any time you replace a fixed quantity with a measured one, you gain adaptability and you lose the ability to reproduce what happened. Sometimes that trade is obviously right. Sometimes, and this is the case people miss, the thing you gave up was the more valuable half.
For a game that is going to be played by thousands of people on unknown hardware, framerate independence is worth more than reproducibility. For a game that is going to be handed to one family on a link, and that we need to be able to prove is finishable before we hand it over, it is the other way round.
What this means for a commission
You would never notice either way. This is an engineering choice with no visible surface. It is here because the reasoning is more interesting than the answer.
It is downstream of how we test. Everything in our process that lets us say a game is finished rather than hope it is depends on the game behaving identically twice, and this is part of that.
And it interacts with feel. The per-frame constants in what makes a jump feel right are only meaningful because a frame is a fixed unit. Switching to delta time would mean re-tuning every one of them.
Both builds in the arcade run this way. Neither has ever teleported anyone through a wall.
