Devlog: Making Time Deterministic

If two players run the same script on the same level, should they get the same completion time? The answer should obviously be a yes... but getting there is trickier than it sounds.

The Problem

While working on Droning On, I noticed a discrepancy in the amount of time a script would be recorded during a run. I further noticed that the same script on a higher execution speed resulted in a substantial inflation of the total time. Something that took 51 seconds on 1x speed returned 1 minute and 30 seconds on 10x speed.

The root cause came down to how the game was tracking time. Like most games, the logic was tied to the framerate. Every frame, the game checks how much real time has passed and moves the timers forward accordingly. This works fine for most games, but in Droning On, we have leaderboards, and those must remain fair. Small floating-point differences in how time accumulates between frames meant the same script could produce slightly different completion times depending on hardware, framerate, or execution speed. In a game where the entire point is writing efficient code to solve problems, that's not an issue I was willing to accept.

Using A Fixed Timestep

The solution was to decouple game logic from framerate entirely. All simulation--movement, turning, waiting, game object timing, etc--now runs on a fixed timestep. Every game tick is the same length, every time, on every machine. The game managers track elapsed time using these fixed ticks, not the system clock. Same script, same level, same time.

This also means the execution speed mechanic works cleanly. Speeding the game up doesn't change the number of ticks a move takes; it just makes them happen faster. The measured completion time stays identical whether you're watching at 1x or blazing through at 10x.

Unfortunately, It Looks Terrible

If you only update positions on fixed ticks, the movement looks choppy, especially on higher refresh displays. The game might only tick 50 times a second, but your monitor is refreshing at 144Hz. You'd see Gizmo teleporting between grid positions in little stuttery jumps.

So there's a second layer to the fix: visual interpolation. While the game logic snaps Gizmo to grid positions on fixed ticks, the rendering system smoothly lerps Gizmo between those positions every frame. What you see on screen is a buttery-smooth animation. What the game actually tracks underneath is a precise, grid-locked position that only changes on fixed ticks.

This means the game essentially maintains two versions of where Gizmo is at any given moment: where he is logically and where he is visually. Hazards, stations, barriers, the exit--everything that matters checks Gizmo's logical position, not the visual one. The visual one is just there to make it all look nice.

Why It Matters

You'll probably never notice any of this while playing, and that's sort of the point. When you nail a level and see your time on a leaderboard, you can trust that number. Nobody's getting an edge from better hardware or running at slower execution speeds. The clock counts the same ticks either way.

It's one of those invisible systems that only gets noticed if it's broken, and getting it right meant rebuilding a lot of how the game processes time under the hood.

Thanks for reading! As always, your feedback is welcome. If you haven't already, drop a wishlist and come hang out in the Discord. It's the best place to share feedback, follow development, and engage.