Why Does My Game Speed Up Every Time I Restart It?

The bug was found because players spoke up, and the devlog says so plainly: the problem was only discovered because players reported unusual behavior. That matters, because this kind of bug does not announce itself with a crash or an error message. The game still runs. It just runs wrong, in a way that feels like speed rather than breakage. A player who restarts once may notice nothing. A player who restarts a few times gets a game that feels hyperactive, and the natural instinct is to blame the frame cap, the graphics settings, or the machine. In this case, none of those was the problem. The problem was quantity: too many loops doing the same job at the same time. That mismatch is also why the symptom is easy to misread. Speed feels like a performance win, so a player may first suspect a setting was changed or a limit was raised, when in fact the game is doing the same work several times over. Counting loops, rather than admiring the speed, is what turns the symptom back into a diagnosis.

To see how that happens, follow the loop the devlog describes. A function called animate() updates the 3D scene, moves objects, and checks collisions. The game runs it 60 times per second with setInterval(animate, 1000 / 60), and a function called startGame() creates that interval. A function called endGame() clears it. So far, so tidy. The trouble lives in the restart path. The flow runs from a finished match through endGame(), to a Game Over screen, to restartGame(), and then startGame() is called again, which creates a new animation loop. But sometimes, the devlog says, the old interval was not cleared in time or at all. Each restart can therefore leave a survivor behind. Two animate loops run at the same time, then three, then four, each one stacking more draw calls onto the browser, and the game speeds up like crazy. The devlog gives the range plainly: after a few restarts, the game might be running 3, 5, or even 10 loops at once. There is a second trap hiding in the same code. A guard line, if (!gameStarted) return;, sat inside animate(). It stopped the logic, but not the interval itself. A flag that says stop is not the same as a loop that has actually stopped, and this bug is what that difference looks like in a real game.

The devlog presents three improvements, and the first one is the load-bearing change: always clear the animation loop before starting a new one. A new function, stopGameLoop(), clears the interval and sets the handle to null, and it is called before every start. In the final flow the devlog shows, startGame() calls stopGameLoop() first, then initializeScene(), then startGameLoop(), and startGameLoop() itself calls stopGameLoop() again before creating its interval. The order is the point. Starting a loop is no longer allowed to assume the previous loop is gone; it must prove it, by stopping whatever exists first. That is what guarantees only one active loop at all times, in the devlog's own words. If you remember one line from this case, remember that order: stop, then start, every time, without exception.

The second improvement cleans up the scene itself. Three.js stores objects in GPU memory, the devlog notes, and an old scene left in memory can slow things down. So before starting a new game, a function called cleanupScene() walks the scene with scene.traverse and disposes geometry, material, and material textures, then calls renderer.dispose(). The devlog's summary of that step is that nothing carries over to the next run. The third improvement removes the misleading guard: the if (!gameStarted) return; line comes out of animate(), and the loop now stops correctly by clearing the interval instead of by asking a flag to pretend the loop is off. The reported result is deliberately modest, and this article keeps it that way: the frame rate no longer skyrockets after restarting, and the game behaves consistently no matter how many times the player returns to the main menu or starts a new match. The devlog calls the result smooth, memory-safe, predictable, and FPS-stable, but it gives no numeric frame-rate measurement, so this article gives none either. Do not read a number into a claim the source never made.

Nothing below is presented as what the Velocity Puck developer did beyond the three improvements already described; the checklist generalizes those improvements for your own project, and it stays inside it. The reusable idea is loop ownership: whoever starts a loop must own stopping it, and the restart path is where ownership usually breaks, because the happy path is tested far more than the path that runs for the fifth time. A game that behaves on first launch and misbehaves on the fifth restart is telling you that its start and stop logic disagree. The fix is not a faster loop or a stricter frame cap. It is a single, enforced rule: no new loop may start until the old one is provably gone, and no old scene may survive into the new run. Test the restart the way a real player uses it, repeatedly, impatiently, and from every screen that can lead back into a match. That is the test the happy path never gives you, and it is the test that would have caught this bug before players had to report it.