This is the second game developed by Howard Scott Warshaw. In Raiders, Indy needs to collect several items on his way to collect the lost ark.
Starting the Game
On boot, the game starts its own internal stopwatch. This is responsible for spawning certain items in the treasure room at any given time as well as making the sun shine in the map room.
The treasure room items appear in game according to the following timepiece positions:
N - hourglass
NE - ankh
E - chai
SE - hourglass
S - ankh
SW - hourglass
W - chai
NW - ankh
For every 2049 frames that pass, not only does the headpiece spawn in one of the Marketplace baskets for 126 frames, but the timepiece also changes positions.
The 00x8C address stores the ark’s location. For every frame that Indy stands on the forklift elevator, the hex value changes. When the player sends an input to one of the controllers, the value stays frozen throughout the game. The ark location system can be thought of like a slot machine with a predetermined pattern.
For the sake of presentation, this TAS starts almost immediately. For reasons I will touch on shortly, I want for the ark to be at the 15th mesa, so we wait until frame 188 to start. According to the RAM address ark location diagram below, that's the 3rd closest frame.
Considering this is a full run starting on boot, waiting for and collecting the headpiece is slower than simply using the bomb on the right wall.
Mid-Game
I collect the whip, bomb, parachute, two pieces of gold, and the hourglass. Then, I walk to the mesa field and deploy the hourglass to travel to the Black Market.
The Glitches
Isn’t bribing the Black Sheik with the chai faster than having to wait for the hourglass grappling hook to travel all the way around as Indy gets to the bottom of the mesa field? Yes, but if you can get Indy positioned carefully on one of the far side mesas, the game allows you to teleport out of bounds. Though we do walk through several screens, we reach the Black Market faster. Waiting for frame 4098 is now in the past! Another upside is that we can skip 2 extra trips to the treasure room because a third set of gold isn’t needed.
Now it’s time for more technical info!!!
The hex values and mesa locations for address 00x8B remain the same as 00x8C. 00x8B changes when Indy teleports to different mesas using the hourglass or ankh. When leaving the mesa field or other rooms, its value resets to 00 (the 1st, 2nd, and 10th mesa). The ark will never be located at these locations during normal gameplay. The only condition for winning is that Indy must dig into the Well of Souls located under the same mesa assigned during the player’s first registered input on the controller (when 00x8B matches 00x8C).
The game only executes inventory management inputs (item dropping and usage) on every other frame. In the Room of the Shining Light, when Indy uses the whip on one of the dungeon walls and then again after exactly 4 frames, the game immediately sends him falling off the hex 00 mesa. If this bug is performed on virtually any wall or interactive element, such as parts of the nest in the Spider Room (excluding both dungeons in the Room of the Shining Light), Indy gets "sucked" into whatever got whipped, and a grappling hook suddenly appears as if Indy is standing directly in the mesa field. Not only that, but the value of 00x8B starts changing!
Execution and Completing the Game
After collecting the shovel, I immediately use the whip on the dealer to perform the glitch. The game thinks I’m standing on the 15th mesa (0C). I wait a few frames so the grappling hook is "off" the mesa as soon as possible. Then I teleport, perform some more fancy stunts, deploy the parachute, and finish the game like normal. We bypass the ankh, avoid the chai, and no longer travel to a mesa the normal way.
Starting from power on, it takes 3742 frames or
01:02.447 to complete the game..
- After extensive testing, I can say for certain this is the most optimal route that Indy can travel for the baseline category.
- The Guardian might be able to be manipulated even more to send Indy to the left dungeon even faster, but I'm not so sure how.
- Exiting the right dungeon through the top is slightly slower than doing the same on the left. Sometimes the whip likes to avoid wherever Indy is pointing towards and just fly off the handle, so we just wait a single frame.
- I hope you like the little whip graphic left behind inside the mesa. :-)
- What would save a massive chunk of time is finding a way to dig through the dirt pile without purchasing the shovel.
- Massive thanks to Halkun for reverse engineering the source code! Though I didn't consult it for this run, hopefully it can lead to discovering even more game breaking skips.
DrD2k9: This game is the perfect example of why I believe it makes sense for our site to (at least) consider various timing methods for some games.
For as long as I've been involved in TASing, our site has generally used the timing method based on the elapsed duration from power-on until the last necessary input (with some occasional slight variations). From this timing perspective, this submission is the fastest completion of A2600 Raiders of the Lost Ark.
Yet when we consider alternative timing methods (such as ones commonly used in RTA speedrunning) we can be faced with some interesting situations/dilemmas such as the one introduced by this game.
While some would claim that any duration of waiting around on a title screen should be considered part of "gameplay," others do not feel that such a wait should be. From the perspective of general RTA speedrunning "gameplay" rarely begins at power-on and often begins upon pressing start at the title screen or, in some cases, even as late as gaining control of the playable character. So the rules for what would constitute "gameplay" in an RTA setting are somewhat variable from game to game. Even accepting that variability in comparing one game to any other, in a TAS setting, we can still calculate what an equivalent RTA timing would be for whatever game/TAS submitted.
Which brings us to why this game is interesting: While this submission is the fastest (known) way of beating the game from power-on to final input, the amount of time it takes from first taking control of Indy until final input is
3555 frames (3742 total frames - 187 frames from waited on the title screen after power-on before starting/controlling character). In
another run of this game that is willing to wait longer on the title screen, from first taking control of Indy until final input the game can be beaten in
only 2453 frames (6368 total frames - 3915 frames from waited on the title screen after power-on before starting/controlling character). So this submission is actually
not the fastest way to beat the game in regards to actions taken by the player (meaning disregarding the initial wait to start).
So we have two runs of the same game which can arguably make a claim of beating the game the "fastest."
- This submission shows the fastest means of the game so from power-on until final input.
- The other run shows the fastest means of beating the game using one of the classic RTA timing methods (from starting/taking control of the character until final input).
In my opinion, the demonstration of both of these methods in a TAS setting holds value. In other words, it's valuable to know how quickly a game can be beaten from power-on; and it's also just as valuable to know how quickly a game can be beaten from actually starting the game from the title screen, regardless of how long the wait on that title screen may be. For many games, the same TAS would demonstrate both of these "fastests" as waiting on the title screen does not impact the rest of the gameplay. In such cases, we don't need two separate publications. But for those games where the title screen wait does impact the gameplay, such as for the game in this submission, I feel it would be wise for our site to celebrate both runs with separate publications in order to demonstrate and archive the differences in the resulting runs using the contrasting "fastest" approaches.
Given that our Standard class is based on our historical power-on to final input timing method, this submission meets the requirements for our definition of a baseline any% category for this game. Thus, no branch is needed; the other run holds the "RTA timing" branch in our Alternative class.
DrD2k9: Delaying; I received a message from the author that he has a small improvement. So we'll hold off on this publication for now.
