140 is a minimalistic rhythm platformer released in 2013 by Jeppe Carlsen. It's a bit of an atmospheric experience; you may want to consider playing it before watching this run.
General notes
Category choice
The game has 8 levels in total. The third is
considered by the developer to be the end of the main game, with the 4th being a bonus level. The final four levels are the same as the first four, except they are vertically mirrored, have inverted colors, and dying in them sends the player back to the level hub. This run completes all 4 non-mirrored levels, which constitute practically all of the unique content of the game. It is equivalent to a real-time "all levels" run, and the first 3 levels of the run are equivalent to an "any%" run. I've chosen to name this run's branch the same way as the RTA category, however, it is technically a misnomer and a different branch name may be more apt.
Game versions
Although they have no official numbering or naming, informally, there exist three major versions of 140, often called by their release years: 2013, 2015 and 2017. The first includes three levels (and 3 mirrored levels) and some exclusive bugs. The 2015 version is not available on PC, only on consoles, and hasn't been explored much, but is overall considered to be the least useful for speedrunning as it changes the game physics in unfavorable ways. The newest version of the game added the bonus level and features a new physics system, which fixed some 2013 version quirks but introduced new ones - most importantly edge jumps, which save significant time over the course of the run. As the fastest version and the one with the most content, the 2017 version was chosen for this run. More specifically, the first patch of the 2017 version was used, as it has a collision bug which can be abused to save time on boss 2 and which a later patch fixed.
Framerate
140 is a Unity game which does a lot of its gameplay-related calculations in Update methods (which are intended for framerate-dependent updates) as opposed to FixedUpdate (the framerate-independent counterparts). This means that, although the developer intends for the game to support arbitrary, potentially varying framerates, the game does act differently (sometimes drastically differently) if the framerate is changed. There is potential to minimally or severely exploit this behavior, however, I did not personally explore this avenue much, as such tricks might make for a worse viewing experience (at very low framerates), open the road for time saves that are not strictly gameplay-related, and possibly call into question whether the game is even being played in an intended/"natural" environment. LibTAS in its current state also seemingly cannot override the game's ~60.36 fps cap caused by vertical sync. This run plays the whole game at 60fps except for 1 frame at ~48.4fps in 1-5 and 1 frame at 58fps before the 2nd boss (both explained later).
Timing
Many of 140's gameplay elements are tied to the game's music. Notably, this includes all the panel activations, boss hits and level 2 boss charges which come at the end of every "sublevel". Runs are most conveniently compared by beats rather than frames/seconds - especially when comparing to RTA runs, which use a special timer that aims to nullify hardware differences and strays from actual real time. One beat lasts 3/7 of a second (can you figure out the meaning of the game's name‽), so almost all improvements necessarily come in multiples of 3/7s (imagine a bus etc.). The only exceptions are the panel before the first boss, which can activate on each quarter of a beat (3/28 of a second), and the 4th boss, if aiming to end input early.
The one universal trick
...which doesn't actually have an agreed upon name 🤦♂️. I'll be referring to it as an edge jump. If the player passes a corner just close enough while not being too close to properly land, a "fake" landing will occur, where coyote time starts but vertical speed is maintained. This allows for a coyote jump that is much lower than usual. This is used all throughout the run to save time as well as sometimes to save no time at all.
Sublevels (segments between orb activations which make up levels) are listed by their conventional names from the RTA community. Timestamps are also provided, as well as a comparison to the best sublevel time achieved by speedrunners (if different). Less interesting sublevels are not given these privileges.
1-4 (2:00)
An edge jump lets the orb be caught just before it moves too low down, saving time over having to wait for its next upwards pulse. This skip is called "groom skip" by the speedrun community - don't ask why.
1-5 (2:54)
As opposed to the other ones in the game, the panel at the end of this sublevel can be activated on any 1/4th of a beat. It's not too surprising, then, to find out that the best known time for this level is very close to being improvable. However, I was unable to do it. Even with some minor framerate manipulation to optimize the boundaries of frames, I was unable to save the ~1/10th of a second here. Frustratingly, prior attempts with a 140-specific TAS tool did lead to a timesave, but that tool incorrectly assumed close to perfect 1/60s music timer granularity. In actuality, this timer is not so ideal and in this case only increments in multiples of about 0.213s. Thus, this quirk alone seems to be the difference between saving time and not, which should give an idea of just how close it is. It may even be possible to save this quarter beat by waiting and losing multiple full beats, since an attempt at a different time would have differently aligned music timer increments.
Note that for one frame the framerate is set to 48.3992 fps. This is a leftover from me experimenting with manipulating the framerate and a genuine mistake of mine which I did not notice prior to submitting the movie, but also one that does not significantly affect the run.
1-boss & 2-0 (4:25)
This boss wiggles. And of course, the wiggles are random. And of course, this affects hitboxes too, which in turn affect whether or not you can get the fastest time here. Luckily, this is the first point of the run where randomness affects gameplay, and practically the only point where it matters for saving time. The run's starting system time was changed by trial and error until good wiggles were had.
2-1 (5:14; 8 beats saved)
The timesave here is very simple - the jumps are executed quickly enough to catch the orb sooner than usual. There is very little leeway. The orb's dance happens every 8 beats, hence the duration of the timesave.
2-3 (6:44)
An edge catch is used near the middle of the level to skip some intended waiting. This can also be done with a normal coyote jump, but that's significantly less fun. There is also a very fancy precise drop through deactivated horizontal static bars towards the end. It doesn't actually make the orb start dancing any sooner than otherwise. Oh well.
2-boss (9:16)
This boss is notable for its LGBT rep.
3-0 (10:45; 4 beats saved?)
The first patch of the 2017 version has a bug where colliding with multiple walls causes the player to be snapped to all of them in turn, even if an earlier snap moves the player out of range. The order the walls get processed is always changing and hard to predict, but is in turn easy to manipulate with trial and error. In this run, the framerate was lowered to 58fps for one frame just before the boss to get the desired collision order.
After the boss, two walls on the left and right side start moving towards the center of the tunnel. These moving walls are different from the two stationary walls present since the end of the boss fight, which continue to exist during the closing in process. With the player against the right side, and collision with the moving wall happening before collision with the stationary wall, the player will be snapped to the moving wall and then the stationary wall every frame, ending up with no net movement. Eventually the player will fully enter the moving wall and get clipped up, saving some time.
It's arguable whether or not this saves 4 beats over the RTA sum of best. This trick was actually
discovered years ago in a speedrun but ignored / forgotten about since then.
3-1 (11:05; 1 beat saved)
Similarly to 2-1, the improvement here comes from movement optimization. An edge catch is used here to skip needing to go back and forth across the bridge (
video showcasing the intended solution and other strategies). It's called "mill skip" - don't ask why. Uniquely, no part of this sublevel is tied to the beat of the music besides the orb panel, which is probably a good gameplay decision given the music that plays here.
3-3 (12:26; 1 beat saved)
Another time save from movement optimization. As opposed to 2-1 and 3-1, this time save may be possible to get in real-time. However, it was not known about until this TAS was made.
3-4 (13:09)
As with 1-5, this level is close to being improvable. So close, in fact, that it can be completed faster in the 2013 version, with its subtly different mechanics. However, despite my best efforts, I was not able to make it happen.
4-2 (17:49)
This sublevel looks innocent enough, but the final movement needs to be very precise in order to get the earliest activation. The optimal time here eluded the real-time community for some time.
4-3 & 4-4 (18:34; 7 beats lost)
4-3 is the only known sublevel whose panel can be entirely skipped, using a slightly precise edge jump. This saves significant time, not only thanks to skipping the activation animation, but also because the orb can be carried over to a later panel, in the end skipping a ~20 second detour to collect the final orb of the game. The downside is it skips some cool gameplay and music :( .
At the end, some time is lost juggling some orbs...
4-5 (20:23; 8 beats saved)
...to save more time than was lost when picking up the orb that was carried over!
The previous best strategy can be seen
here. In this case, the first jump pad activation happens too soon and can't be used. However, an orb can be repositioned such that it's just barely possible to use the jump pad immediately, collect the orb, and land on the following platform after gravity switches back to normal.
It's important to understand the behavior of the two orbs in this section of the run. The white orb (i.e. with a white border) initially mirrors the player's horizontal movement, but after being picked up and put down at least once, it centers itself above the pit. The black orb (i.e. with a black border) remains wherever it is dropped. It's apparent that the black orb can be picked up from further right than the white orb ever could be. It turns out that because of this, the timesave only works with the black orb.
To fully optimize the position of the black orb, it needs to be lagging behind the player a fair distance to the right (requiring some player movement to the right), and it needs to be dropped when the player is as far right as possible (requiring the white orb to be stationary above the center of its pit). All of this explains why three orb swaps and some seemingly suboptimal movement are needed.
Total
In total, 15 beats were saved (11 excluding 3-0).
Thanks to
- the 140 speedrunning community. As is often the case, this TAS is largely a collection of strategies found over many years by real-time speedrunners, without whom this run wouldn't have been nearly as fast!
- Spikestuff, without whom I wouldn't have known the game works with libTAS, and who made an initial run through part of the game.
Info Teddy: I just needed to dump with software rendering, it works now.
- This syncs on the specified version (
-app 242820 -depot 242824 -manifest 4541605642527131830). Note that the hash of 140Linux.x86 doesn't seem to have changed between versions, so libTAS doesn't complain about a different hash if you happen to run it on the latest version by mistake.
- Never fast-forward, otherwise it will desync.
- Dump with software rendering, otherwise the dump will be a black screen.
This run beats all known records. There is an
RTA record on SRC that appears to be faster, but that's only because it completes the levels out of order and ends time on the last input. This run completes the levels in order, so the time spent during a certain cutscene counts against it that isn't counted in the RTA run due to RTA putting it last. If both runs are timed to include the time of the last cutscene, this run is 22:32 and the RTA run is 23:07, so this clearly beats it. (Only gameplay is counted towards optimality, so other factors like cutscene time or swapping level order shouldn't change it.)
A beautifully played run, apologies for the delay. Accepting to Standard.
