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.

In case you were wondering how broken room corners are...

Given my complete inactivity in the game's speedrunning scene combined with currently being the sole person who can verify runs and edit categories/rules/etc (thelegendarymudkip hasn't been able to log in for months), I figure I should open this thread for anyone who is willing to become a Cookie Clicker moderator.

You should hopefully pass these requirements:

• have run the game at least semi-recently
• be ready to regularly verify newly submitted runs and help maintain the game's SRC page if needed
• have some prior experience moderating on speedrun.com (not actually necessary but a definite plus)
• abide by the moderation rules (link)

Utility hack for watching horizontal speed during gameplay, if anyone finds it useful.

Download patch: https://drive.google.com/open?id=1CvfDFS0ObTkbSwFlWIojla8OO4gQtd97 How to apply xdelta patch (either through command line or GUI): https://pcgamingwiki.com/wiki/Xdelta

After watching the recent 3:10 WR (http://www.speedrun.com/run/0zno5oly) I noticed that in level 12, the snowball was moving a lot faster for Sly than it was for me. So I tested, did a couple of runs, and I was always losing at least 5 seconds to him on level 12. I'm not just saying this because I want my world record back - his run is very good, definitely better than mine was. However, it does seem that some phones may have a disadvantage compared to others. It might be something to do with whether you're on Android or iOS, but not necessarily, although flight's iPhone, my iPhone and the iPhones I found in different videos on the internet have a slower level 12 than in Sly's video and the 2 Android phones I tested personally. For now, flight and I have decided to leave everything as it is, but in the future, should the 2 versions be seperate, or should they stay in the same leaderboard? Opinions?