Submission #9795: RockyGaming4725 & almostmatt1's DOOM Final Doom: The Plutonia Experiment in 10:42.40

Final Doom: The Plutonia Experiment is an FPS created by Dario & Milo Casali and published by iD Software in 1996. This TAS uses the Ultra-Violence difficulty setting and is completed in the UV-Speed category, Dooms equivalent to any%. Item collection, kill count and secret exploration is irrelevant and the secret maps can be skipped. This TAS was created by RockyGaming4725 & almostmatt1.

The TAS was built frame-by-frame using XDRE, with each TASer using their own personal version of the tool with unique alterations applied. XDRE produces standard vanilla-compatible .lmp files (with the addition of a small info footer in the demo). DSDA-Doom was also heavily used for brute forcing.

This TAS was made with the conventions of the classic Doom speedrunning scene in mind, so tricks and glitches are allowed and utilised but cheat codes are not. Usage of engines that support behaviour not available in the original game, such as using GZDoom to jump and aim up/down, is considered invalid as they do not replicate vanilla gameplay. IGT is the primary concern, not RTA. For this reason we did not use the smallest number of tics possible in the intermission screens between maps, instead deliberately leaving a small amount of time to view the map times more easily.

This run of 8:54 is an improvement of 3:01 over the previous Plutonia TAS: 11:55 by ClumsyDoomer & 38_ViTa_38 (primarily ClumsyDoomer) from 2017. Here's a table comparing this run to that run and, just for fun, a comparison to the current non-TAS record of 19:08 by Zero-Master. Decimals are included in per-map times, but for overall times Doom disregards the decimal - E.g. 9.97 seconds and 9.00 seconds are each just 9 seconds. All runs skip the secret maps 31 & 32. Format is time (total time) for the first demo, and time (total time) (difference) for the others.

This submission text tries focusing on the technical aspects of the run and not the long and difficult journey we took to make it happen, but briefly: this demo took 490 cumulative hours of effort (110 hours were spent just reworking large sections or whole maps that we later found improvements for) over 1 year, 10 months and 15 days and is by far the largest TAS project that either of us have been involved with. That 490 hours number does not include a further massive (but unfortunately unknown) number of hours that were spent brute forcing and generally experimenting, just the time spent purely on actively and purposefully building, which we made an effort to track. The original Doomworld submission contains a whole different set of comments than the below with a bit more personality that you can find here, if you wish: https://dsdarchive.com/files/demos/plutonia/89186/30plx854.zip

This demo has played back perfectly with every vanilla compatible source port we have tested it on but we have experienced inconsistent crashing upon playback in the original .exe when a memory overflow trick is used at Map 11. We have not been able to definitely determine the cause of this, and why it sometimes does and sometimes doesn't work. This issue initially prevented us from submitting this run to TASVideos, but we are submitting it after being encouraged to do so by feos. Here is a video of RockyGaming4725 successfully playing the run with the original executable in 86box: https://youtu.be/Gv8uTWylCxs?si=P586_jYBM2pXUBK2

Finally, in the video provided for this submission there is a small custom message at the end. This was purely added for fun for the video encode and doesn't affect the demo file or its vanilla compatibility. It also uses a custom soundtrack. If you wish to watch the run with the OST, a link to this is in the video YouTube description.

Doom allows lots of control over player movement. You can face 256 angles, move forward or backward, and strafe left or right in each frame. Running and strafing isn’t a binary value and instead occurs in thrust values of 0 to 50. Running forward at full speed results in an MF50 (MF = move forward) input, while strafing to the left at half speed would result in a SL25 (SL = strafe left) input.

Distance is measured in game units. Doom uses fix-point maths for momentum and co-ordinates with the decimal component of units having 16 bits of precision, meaning within a single unit the player can exist in a position from x.0 to x.65535. For reference: Doomguy is 32x32 units in size so in just the space that the player occupies there are 4,398,046,511,104 different potential positions.

The Doom engine calculates movement separately along its X & Y axes, consequently considering the player to simultaneously have momentum and movement in 2 cardinal directions, causing diagonal running to be faster. This means a 41% higher top speed, faster acceleration, and reaching speed thresholds that facilitate certain tricks faster than if the player moved in a single direction. It also provides more versatility in being able to reach very precise positions; running in one direction provides 25,856 possible input combinations whereas running and strafing provides 2,611,456 input combinations. A massive number of input combinations were constantly brute forced for specific tricks.

If close enough to a wall and running alongside it in either a north or east direction, after a certain momentum threshold is exceeded movement per frame is doubled while contact with the wall is maintained. It’s important to distinguish that Dooms stored *momentum value* for the player is not doubled, only the distance that the player moves per tic. This is why it may appear that Doomguy suffers a large speed decrease when a wallrun finishes – the momentum value did not suffer, the wallrun effect simply stopped. Because the wallrun only occurs after the player exceeds the speed threshold of roughly 13.6 units/tic, the exact frame where contact is made with the wall must be optimised. If you reach the wall too soon you won’t be in as far a position as possible before beginning the wallrun, too late and you miss an opportunity to wallrun for at least one frame. Movement must be adjusted when approaching and contacting the wall to not kill precious momentum. You can either get as close as possible to the wall while technically not touching it on the frame preceding the beginning of the wallrun, or (skipping the technical details) you can run into the wall JUST aggressively enough that you maintain momentum in the wallrun direction while also getting half of a wallrun boost for that particular frame. The latter approach relies on having a momentum value exceeding the 13.6-ish units/tic wallrun threshold on the contact tic, and is typically both harder and superior, though this is situational. Because wallrunning is (almost always) only possible while travelling north and east it is not done in many cases where a casual observer may think it is obvious to do so. The player does not run perfectly straight forward in the direction they appear to be looking. There is a very slight offset that causes them to be turned ever so slightly to the left, which causes problems for wallrunning. If the player is looking what appears to be perfectly north and the wall is to their left (to the west of the player) and they move north, they are very slightly trying to move towards the wall on each frame, ensuring contact with the wall is maintained. However if they move north with the wall to their right (to the east of the player), this slight offset means that the player is actually constantly trying to move away from the wall, meaning that movement values needs to be slightly adjusted to ensure they're staying in contact with the wall. This very slight adjustment very slightly compromises what would otherwise be running in a perfectly straight direction, making these wallruns both harder and *very slightly* slower.

This differs from straight wallrunning in that you don’t simply get in a good position, pick a good angle and run in a straight line. When running into diagonal walls Doom has very inconsistent behaviour including killing, maintaining, increasing or totally inverting (called an ‘elastic collision’, which can also occur outside of diagonal wallrunning) your momentum, and also providing a wallrun effect. In a controlled TAS environment we can ensure that increasing momentum and providing a wallrunning effect occurs as frequently as possible, but this is amongst the most difficult and time consuming aspects of Doom TASing to optimise. In a portion of diagonal wallrunning lasting for several frames, movement must be altered and adjusted for every single frame to maximise the outcome on that frame, which is made more complicated by the fact that a sub-optimal outcome on an earlier frame may happen to give the player the exact position and momentum values to get a far superior outcome on later frames. Optimisation therefore cannot be done in a sequential frame-by-frame manner, it must be done in sections of frames considered as a group. Brute forcing was extensively used for this.

In certain situations, often when opening doors, you can preserve your forward momentum value by running parallel to the wall perpendicular to, and to the side of, that door. Like wallrunning, this requires getting into a very close position against that surface. Having preserved forward momentum the player can travel through the open door at a high speed on the very first frame that the door is open enough to move through. This effect is often mixed with the wallrun trick: on the very first frame that the player can move through the door they do so not only at a high speed but with double the distance travelled per frame, because they are moving alongside a straight wall. Without momentum preservation tricks momentum is typically killed when colliding with a wall or a door, but it is worth noting that running against an enemy, barrel, or level decoration such as a torch prevents the player from moving in the direction towards the obstruction but also effortlessly maintains momentum in that direction.

There is a distinction between getting “very close” and “perfectly close” to a wall, the latter being called a .00000 trick in reference to the .00000 units of space between the player and the wall. It’s a little complicated: - If the player is in this position they can accumulate momentum both alongside and perpendicular to the wall. - If the wall coordinates do not overlay the lines of the 128x128 unit blockmap grid, the effect is only possible when the wall is to the south or east of the player. There is a momentum cap of 14.5 units/frame. If the player is stationary and exceeds this on either axis, momentum for both axes is reduced to 0. If the player is moving and exceeds this on either axis, momentum for the direction the player is NOT travelling is reduced to 0. There is a small value window between 13.6-ish and 14.5 units/frame where momentum is high enough to facilitate wallrunning (again, only if travelling north or east) but low enough to maintain momentum in both directions. - If the wall coordinates DO overlay the lines of the blockmap grid, the effect is possible no matter which direction the wall is from the player, and there is no longer a momentum cap. This effect is often used to move quickly in a certain direction once the player moves past a wall and is especially powerful when used in conjunction with a wallrun. An example is the wall to the right of the player while ascending the stairs in Map 1: momentum is maintained towards the south while they wallrun very quickly in an east direction. Finally, something rare: While wallrunning is typically only possible north and east, if there is a wall that happens to overlap the blockmap grid, you can get a .00000 position against it and accumulate more momentum than is typically possible, allowing the player to wallrun west and south. This occurs once in this run for a west wallrun in map 28. We also had a brief south wallrun in an old iteration of map 23, but a routing change made this obsolete.

Explosions from rockets give a significant speed boost allowing for general speedups and occasional skips/sequence breaks. The closer you are to the explosion, the more speed is given but the more damage the player takes. All damage boosts affect the players speed but rocket boosts are different in the sheer amount that they give you and in that they can be readily self-inflicted. Because rocket boosts exist, health itself becomes a resource and planning the optimal relationship between boosting to gain speed and deviating from the path as little as possible to grab extra health becomes a routing consideration.

“Things” include enemies, barrels, and obstructing map decorations. Running into walls generally kills your momentum but this is not the case with things: you are prevented from moving towards them but can move alongside them, including wallrunning against them if your momentum is high enough. This differs from wallrunning in that no precise position is necessary, you can just run into them and it generally works itself out – however, getting as close as possible and maximising speed and distance still requires manual optimisation.

The player is a 32x32 box that is always axis aligned, and they can move through gaps that are exactly 32 units in size. This is possible, but surprisingly very difficult, outside of a TAS. However, a TAS can accomplish this instantly and without a momentum loss. This is used to sequence break maps. Because a squeeze glide necessarily places you in a position perfectly close to a wall it often happens at the same time as .00000 tricks for momentum preservation and wallrunning, so after brute forcing the exact inputs needed for the glide we immediately have to consider how to optimise the movement often before we have even left the gap.

Dooms terminology for clipping out of the map. It’s rare that this can happen and rarer still that it’s useful. The height of sectors affects the height of the void sections adjacent to those sectors which often leads to player obstructions while out of bounds so it’s rare that we can access anything useful while here, and it’s very rare and difficult to re-enter a map from the void. This is used just once in this run and happens to also include a map re-entry. It is made possible by a combination of two previously mentioned tricks, diagonal wallrunning and the fact that things obstruct you but don’t kill your momentum. It is explained in the map 22 comments.

This is mechanically very similar to void glides. Certain walls in the game, often referred to as "fences", mechanically differ in that they don't kill your momentum upon collision, they allow you to maintain it. Occasionally you can wedge yourself between a diagonal wall and a fence, be kept in place by the fence, accumulate momentum against the diagonal wall, and clip through the fence.

It’s possible to activate some switches while being almost perfectly perpendicular to them, with a slight offset. The game is inconsistent in the distance that is required and whether walls obstruct the switch presses, and is dependent on the direction of the press and whether the space between the player and the switch is separated by one of the blockmap grid lines.

Affects projectile spread, projectile damage (player & monster), monster movement, whether monsters attack you, which tics monsters perform their line of sight check to look for the player and enemy death animation offsets. RNG is pseudo-random. The RNG number can be one of 256 values, and when the game needs something random to happen it checks this number, does some random stuff and iterates it. If the map starts on the same RNG number the same gameplay will sync perfectly, with a small exception: Revenant projectiles are either player-tracking or not and this depends on whether the total tic number is even or odd (plus a small RNG effect to potentially flip this) instead of being purely based on the RNG number. This means it’s possible to complete a map, go back to a previous map and change some things, ensure the RNG number is correct when entering the original map for it to sync perfectly, and the map will sync UP UNTIL a Revenant projectile happens to no longer have the original homing properties, causing a desync. This is easily solved by adjusting the number of frames in the intermission screen which otherwise has absolutely no effect on RNG or gameplay. Within maps RNG can be primarily manipulated by firing on different frames – this changes the RNG value whether or not the projectile hits something that sustains damage, which is why the player will occasionally fire at the wall or punch the air in front of them, however the RNG value will be changed to something different depending on whether the projectile causes damage or not. RNG can also be altered by slightly adjusting the player movement but this is typically a last resort because it compromises our attempt at optimising movement. RNG can be manipulated to have enemies move out of our way and miss their attacks, but can also be manipulated to ensure they DO attack us.

Jumping is impossible in Doom but the Arch-Vile attack launches the player in the air which can be used to clear large gaps and ascend to otherwise inaccessible places. This can be used for major sequence breaks. RNG has to be manipulated to optimise the timing of when the Arch-Vile begins to attack the player, and there is a considerable delay between the Arch-Vile targeting the player and the attack actually occurring.

The Intercepts Overflow or “all-ghosts” bug is the result of a memory overflow caused by a hitscan attack crossing too many linedefs/things at once. Normally this requires too many linedefs/things to be in place at once to be a concern, but an *extremely rare* rounding error can occur in Dooms fixed point arithmetic causing the code to enumerate the same intercepts several times, causing the bug to sometimes occur in unexpected places with relatively few linedefs/things. When this bug is triggered linedef effects no longer work: walls no longer obstruct the player, but switches and walk-over triggers can also no longer be activated, which are how the overwhelming majority of maps end. Thankfully the effects of this bug are removed entirely when the following map is initialised, so this bugged state does not persist past the map it occurs in. This bug is used in Map 11, read those notes for more. Small note from almostmatt1: I’ve played and TASed this game for thousands of hours over many years and the only two times I’ve encountered this bug occurred on the same afternoon in two totally separate maps. Crazy unlikely coincidence.

You can sometimes grab items on the other side of walls and on high ledges you typically can’t reach. You can do this by being very close to the wall and having a high enough momentum value that the game calculates where you WOULD be if there wasn’t an obstruction in the way, and if it sees that you would have intercepted the item (and if the difference in height between the player and item isn’t too large), the player attains the item.

The player can turn while mid-air but cannot affect their momentum or movement direction by entering movement commands. Firing in different directions is possible while not compromising the movement of the player.

Linedefs are all the lines in the game that separate sectors, whether they be solid walls, doors, the points of changes in texture in an otherwise plain piece of floor, or occasionally walk-over lines that trigger something to happen. We can occasionally deliberately pass over these lines while leaving them unactivated to avoid certain things like temporarily being locked into certain areas. It involves being close to them on the frame preceding moving over it and having a high enough momentum that the game believes we didn’t actually contact the line while moving over it. This behaves differently in different directions - sometimes it’s so easy that it happens accidentally and speedrunners actually alter their movement to DECREASE the odds of it happening, and sometimes it’s so hard that it requires a wallrun or rocket boost to be possible at all.

The player can face 256 angles, but our movement options allow us to face 4 different directions while retaining the same movement values. For example, facing north and moving forward = facing east and moving left = facing south and moving backwards = facing west and moving right. Some variation of this exists for any combination of running, strafing and turning inputs. Assuming we don’t need to face a certain direction on a given frame to fire a projectile or activate a switch, we can use this fact to our advantage to just make the demo visually nicer: because at any point in time we can be facing 4 different directions while retaining equivalent movement, throughout the demo we considered which of the 4 directions to face the player so that the most interesting part of the gameplay was being viewed. It also allowed us to significantly mitigate the visually jarring effect of constantly sharply turning. Unfortunately 4 of the 256 turning angles don’t transpose correctly, meaning that altering the player angle sometimes causes a very slight change in player movement, large enough to cause a desync. This meant that on top of the tedious and time consuming process of manually transposing all gameplay for visual smoothness we had to constantly monitor our movement values to ensure we weren’t subtly introducing a desync. In addition, since movement values cannot be altered while mid-air (outside of colliding with walls and taking damage), we can use these periods of time to smooth out our turning angles over several frames for visual smoothness at no compromise to movement optimisation. This was done for every period of mid-air gameplay in the run.

When entering a teleport the player is stuck for 18 frames before they are able to move, but if they take damage they become "unstuck" and are able to instantly move. The player must be attacked by an enemy or damage themselves with a rocket for this to happen. RNG manipulation is needed for the former and fine-tuning is needed for the latter: it doesn't matter how much damage is taken, only that some is taken, so when self-inflicting damage with a rocket to become unstuck we try to have the rocket explosion as far from the player as possible while still touching us.

If the player dies, they can still technically end the level: their corpse can cross over a level-exiting linedef, or (not used in this run) it is possible to trigger an exit switch on the exact frame that the player health becomes 0. The game happily progresses you to the next map, with a twist: aside from RNG being affected by the previous map the game starts you on the next map as though you're starting a new game. Health is reset to 100, armour to 0, all ammo to 0 except 50 bullets, and you keep only your pistol. It is often so beneficial to death exit a map that it is worth these drawbacks. When the player dies their height also becomes 0, meaning they can suddenly pass through very small gaps that a living player cannot pass through. This means that death exits occasionally facilitate unique map exits by allowing us access to areas normally inaccessible.

"Infinite height" is inconsistent. For colliding with/being obstructed by things, you can think of the enemy as being an infinitely tall rectangular prism: you cannot travel under flying enemies or over the top of ground-dwelling enemies, you will collide with them as though they are right in front of you. But for attacking enemies, your hitscan projectiles, plasma balls, BFG balls and BFG tracers can only attack the enemy if they're appropriate visible and not excessively higher or lower than the player - but punching, using the chainsaw, and rocket explosions are infinitely tall attacks, meaning you can walk up to a Cacodemon that is far too high to see or shoot and instead punch it. All projectiles can travel over/under enemies, meaning rockets themselves cannot target enemies that are too high/low to see, but if an explosion happens close enough to them on the X and Y axes, the Z axis difference between the enemy and the explosion is irrelevant - for this, you can think of the monster as being an infinitely tall rectangular prism and the explosion shape as being an infinitely tall cylinder instead of a sphere. While infinitely tall enemies obstruct you from moving under or over them, this does mean that the player can thingrun alongside them no matter the Z coordinate difference. This is used in map 23 for the yellow keygrab. Infinite height affects switches. If you're appropriately close to the switch on the X/Y axis, the height difference between the player and the switch does not matter. Infinite height does NOT apply to grabbing items. If an item is appropriately close on the X/Y axis but too high or low you won't be able to grab it. This is why the yellow key grab on map 23 needed a jump to grab it from higher up instead of just running into the platform it is on from the ground below.

The community doesn't really have a name for this one, so I'm going with this. Normally movement inputs are entered, the game determines how much additional thrust to apply to the player based on these inputs and applies it, a top speed clip is applied, the game performs it's movements and checks, and finally an amount of friction is applied to the player. This friction value is 0.90625 (29/32) of the players current speed, meaning that the momentum value is 90.625% of the distance travelled for that frame (assuming no additional factors like wallrunning, damage taken, etc). This means that on the following tic the thrust value is added to this reduced momentum value. However if the player steps off of a ledge/platform/stair or the like, this final step does not occur: On the final tic of contact with the ground and every mid-air tic, friction is not applied and momentum is equal to distance travelled. This means that when the player regains contact with the ground, the gathered thrust value is added to this now higher-than-normal momentum value, meaning the player moves faster than if they had remained in contact with the ground. In maps 28 and 29 we can abuse this by constantly running on and off of a ledge to push our movement speed far higher than it normally would be able to reach. Because a top speed clip is still applied we still cannot use this to exceed the momentum cap of 30 units/tic (the only thing that can exceed this is interactions with diagonal walls) but we can still go much faster than normal.

Wallruns, optimised collisions, momentum preservation tricks (and the precise timing of those things) and RNG manipulation is so prevalent throughout the run that it would be extremely excessive to mention every instance of it. It’s not an exaggeration to say that it was virtually ALWAYS a consideration and was often considered in conjunction with other more obvious tricks. Therefore an explanation of most maps would mostly just be repeating the above, but below are some notes for a few maps notably deserving a bit more of an explanation (not to say that these are necessarily the most standout or high effort maps completed).

Map 07 - Caughtyard
This map is unique in that a lift lowers after all Mancubus enemies have been killed. When each one dies, on one certain frame of their death animation the game tests if all other Mancubi on the map are dead, and if so the lift begins to lower. It's the games way of enforcing a "Kill all enemies to proceed" effect. The monster death animation has a random slight offset which means the time following the Mancubus death can slightly vary, meaning we needed to try to adjust RNG so this was appropriately timed while also adjusting RNG to maximise rocket damage. The Mancubus killed at 5.03 seconds, the fourth-last one killed, was the one whose death animation evaluated whether all other Mancubi were killed. The final Mancubus was killed at 6.49 seconds, and the evaluation was successfully performed on the very next frame at 6.51 seconds. Timing this while juggling the other RNG considerations was hell and turned this map into a major roadblock. It also meant that rocket placement was particularly difficult because we tried applying damage to multiple enemies at the same time with each explosion where possible. We had to contend with the random movement of monsters and the randomised damage of the rockets, and the fact that we had to be close enough to the Mancubi while firing the final rocket so that it contacted it as soon as possible.

Map 11 - Hunted
This map is normally a tedious and uneventful maze that can contain some general movement optimisation but is otherwise not notable. However it is one of two maps in the official Doom releases where the all-ghosts bug can usefully be triggered. By moving into a very specific position and firing in a specific angle at some ammunition pickups, the bug is triggered and walls stop obstructing the player, meaning we can run straight to one of the two exits on this map: an area that has a sector effect that ends the map as soon as the players health value is low enough. All-ghosts causes linedef effects stop working but sector effects continue to function, so the map can still be exited. On the previous map we do a lot of rocket boosting, which has a dual-purpose: it speeds us up a lot for that map but also gives us low enough health that on the very first frame of reaching the special Map 11 exit sector, the map instantly ends. The effects of the bug are cleared as soon as the following map is reached.

Map 12 - Speed
This is quite cool in that it has a simultaneous Arch-Vile Jump + Rocket Boost + Death Exit, but is also notable for another reason: if the previous map was exited normally it's actually possible to save an additional second on this map. We can get Tele Unstuck by taking damage, allowing us to turn around and fire a rocket at the wall while getting the Arch-Vile jump sooner enough to save a second. The problem is that after our health was deliberately lowered for Map 11, we don't have enough health to survive getting tele unstuck. This isn't a time loss because 30+ seconds were saved in the previous map at the cost of a single second here, but it's still interesting.

Map 20 - The Death Domain
Small note from almostmatt1: since this is such an extremely clever and out-of-the-box route I just wanted to take the time to shout-out 38_ViTa_38 for discovering it.

Map 22 - Impossible Mission
The Void Glide! By wedging ourselves between a diagonal wall and an enemy, the following behaviour loops: the monster stops us from moving and prevents our momentum from being killed. By running against the diagonal wall, the game calculates what to do about our momentum, makes a mistake and gives us too much, then adds this to our current momentum value despite us not actually moving. When enough momentum is gathered the game places us from one side of the wall to the other in a single frame. The re-entry involves being obstructed by a small piece of map geometry while outside the map and running in a direction where the game things we're constantly colliding over and over with the INTERNAL part of the diagonal wall inside the map, eventually accumulating enough momentum that we clip back into the map. We pop back in right at the exit, which we can take immediately.

Map 23 - Tombstone
This map briefly features a cool utilisation of infinite height: while travelling from the raising platform to the yellow key during the yellow key grab, we perform a precise thingrun against an enemy that is on the ground. Despite them being quite a bit below us, Dooms infinite height allows us to thingrun against what is essentially an infinitely tall diagonal prism above the enemy. Paired with fairly precise positioning beforehand, this lets us cover just enough extra distance to be able to Item Bump the Yellow Key.

Map 26 - Bunker
This map features an interesting example of thingrunning and item bumping. We kill the Arachnotron enemy and its corpse (which can at this point be travelled through and does not obstruct us) travels some distance towards the trench that we then fall into. However, the corpse of the enemy is too large to actually fall into the gap so it overhangs it until it comes into contact with the far wall. Its size means it remains accessible to an Arch Vile, who runs over to resurrect it from the high ledge. As soon as the Arch Vile resurrects it, its corpse becomes solid and we can thingrun against it, allowing us to maintain momentum towards the wall AND get a wallrun effect in that direction. In combination with a rocket boost we accumulate enough momentum to grab the key through the wall, saving several seconds.

Map 27 - Anti-Christ
This map contains almost 30 seconds of gameplay where we cannot do anything to speed up the map progression. A switch is triggered at 12.20 seconds and we then need to wait until 40.09 seconds until a platform is raised enough for us to access the final area. We cannot Arch-Vile Jump or Rocket Boost to this area, we must wait. During this time we gather resources. Movement during these sections is not strictly as fast as can be, and is in fact sometimes deliberately slower than is possible to make the sections a little more smooth and watchable, but this does not compromise the final time whatsoever since we are forced to wait anyway.

Map 28 - The Sewers
This map contains a very rare example of west wallrunning at around 57 seconds into the map. By getting into a .00000 position against a blockmap aligned north wall we can accumulate north and west momentum, and the lack of the momentum constraint typically present for .00000 tricks allows us to wallrun in a west direction. At one point a mechanically similar and equally rare south wallrun was present in Map 23. This occurred in an obsoleted route and was consequently scrapped.

Plutonia UV-Speed is an extremely broken run: Only 3/30 maps (15, 28 and 29) are completed with more-or-less the intended route without a major skip or sequence break. Despite it skipping so much of the intended progression of the game, it manages to retain much of its appeal and charm in a way that is sacrificed in many other games with TAS runs that exploit the game this much. We hope you enjoy watching it.

eien86: Claiming for judging.

eien86: When decades of collective knowledge and the titanic effort of obsessed individuals meet, these types of movies are produced. An absolute masterpiece, and a shining addition to the site's library.

Plutonia is my favorite IWad, having played it for hundreds of hours and knowing all its secrets, I still had to watch some levels several times and read its notes to understand exactly what happened there. Some tricks here are absolute novelties and can leave even the casual viewer gobsmacked.

Privileged to be the one accepting this as improvement over [3337] DOOM Final Doom: The Plutonia Experiment by Clumsydoomer & 38_ViTa_38 in 12:53.28