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.
There is one already, that people have been using. https://discord.gg/g2fdSwy
Also quite importantly: the boundaries of the entire map (ie. the edges of the rectangle containing all the existing screens, spanning 10 screen widths by 10 screen heights) are sort of "reinforced"; there is only one precise position value that will let you perform a warp if you are up against them, and you can't bounce off because that prevents screen transitions for that frame. That's why trying to do it at the top of the overworld might seem more difficult than in other places.
Just to unify information: when you warp, the "expected" screen is loaded, but your internal position on the grid of screens (confusingly called xpos and ypos in code) gets offset incorrectly. The latter determines the tileset/palette of the screen and, importantly, to which screens the edges of the screen will take you (which is why once you've done a regular transition, there is no more discrepancy). If the room that is attempted to load exists, it will load, even if that puts your internal screen grid position onto a hole in the map or outside the map bounds entirely. If it doesn't exist, you just die.
Presumably that one's just because the ceiling is at a different height in the two rooms.
Yes, in fact it's pretty easy even in real time to chain horizontal warps by just staying near the right edge and repeatedly transitioning up and down:
Essentially the way to abuse corners is to be close to one edge of the screen as you move across another edge. After transitioning, because you are in the corner, the room transition logic assumes you have moved across two edges at once and offsets you by 1 room both horizontally and vertically. There is some extra nuance, because the wrong screen is loaded until you transition again, but practically speaking this lets you warp along a room edge like so:
in all 8 ways (as far as I'm aware).
The TAS above takes this path through the map, with red arrows representing "warps" and blue arrows/lines representing normal movement: link
we are taking over!!I used some copy of GameMaker 8.1 that was on my PC, don't remember where it came from but it must have been thanks to the IWBTG fangame community. I can publish the build I made if needed, but even with a watermark or something, it might still be too easy to edit out, with there being decompilers for pre-GM:S games.
There's an archive of old ludum dare entries here (link to cat planet directly): https://ludumdata.openfu.com/game/34055
Downloads from that page in case something happens to it: Newest version: http://love-game.net/catplanet.zip Original competition entry: http://love-game.net/catplanet-compo.zip Source: http://love-game.net/catplanetsource.zip
To me it seems like it unnecessarily blows up the amount of IL categories, but we can at least try and see for now if the reset runs get attention.
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)
Looks like a case of the timer not updating visually.
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
It's true, the rules and decisions are not very concise. Not only am I not particularly invested in moderating this game, but also the nature of it makes it a non-trivial task.
