TASVideos

Tool-assisted game movies
When human skills are just not enough

Submission #6825: DrD2k9's GBC Donkey Kong in 54:15.44

Console: Game Boy Color
Game name: Donkey Kong
Game version: JPN/USA v1.0
ROM filename: Donkey Kong (JU) (V1.0) [S][!].gb
Branch:
Emulator: BizHawk 2.4.2
Movie length: 54:15.44
FrameCount: 194828
Re-record count: (unknown)
Author's real name:
Author's nickname: DrD2k9
Submitter: DrD2k9
Submitted at: 2020-07-28 02:22:22
Text last edited at: 2020-08-01 08:59:10
Text last edited by: fsvgm777
Download: Download (34216 bytes)
Status: published
Click to view the actual publication
Submission instructions
Discuss this submission (also rating / voting)
List all submissions by this submitter
List pages on this site that refer to this submission
View submission text history
Back to the submission list
Author's comments and explanations:

Donkey Kong

a.k.a. Donkey Kong '94
This version of Donkey Kong follows the same premise as the original game from the 1980s, in that Mario is tasked with rescuing Pauline from the eponymous Donkey Kong. Besides adding over 90 additional stages to the original 4 stages, this release also introduces many new game-play mechanics which both help and hinder Mario from reaching his goal. Some of these new elements are patterned off concepts from other Mario games including Donkey Kong Jr., SMB, SMB 2 (USA), and SMB 3.

Temp Encode

Game Notes

Where the 1981 Original (and most of its ports) only allowed Mario to complete his quest by running, jumping, climbing ladders, and smashing stuff with hammers. He was hindered by broken ladders, enemies, conveyors, barrels, and holes in the floor. This version adds numerous mechanics which both help and hinder Mario in his quest to save Pauline.
  • Worlds & Stages - First and foremost, the original game only had 4 different stages that repeated (some ports only have 2 stages). This game has 10 themed worlds each with anywhere from 4 to 16 unique stages. None of the stages are repeated through the game.
  • Falling - Falling has been modified. In most ports of the original game, falling even a short distance on a stage (anything greater than jump height) resulted in Mario's death. In this version, typically Mario can fall from one platform to another immediately below it without dying. Specifically if Mario falls too far, he will land on his face and be stunned for a second; if he falls even further, he lands on top of his head and dies. The increased freedom gained from the new fall mechanics are seen throughout the run.
  • Flip Jump - Holding down while jumping allows Mario to jump onto his hands. In this position, Mario can block some projectiles with his feet (which is necessary to obtain barrels to use on DK fights). He can also move horizontally, albeit at a slower pace than normal running.
  • Handspring Jump - Jumping quickly out of the handstand position allows for slightly higher jump and slightly faster horizontal motion than a standard jump.
  • Triple Jump - This jump allows for an even higher elevation jump. To perform, a flip jump is immediately followed by a handspring jump, then when Mario lands he ducks for a moment. During this ducking phase, a third jump can be performed which is the highest intended jump in the game.
  • Back Flip - A higher jump than standard, but not as high as a triple jump. Performed by pressing the opposite direction of movement and immediately pressing the jump button. This mechanic is utilized a lot (and somewhat abused in this run).
  • Hammer Throwing/Catching - While the original game required Mario to wait out the duration of the hammer power-up, this game allows Mario to toss a set of hammers straight up into the air to either discard them or transfer them to a higher position in the stage (assuming he can also get himself up there to catch them before they fall too far down). If Mario initially obtains or catches a hammer with upward momentum, this momentum is preserved.
  • Vine Climbing - Mario is able to climb vines much as DK Jr. does in his own game.
  • Swimming - Mario can swim similar to how he does in SMB1.
  • Temporary Stuff - Throughout the game, there are places where temporary items are utilized. These disappear after a set time.
    • Ladders
    • Platforms
    • Springboards
    • Blocks
  • Tightropes - In some stages there are wires stretched between to locations. Mario can either shimmy his way along these or swing his body around them like a gymnast then fling himself off in a dismount that can project him across the stage or to heights that jumping could not equal.
  • Keys - While there are some stages that mimic the original game in that the goal is to simply reach Pauline, most stages instead require Mario to obtain a key to unlock a locked door as he chases DK and Pauline.
    • Jump to Door - When finishing a stage with a door, Mario triggers the end of the stage when his feet hit the floor along a range of X-positions from one side of the door to the other. When this stage-end is triggered, Mario walks to the door, unlocks, it and runs through. If Mario hits this end trigger at the furthest point possible, it can take longer to walk to the door than if Mario simply jumps over the trigger and lands perfectly at the door.
  • Switches - Switches have various effects and are can be triggered by DK, DK Jr., or Mario himself.
    • Retractable floors
    • Retractable walls
    • Conveyor direction
    • Elevator motion/direction
  • Dangers
    • Spikes/Lava - If Mario is empty handed, these cause instant death. Otherwise, they cause him to drop the item he's carrying and be stunned briefly.
    • Enemies/Projectiles - Various enemies wander around the stages. Many are deadly to contact; some can be stood on top of and even picked up. Some shoot projectiles that kill Mario or cause him to drop things.
    • Thwomps - While faceless in this game, they are effectively the same as those in SMB3. One exception is that Mario can stand atop them.
    • Mushrooms - Mushrooms in this game actually cause Mario to shrink instead of grow (only seen in a cut scene in World 4)
  • Mini-Boss stages - At various checkpoints through the game (typically 1/2, 1/3, or 1/4 of the way through a given world) Mario will have a stage that mimics the classic 'reach Pauline' concept; these don't require obtaining a key.
  • Boss Battles - At the end of each world, Mario must battle it out with DK. In addition to any other hazards present in the stage, DK will hurl barrels at Mario. Mario typically must use a handstand to block these barrels and stop them so they can be picked up and thrown back at DK. Three hits on DK and the stage ends.
    • Occasionally, DK will throw little walking creatures instead of barrels. Mario uses these instead of barrels to defeat DK.
  • The Final Battle - The final stage of the game is a battle between Mario and a GIANT DK (ala King Kong). In this battle, DK must be hit by 6 barrels total. After each two, DK will leave the screen then return; thus at least 3 cycles are necessary to defeat him.
  • Bonus Stages - Thought not seen in this run, bonus stages can occur in all worlds from 1 onward and allow Mario to earn extra lives. They happen after each stage when all three bonus items (Pauline's parasol, purse, and hat) are collected within the stage itself. As this would obviously add unnecessary time, they are avoided. If someone were daring enough to do an All Items branch of this game, these bonus stages would be incorporated.

TAS Notes

  • Emulator used: Ultimately this run was completed on BizHawk 2.4.2, but it has been an ongoing project since probably before v 2.0
  • Game Version Used: USA/JPN v1.0 - This version's glitches are slightly different than v1.1 and movement can be started slightly earlier in some stages.
  • Mode: GBC in GBA mode was used as that's what would be needed to console verify this run (at least to my understanding). Unfortunately we've learned that uninitialized RAM won't allow for console verification...at this time.
  • Objective: Beat the game as fast as possible from starting a blank file to final input to defeat DK
  • Rerecord Count: As this TAS was created using multiple emulator releases over the past few years, The inputs were copied and pasted multiple times across multiple files. Due to this, I don't know the exact rerecord count. As best I can estimate from looking at a few of the files' headers, it would be approximately around 180,000 rerecords. If anything, the actual number is higher.
    • Given that the actual value is unknown, I've set the header in the submitted file to zero.
  • Soft Resets - Soft resets are used at the end of each world (after saving) as it's a faster method to get to the next world's first stage than waiting for the animation that would normally play between worlds.
  • Cut Scenes - Sadly these cannot be skipped.

Glitches Utilized

  • Air Jump - If Mario slides off a platform while crouched going into the 3rd jump of a triple jump, there are a few frames in which he can effectively jump from mid-air. This often breaks the path that developers intended Mario to take through a level.
  • Wall Jump - As with many Mario games, it's possible (though unintended) to wall jump. If Mario's trajectory positions his sub-pixel position correctly where two wall blocks meet, he "lands" and can jump off the wall.
  • Wall Walking - On occasion, there are walls with platforms on top of them. If jumps are performed correctly, it's possible to land on top of the wall, but not on top of the platform. This can sometimes break the developer's intended path through a stage.
  • Key Glitches
    • Throw & Catch - If Mario throws the key upward then jumps (typically back flips) up to the key, he can re-grab the key at the higher elevation. This can sometimes allow Mario to reach platforms higher than he could otherwise jump to if he catches the key at the right time.
    • Back Flip Key Grab - If Mario picks up the key during a back flip various glitches can result. As a side note, this is often the fastest way to pick up the key as well. The following result after back flip key grabs:
      • Double Tumble - When jumping off a ledge then falling far enough to tumble after, the key will stick in its vertical position for a few frames and Mario will be invulnerable. Unfortunately he is unable to climb ladders (as if he is still carrying the key). If a second fall and tumble occurs, the key will freeze in its position and Mario will now be able to move as if he's not carrying the key. Reaching the door in this state will still allow Mario to complete the stage.
        • Tumble Cancel - If Mario throws the key at the right moment just before a tumble after a back flip grab, his tumble animation will be canceled and he'll automatically retrieve the key.
      • BASE Jumping - Normally, if Mario falls too far while holding the key he will drop it. The back flip grab prevents this from happening, and Mario can fall much farther without dropping the key. If Mario lands on the end trigger, he can finish a stage after one of these long falls that would otherwise kill him.
    • Key Riding - If the key is falling and Mario can manage to land on top of the key as it falls, Mario can travel any vertical distance without taking damage. In this state, Mario can pass vertically down through elevator platforms unhindered.
  • Ejection Abuse/Clipping - When an object (including Mario or the Key ) becomes clipped into a solid object, the game ejects the first object vertically. This is used to rapidly transport the key upwards in a stage. It's also used to clip Mario vertically upward and break the developer's intended stage path. When Mario is being ejected, he can still actively move right and left.
    • Sir Shove-a-Lot clipping - One of the enemies will push Mario around. If Mario is one block lower than this enemy and standing on a floor that can normally be jumped upward through, jumping just as the enemy reaches Mario allows Mario to be pushed through the floor breaking developer intended path.
  • Extended Handspring - When a flip jump is performed correctly on a springboard, it allows Mario to jump even higher than he'd normally be able to with a normal jump off the springboard.
  • Walk Through Spikes - Details on this glitch will be explained in the stage they are part of.
  • Out-of-Bounds Boss Stage End (OOB Stage End) - On a couple Boss stages, it's possible to be ejected out of bounds by clipping up through Pauline. This is currently only known to work on 2 stages and requires at least 2 factors:
    • 1) The total time of the three previous stages must fall within in a certain range.
    • 2) The game must have been reset after the previous Mini-boss stage.

Stage-By-Stage Comments (Primarily glitches used, but some other pertinent info as well.)

  • Construction Yard (World 0) - This world is all 'reach Pauline' style stages: remakes of the original 1981 game's 4 stages.
    • 0-1 - Normal movement via back flips
    • 0-2 - Normal movements. The jump to the platform with the hammer is shortened by Mario hitting his head on the burning barrel.
    • 0-3 - Mario catches the edge of the elevator platform after a handspring jump to execute an air jump up to Pauline
    • 0-4 - Normal movements but abuses the newly introduced falling freedom to trigger rivet hit boxes while falling through the air.
  • Big-City (World 1)
    • 1-1 - Wall jump is used to reach the key faster.
    • 1-2 - Wall Jumps.
    • 1-3 - Everything here is normal motion. An interesting hammer duplication glitch occurs (I'm not sure why), but it affects lag. Interestingly, I couldn't beat the level faster NOT duplicating the hammer.
    • 1-4 - Wall jumps break developer's intended path.
    • 1-5 - Normal Movement. This is the first instance of Jumping into the Door, but it's not very obvious.
    • 1-6 - Wall Jumps & Wall Walking
    • 1-7 - Wall Jumps, Wall Walking, Throw & Catch. This is the first obvious instance of Jumping into the Door.
    • 1-8 - Normal movement (and some goofing off)
  • Forest (World 2)
    • 2-1 - Air-Jump and Double Tumble. (minor delay to get a 190 instead of a 191)
    • 2-2 - Ejection Abuse. Air Jump.
    • 2-3 - Abuses poor stage design to break developer's intended path. The temporary ladder is placed under the retractable wall to prevent it from coming down fully and allows Mario to walk through where the developers intended a wall to block him.
    • 2-4 - Extended Handspring. This also demonstrates how Mario won't grab vines during a triple jump. He will normally grab vines during a regular jump or back flip jump.
    • 2-5 - Normal movement.
    • 2-6 - Normal movement. A jump into the end-trigger does not land perfectly at the door. This is done to yield a 140 on the timer instead of 139.
    • 2-7 - Wall Jumps
    • 2-8 - There are two glitches here that involve the spring that DK throws (I don't really understand how either work).
      • 1) Initiating a flip jump at the right moment against the left wall just as DK picks up the spring results in a higher than normal flip into the handstand and places Mario on the upper platform.
      • 2) The spring is somehow involved with the clip through the floor and into the non-climbable ladder which then ejects Mario upward to reach Pauline much faster than intended.
    • 2-9 - BASE Jump to skip intended path.
    • 2-10 - Wall Jumps
    • 2-11 - Normal Movement
    • 2-12 - It is not possible to stop both the 1st and 2nd barrel, thus the second is allowed to leave the stage. The rest is normal movement/battle.
  • Ship (World 3)
    • 3-1 - Normal movement.
    • 3-2 - Wall Jump. Tumble Cancel. Throw & Catch.
    • 3-3 - Sir Shove-a-Lot clip.
    • 3-4 - Air Jump. This stage uses a clip similar to that in 2-8 but this time using a thwomp to clip Mario through a platform instead of the spring. This stage also uses standard clipping and ejection abuse to get up by DK, jump over him, then jump off screen and climb down the ladder to reach Pauline, completely breaking the developer's intended path.
    • 3-5 - Single tumble (only the first of the double tumble glitch).
    • 3-6 - Wall Jump using temporary platform,
    • 3-7 - Wall Jump.
    • 3-8 - Normal movement/battle.
  • Jungle (World 4)
    • 4-1 - BASE Jump
    • 4-2 - Thwomp clip.
    • 4-3 - Wall Jump
    • 4-4 - Wall Jump
    • 4-5 - BASE Jump
    • 4-6 - Throw & Catch
    • 4-7 - Wall Jump
    • 4-8 - Wall Jump. Killing the enemy with the coconut is unavoidable without losing time.
    • 4-9 - Normal (albeit fancy) movement
    • 4-10 - Normal Movement (frogs are used to move vertically as needed)
    • 4-11 - Wall Jumps completely break developer path intent
    • 4-12 - Normal Movement/Battle. Interestingly, I achieve a double kill here; I hit DK for the 3rd hit and fall far enough to die at the same time. However, as the stage end has already been triggered, Mario doesn't die (even though the SFX for him landing on his head plays); and progress to the next stage occurs.
  • Desert (World 5)
    • 5-1 - Normal movement. This stage introduces the Mega-Hammer which is necessary to break some blocks which otherwise hinder progress.
    • 5-2 - Getting the bone throwing skull to cooperate was a pain.
    • 5-3 - Wall Jump.
    • 5-4 - Wall Jump. There is an intentional delay at the end of this stage to set up RNG for better enemy movement in stage 5-6.
    • 5-5 - Walk Through Spikes. In this stage, there is a wall that has a conveyor sitting on top of it with spikes directly on top of them. It's intended for Mario to throw the key onto the conveyor so it goes over to the door while he travels around the long way. However using a back flip into a wall walk followed by holding both down and right, it's possible to glitch the game into thinking Mario is crouching while still allowing him to run side to side. As the game think's Mario is crouching, he's not 'tall' enough to hit the spikes thus he walks right through them. It's unknown exactly why this glitch happens, but it is believed to be connected to both the wall walking position and the conveyor being on top of the wall.
    • 5-6 - This is all normal movement. However, it required the RNG setup from stage 5-4 as well as some frame perfect timing on retrieving the key just before unlocking the door.
    • 5-7 - Double Tumble
    • 5-8 - Normal Movement
    • 5-9 - Wall Jump
    • 5-10 - Ejection Abuse, Wall Jump
    • 5-11 - Normal Movement. A temporary block is used to block a retractable wall.
    • 5-12 - The pharaoh heads are used to hit DK. After DK throws them and they land, they sit still for a moment then begin moving. Their hitbox does not populate until they begin crawling around. Thus, if Mario picks them up before they move, they will be ineffective in hitting DK as they have no hitbox; they instead just pass right through him. Thus apparent delays in picking up the heads is for this reason.
  • Airplane (World 6)
    • 6-1 - Wall Jump. BASE Jump.
    • 6-2 - BASE Jump.
    • 6-3 - BASE Jump.
    • 6-4 - Wall Jump.
    • 6-5 - Wall Jump.
    • 6-6 - Wall Jump. Tumble Cancel
    • 6-7 - Wall Jump. Double Tumble
    • 6-8 - Normal Movement.
  • Iceberg (World 7)
  • As with other video games with ice levels, this world introduces ice physics for running and stopping/sliding.
    • 7-1 - Wall Jump. There is an unfortunate wait at the beginning of this level waiting for the Fireball to melt the impassable ice so Mario can progress through. I just goof off during this time.
    • 7-2 - Wall Jump. Tumble Cancel
    • 7-3 - Normal Movements. This is the first stage with a hidden doorway.
    • 7-4 - Ejection/Clipping Abuse. This stages uses the Thwomp to lift Mario and a precisely timed jump clips him up through the floor to the end.
    • 7-5 - BASE Jump.
    • 7-6 - Ejection/Clipping Abuse. Wall Jump.
    • 7-7 - Pseudo Double tumble; falling into the water after the first tumble acts as a second tumble and gives Mario free movement. This conveniently stops the key right near the door. Then placing a temporary ladder under the door tricks the game into thinking there's a platform under it and allows the end stage trigger to be triggered even though Mario continues to fall through the screen.
    • 7-8 - Wall Jump
    • A soft reset is performed after 7-8 in order to enable the OOB End Stage glitch for 7-12
    • 7-9 - Normal Movement
    • 7-10 - This stage uses a weird movement glitch that's a combination of a Triple Jump and a Wall Jump by 'landing' on the spike's platform to crouch into the 3rd jump. There is a few second long delay at the end of this stage so that the timer value is appropriate to execute the OOB End Stage glitch in 7-12. I probably should have goofed off a bit, but didn't. It may be possible to add something in without affecting future stages, but I'm not sure. RNG may be affected if Mario's movement triggers a random event.
    • 7-11 - Wall Jump. Tumble Cancel.
    • 7-12 - This is our first OOB End Stage glitch. To trigger the glitch, the two requirements must be met, then Mario must manage to clip out of bounds through Pauline and finally move while off screen to certain coordinate location. This then somehow triggers the end of the stage even without attacking DK. This is MUCH faster than battling him. The time saved is enough that the delays necessary to set up this glitch don't negate the benefit. SIDE NOTE: I do have a version of the run that does not use these OOB glitches. However, RNG is different for stages from 7-9 onward in that run.
  • Rocky-Valley (World 8)
  • This is the only World with 16 stages.
    • 8-1 - Normal Movement
    • 8-2 - Throw & Catch.
    • 8-3 - Throw & Catch.
    • 8-4 - Wall Jump
    • 8-5 - Wall Jump. Double Tumble. Wall Walk. Pseudo Double Tumble - Similar to how the water yields the same effect as a 2nd tumble in 7-7, This stage uses the hammer to replace the 2nd tumble and get Mario into a free movement state that can still unlock the door.
    • 8-6 - Ejection/Clipping Abuse. Key Riding.
    • 8-7 - Key Riding. Throw & Catch.
    • 8-8 - The fastest way to the middle platform is jumping from a rolling boulder. Thus there is a goof-off wait at the beginning of the stage while waiting for the boulder to arrive.
    • 8-9 - Ejection/Clipping abuse.
    • 8-10 - Key riding.
    • 8-11 - Wall Jump
    • 8-12 - Normal movement.
    • A soft reset is performed after 8-12 in order to enable the OOB End Stage glitch for 8-16
    • 8-13 - Throw & Catch
    • 8-14 - Air Jumps. Wall Jumps. Ejection/Clipping Abuse.
    • 8-15 - Air Jumps. Wall Jumps. Ejection/Clipping Abuse. There is a very minor but intentional delay so that the timer value is appropriate to execute the OOB End Stage glitch in 8-16.
    • 8-16 - This is the 2nd OOB End Stage glitch.
  • Tower (World 9)
  • With the exceptions of 9-4 and 9-8, every other stage in this world is a classic 'get to Pauline' style stage.
    • 9-1 - Normal Movement
    • 9-2 - Normal Movement
    • 9-3 - Wall Jumps
    • 9-4 - This stage is a remake of the classic key stage from the original Donkey Kong Jr. There is a delay after inserting the final key before Mario is transported to the top of the screen. It's possible to die during this time, so I chose to dive for the ground and catch the rope near the bottom. This fall does not delay the transfer up.
    • 9-5 - This looks like normal motion, but some of the jumps are done from the bottom of a block not the top...meaning they're effectively wall jumps.
    • 9-6 - Normal Movement
    • 9-7 - Normal Movement
    • 9-8 - Normal Battle - Slight delay to yield better RNG for the Final Battle.
  • Final Battle - There is a lot of down time here, so I tried to goof off a bit. I'm sure I could have done more fancy stuff...but I'm not the best at goofing off during down time. The final barrel is thrown as early as possible.

Comparison to Humans

The current RTA world record for this game is 1:00:01.466 or approximately 215,107 frames by PTO. However, RTA runs are timed is a bit different than TAS timing. RTA runs start timing on file selection and stop time at the last hit on GIANT DK. Using the RTA timing method, this submission's time would be 0:54:16.624 or 194,510 frames -- a difference of about 5:45

A five and a three-quarter minute difference over the course of a 1 hour run is a significant difference, but the difference becomes even more meaningful when one considers the number of frames in which inputs by the player have no affect on the game time: (we'll call these Worthless Frames for shorthand)
Counting (from file selection to the final throw at Giant DK) all the Worthless Frames yields 123,393 frames. These Worthless Frames are comprised of cut scenes, lag between stages, etc. This value should be relatively equal between both a human and a TAS with a few frames of leeway.
Subtracting the Worthless Frames from the total frames yields the number of frames that the player is actually impacting the run's time (We'll call these Game-play Frames).

  Side note: I actually counted lag within the stages toward Game-Play Frames not toward Worthless Frames as that lag is affected by input and what's happening
  within the stage and thus the number of these may likely be different than what they would be for a human.
If we consider only Game-Play Frames, this TAS has 71,118 frames; or a time of 19:50.708
This time is the effective amount of time that the TAS "plays" game elements.
Looking at only Game-Play Frames for human RTA yields 91,714 frames or a time of 25:35.541.

Breaking down this comparison:
When only comparing the total time, this TAS beats the game in about 90.42% the total time it takes a human.
But if the Worthless Frames are discounted from both the TAS time and human RTA time and only the Game-Play Frames are considered; the TAS actually beats the game in about 77.54% of the time it takes a human speedrunner to accomplish the same feat.

Potential Improvements

  • OOB End Stage Glitches: The two OOB glitches used are the only two currently known to work.
    • It's been theorized that other DK battle stages may also have this glitch, but none are known at this time. It's not completely understood why this glitch works the way it does nor how the timer and reset are involved; it's only known that they're necessary. If someone were able to decipher WHY these happen (specifically with regards to the timer value), then investigation into whether or not other battle stages may be beaten this way could be accomplished more easily. Brute force trial-and-error may prove the glitch to work in other battle stages, but the time it would require to perform all the necessary permutations via brute force would be insane.
  • General RNG Info: The sequence of RNG values is only advanced when a random event occurs. The calculation to determine the next value has been deciphered from the game code and is somewhat complicated. Putting the calculation here in the submission notes would be mostly pointless, as even knowing what the next value will be tells the player/TASer nothing about what effect the value itself will have. Thus RNG doesn't currently affect TASing beyond watching when it changes and seeing how waiting for a new value affects future stages.
    • It is absolutely possible that differences in RNG will impact enemy movements and stage events in ways that could shorten the overall time of this run. In fact, some of the stages I TASed before introducing the OOB glitches are shorter than the equivalent stages in this TAS due to changes in RNG. Unfortunately, any change made in the game that affects RNG will force a near complete reTAS of all subsequent material through the end of the game.
    • RNG Manipulation: A lot of elements of this game are determined by RNG. While the RNG value itself (and its RAM address) are known. There are very few opportunities to actively manipulate this value. Known ways include:
      • Hard Reset (Power Cycle) - This will effectively reset RNG value to 15 (in BizHawk) at game initialization. (On real hardware it may not always be 15, the reason is not pertinent to this submission but essentially has to do with uninitialized RAM).
      • Soft Reset - This will perform a bitwise AND with 15 on the previous RNG value to yield one of 16 possible values.
      • Waiting - waiting for a random event to occur will advance RNG one value in its natural sequence.
      • Enemy Manipulation - Some enemies call the RNG value for animation purposes and/or for direction of movement. There are a few (but very few) enemies who's animation/movements are determined by Mario's relational position to the enemy. IF one of these enemies also calls RNG for an animation or movement after Mario initiates an interaction, only then the value will be advanced one in the sequence. This is the only known way (besides just waiting) to actively force or restrict an RNG change through game-play actions; forcing the sequence to advance by initiating the interaction or restricting the sequence advance by avoiding the interaction.

I fully expect that with enough study into the RNG and how to control the ideal sequence of values, that this run could be beaten. However, the effort that it would require to do so would be very involved and take quite some time.

Acknowledgements

A huge "Thank you!" goes out to the RTA runners of this game. While I'm the sole author of this TAS, I worked closely with many of them in the DK'94 discord server regarding strategies and theories that would improve the run. The back and forth between myself and them had a major impact on the resulting submission as presented. Specifically, members of that community include PTO, Civel, LudwigVonKoopa, Nardiko, and NullSprite. I'm sure there were others, but I'm blanking on names at the moment (please forgive my awful memory).

Suggested Screenshots

Frame 194887


Memory: ok so like my favorite GameBoy game yeah I'm claiming this.

fsvgm777: Replaced movie file with one that has the correct cycle count.

Memory: Soooooooooooo this movie was absolutely incredible. The key glitches, clips, and wall jumps were all incredible. The boss skips in particular were a huge surprise to me. I made so many noises while watching this TAS that I had never made while watching a TAS before (SHUT UP SAMSARA). The audience loved it too.

Accepting to Moons but I wouldn't be surprised to see this reach Stars.

fsvgm777: Processing (after Heroes of the Lance).

Memory: Replacing file with a 663 frame improvement.

DrD2k9: In light of updated bk2 file: Updated the values in "Comparison to Humans", Updated Suggested Screenshot frame number and image.

fsvgm777: Processing (for real this time).


Similar submissions (by title and categories where applicable):