In August 2020 I completed a run of this game in 25:14, 7 seconds faster than the current record of 25:21. I ended up not submitting this run, because I was unsure if the run was really faster. Even though my run was technically faster, the in-game time was slower, and the run didn't feel faster, either. It didn't feel right for my run to be listed as 1st place. I eventually stopped playing the game and didn't try to analyze the issue any further, until today.

I had a look at the three speedrun.com runs currently listed, as well as three other runs that I was aware of. The first thing to notice about all of them is the discrepancy between the real-time and in-game time:

Krankdud: 25:21 - 23:54 = ~87 seconds ForOhForError (slower): 27:12 - 26:14 = ~58 seconds ForOhForError (faster): 26:57 - 26:00 = ~57 seconds Drusskye (slower): 33:38 - 33:19 = ~19 seconds Drusskye (faster): 28:39 - 27:39 = ~60 seconds -7: 25:14 - 24:43 = ~31 seconds

Having looked into it a little (but not super extensively), the in-game timer appears to pause during room transitions (kind of - explained later) and also slows down along with the game slowing down. Knowing this, we can analyze why the above time differences are what they are.

First of all, not all of these runs feature the game constantly running. ForOhForError's 27:12 run and Drusskye's 28:39 both have a crash, which cost them about 16 and 36 seconds respectively, not counted for the in-game time.

Additionally, load times vary between different runners; this is the distribution of durations of black screens for each run:

You can see large amounts of ~15 frame black screens, corresponding to transitions between adjacent rooms, as well as 8 or more ~125 frame black screens in each run, which are the transitions when entering a dungeon. There are also a few other values in the mix too, resulting from things like performing 2 screen transitions in a row, the aforementioned crash, possibly some fuzzy data, etc, but these are not too significant in this case.

From testing, it seems that for each room transition, 9 black frames are intended to show up; these don't seem to involve loading and they do not pause the in-game timer. This means the real loading time for a transition is 9 less than the values listed above. Taking this into account, it can be seen that ForOhForError's loading times in their 26:57 run are by far the worst of the bunch, generally lasting about 11 frames, while Drusskye's in their 33:38 run are the shortest at around 3 frames - quite a big difference. Over the course of the run there are about 270 short transitions, totalling a difference of about 36 seconds between ForOhFor and Drusskye from these loads alone. These differences in load times are of course present between all of these runs, not just those two.

The final difference is a case of slowdown, and it only applies to Krankdud's PB run. I chose four rooms which all 6 runs seem to complete as fast as possible and as fast as each other:

Timing these rooms for all 6 runs gives the following table:

Krankdud's run is definitely an outlier, and it suggests that they were, probably unknowingly, playing at a tickrate of about 57-58 tps. This adds up to several tens of seconds over the course of the 25 minute run.

In short: load times between rooms and the game not running at a solid 60tps both cause differences between runs that are merely dependent on the game's performance.

These findings might make a solid case to switch to comparing runs by in-game time, rather than real-time. IGT is not necessarily flawless, as it essentially allows slowed down play at no cost and doesn't account for the game crashing, but with some extra rules and such in place it might end up being a better way to time runs than we do it right now.