(Link to video)
EDIT: The rerecord count should be 40365 according to the lsnes message window when the movie is loaded, but shows up as just 1 for some reason.

Details

  • Emulator used: lsnes rr2-β17
  • Aims for fastest time
  • Manipulates luck
  • Takes damage to save time
  • Abuses programming errors
  • Finishes with suspiciously high item collection percentage
  • Saves the animals?

cpadolf's comments

Recently a set of discoveries in the Super Metroid speedrunning community involving the fabled Space/Time beam led some runners to beat the current any% TAS, obviously something had to be done about that. This new TAS beats the current any% TAS by 23446 frames, or about 6.5 minutes (thereby turning it into a low% run instead of an any% run), and finishes with an ingame time of about 06:15 (although it's displayed as 00:05, more on that later). This substantial improvement comes from using an entirely new route and a new way of finishing the game involving arbitrary code execution, a phenomenon that seems to become more and more common in the TAS communtiy. As an aside, with the timing used for runs in the real time speedrunning community this run is about 12:30.
The point of the route is to get to Gold Torizo as fast as possible and use the so called "GT Code" which instantly gives Samus most of her upgrades and a lot of ammo, enabling the glitching that takes place afterwards. There are basically two routes for doing this, both of which were fully run through and optimized. The first one is to go to Kraid in order to receive the Varia Suit that will take you through norfair and LN without having to collect a bunch of energy tanks. This is the one that was used by Saturn in his GT code run, and is used by the real time speedrunners (minus the hi-jump boots which can be skipped with some tricky kago balling and walljumping during the lava dive before LN). The second one is to skip out on Kraid and instead use the somewhat unknown and never before (to my knowledge) constructively used pause glitch that keeps Samus from dying as long as the game is constantly being paused. The second option turned out to be faster by about 30 seconds despite the game only being able to run for about 1 second per 2 seconds of paused time.
In order to make it all the way to GT with the pause abuse a reserve tank had to be collected as Samus has to have at least 1 energy when riding on an elevator to keep from dying, and to refill on energy before using the PB in the Gold Pirate room in LN as the game can't be paused after a PB has been placed. Because of the time saved by avoiding an extra pause a lot of extra drops were farmed and damage avoided throughout the run in order to minimize the amount of pauses. An interesting side effect of the pause glitch is that the game clock stops running while Samus health is 0, which makes the ingame clock about 20 seconds lower than it should be by the point that GT is reached, therefore displaying a 00:05 at the end instead of 00:06.
With that I'll leave it over to amaurea and total to get into the more technical stuff of the glitching in the run.

amaureas comments

Some of the first TASes of Super Metroid made use of a glitched beam combination called the "Murder beam", which was activated by shooting a charged shot to the left with all the beams equipped, even the incompatible Plasma and Spazer beams. That combination results in a sort of area-of-effect damage that keeps damaging nearby enemies forever, and was used in the Mother Brain fight until it was discovered that it was faster to just shoot optimally charged normal beams.
Since then, no glitched beams have been used in TASes here, though two other non-crashing beam combinations were known: The zero range, zero-damage, rapid-fire "chainsaw beam", and the seriously glitched space-time beam (uncharged plasma, spazer and ice), which could bring the bosses back to life, retile the rooms, reset items, or trigger the escape sequence. But despite the known potential of the space-time beam it was not used here, possibly due to it being emulated differently by the previous generation of snes emulators. Its most powerful effects may have been thought to be emulation errors.
This TAS uses not only the space-time beam, but also another beam previously thought to be useless: The charged space-time beam. After performing a trace log while firing the various glitched beam combinations, I found that out of the 8 possible glitched beams, the three known beams (murder, chainsaw and space-time) jumped to ROM data, while the remaining 5 all jump to RAM. That is why the former beams were reliable enough to use, and why the latter beams would always lead to a crash: RAM contents are variable, but rarely contain sequences of bytes that when interpreted as machine code do anything safe. In particular, more than half of all RAM values are 0, which when interpreted as an instruction means BRK, aka "hang forever".
But on the other side, while ROM is unchangable, the player can to some extent control the content of RAM. Many of the glitched beams jump to interesting RAM locations, but the one used in this TAS (but not the only potentially useful one) is the charged space-time beam, which jumps to ram location 0x900a0a, where we can find Samus' super missile count, followed by her power bomb count and selected item etc. These are all under the player's control, and have a large enough range that it is possible to perform some interesting operations.
For example, a super missile count of 32 corresponds to the instruction JSR (jump to subroutine), which lets us jump to a location of our choice based on the power bomb count. The most promising targets are the gamepad auto-read registers at location 0x4218 to 0x421f, which contain the current button presses of four gamepads, effectively giving us 8 consecutive bytes which we can freely choose, and which we can update every frame. Reaching these registers would be enough to let us execute arbitrary code, and take total control over the game.
However, both the super missile and power bomb counts are 2-byte variables, and what forms the address to jump to is the second byte of the super missile count and the first byte of the power bomb count. Jumping to 0x4218 using JSR would require 0x18 in the second byte of super missiles, and 0x42 in the first byte of power bombs, for a total of 6176 super missiles and 66 power bombs. Which would take a while to get. So we can't jump there directly. With reasonable ammunition counts, we can hope to jump to addresses 0x0000, 0x0100, 0x0200, 0x0300, ..., 0x3200. That's a lot to choose from, but most of them are hard to influence and contain large stretches of repetetive bytes, such as tile maps etc. But at least two of these are suitable: 0x0400 (OAM data), and 0x0b00 (position and scroll-related variables). The former is what I used in this demonstration video, but it is quite fickle, and requires the right enemies at the right position in the room. The second one I had given up on after almost making it work, because I thought Samus' relative screen position could never get much larger than 256, which would not get me the bytes I needed:
     b00 height       stand=(15,ORA,A),jump=(13,ORA,A),aimdown (0a,bad),crouch=(10,BPL,nop)
     b01 00
     b02 coltype      L=BRK, R=ORA, U=COP, D=ORA, so R or D are OK,  though both modify A.
     b03 00
     b04 x_screenrel low  practially any value
     b05 x_screenrel high nonzero only if Samus is off-screen
     b06 y_screenrel low  typically between 2c and c0
     b07 y_screenrel high
The first 4 bytes here are not useable, but can be made equivalent to harmless operations that bring us to 0x0b04. There we have 4 bytes in a row related to the Samus' screen-relative x and y position. If these could take any value, then we could use this to perform a jump to 0x4218. But when I first investigated this, I thought both these scroll values would be between 0 and 255 (i.e. Samus inside the screen) or at least not values much higher than that. That would make 0x0b05 and 0x0b06 zero, as indicated in the excerpt from my notes above, and would limit us to the same kind of restricted jump that brought us here in the first place.
But total pointed out that I had forgotten out-of-bounds travel (OOB), where it is possible to get almost arbitrarily far outside the screen. That made this method an easy and reliable (to a TASer anyway) method: Position Samus such that her screen-relative position is (x,y) = (0x1182,0x??37), where the ??-part is irrelevant. This corresponds to the machine code
     $90/0B04 82 11 37    BRL $3711
Which finally brings us to the gamepad auto-read registers! At that point we have total control over the game: We could for example set up a jump from the last register to the first one, trapping the game inside this 8-byte register range (this is what I did in my OAM example). But total found a more efficient setup, as he will explain.
See the Super Metroid game resources page for a more detailed analysis of the glitched beams.
Potential improvements: While we investigated the other glitched beams, we were not exhaustive, and they may be usable for gaining control earlier. This includes the standard murder beam, if fired in another direction than left. It might also be possible to gain control without the use of glitched beams at all, by triggering a glitched door transition while out of bounds (for example using the X-ray gltich). I've discussed this with PJBoy, but we didn't find a concrete way of realizing this. To execute larger amounts of arbitrary code, it will be useful to use the manual gamepad registers instead, as the current method only lets us execute about 2-3 instructions per frame.

total's comments

Now that we've finally managed to direct the game to execute code from controller registers using the methods explained by amaurea we need to make sure that we can stay in control for long enough to change the game state and do any other modifications that might be needed to keep the game from crashing. This can be done as explained earlier by crafting a loop that keeps code execution within the controller registers but in this case there's a slightly more efficient method using the games own programming against it.
So what we can do now is to overwrite the function pointer in memory for the charged space-time beam (the one that right now points to 0x0a0a where our first entry point is) with 0x4218. This has the effect that for the following frames as long as the space-time beam projectile still exists, when the game runs code to update it, it will no longer be using the chain of super missile and power bomb count and positional requirements but instead helpfully enter the controller registers as a subroutine. This gives us plenty of controllable bytes each frame since we only need one byte to return control back to the game.
Below is the final five frames of meaningful input using four controllers and some quick notes on what they do (the 0-3 buttons are extra bits that can be set, but does not represent a button on the controller):
   ...Su...A.L.0..3|....ud...XL.0...|B...ud.r.X....2.|.Ys......XLR0.2. 
   LDA #$4218
   STA $0C68
   PLY
   RTS
As explained above, this is our first chance to run our own code and we'll use it right away to overwrite the function pointer so the game will keep calling into the controller registers no matter our ammo or position. Before returning back to the game we'll also have to clean up the stack so we return back to the right place.
   ..s..dl.A.L.0..3|....u..rA..R0...|B...ud.r........|.........XL..... 
   LDA #$26
   STA $0998
   RTS
This sets 0x0998 in RAM to 0x26 which changes the gamestate and tells the game that we've just finished it, and it will now start a fadeout into the ending.
   B.......A.L.0..3|BY.Su.....L....3|B...udlr........|.Ys......XLR012.
   LDA #$80
   STA $7ED821
   RTS
Since we still have a few frames to work with while the game is fading out, there's some small details we can do while we're waiting for the ending to start. So why not be nice and make sure our animal friends make it out safely.
   BY..udlrA.L.0..3|....u..rAX..0...|B...ud.r...R..2.|.........XL..... 
   LDA #$12CF
   STA $09C8
   RTS
And this increases our missile count to get a nice item completion percent.
   .Y......A..R01..|................|.Ys.........01..|................ 
   STZ $0C40
   RTS
Before returning full control to the game, we delete the charged space-time beam projectile to make sure the game does not try to call into the controller registers again.
It should be noted that instead of overwriting the function for the beam handling code, there are a few other pointers that can be overwritten to keep in control of the game that will persist through door transitions and does not need an active fired beam projectile. It is not used in this case since it would require quite a bit more code to setup and was not needed in this case where we just need to end the game.
As mentioned before this run also uses the uncharged space-time beam a few times. First to exit Golden Torizo's room without fighting him and also resetting the super missile in the room, and finally to create a door transition block that will place us out-of-bounds in the next room which is needed to be able to manipulate the screen-relative position enough to be able to execute code.
The way this works is that when you fire the uncharged space-time beam, the game jumps into the middle of a routine in ROM that does a memory copy into RAM. But since we're entering that routine from the wrong place and with non-intended values in the X and Y registers, this routine will copy a whole lot more data than it is supposed to. It will end up overwriting data for events, items collected, bosses defeated and so on which is what makes it possible to collect the same super missile pack three times. An even more destructive thing happens as well though, it will also overwrite room data with "garbage" blocks where some of these will be valid door transition blocks. We abuse this by using these to first escape GT's room and fight, and last to quickly get out-of-bounds in the room left of GT's room where we can finally get into position to fire the charged space-time beam and ending the game.

Thanks to

Big thanks to all of the Super Metroid speedrunning community for their recent efforts in glitching the game, as well as all the people actively contributing to the TASvideos forum thread. Special thanks to hero of the day for suggesting the use of the pause glitch to skip going to kraid.

Noxxa: Judging.
Noxxa: This is a quite unique run. It uses a debug code to aid in reaching its end goal faster, which is arbitrary code execution. We have had varying precedents on runs using cheat codes that were accepted, and that were rejected. These cases all differ in multiple fields, including whether the debug code or cheat code is conventionally accessible in gameplay, whether they are intentionally put in the game for the player to use, and how much of an impact they have on gameplay. But in the end, this just turns out to be an entirely unique case. This is because the run does not just clear the game like a normal playthrough - it takes over control of the game code to trigger the ending.
The movie rules contain a rule against cheat codes, so if the rules are to be followed, this run would be rejected. However, we need to look at the spirit of the rule here. Normally, cheat codes are used to make gameplay easier - make it simpler to finish the game. However, in this case, the run is not ordinarily "finishing the game". It does not actually make "gameplay" easier, because what it actually affects here can barely be called "gameplay". In odd instances such as these, where the game is not being conventionally played or finished, we can make an exception to this rule.
So putting aside the use of the debug code, we are met with a nice, entertaining and well-received run which finishes the game fast. Accepting for Moons. This run will not obsolete any previous run - the current any% ("X-Ray glitch") seems to hold enough merit on its own to keep publication, as it is a more "true" run which completes the game without arbitrary code execution or use of debug codes.
Ilari: Processing.

1 2
5 6
Skilled player (1430)
Joined: 7/15/2007
Posts: 1468
Location: Sweden
I don't really think it changes anything for runs that aim for ingame time. Becuse you don't actually reduce ingame time, you just trick the ingame clock. There's still an adress for "ingame time" that keeps running while your HP is 0. I still think aiming primarily for ingame time in the 100% run was the corerct choice for example, and don't think that not using the pause glitch goes against the goal set up in that run. Using the pause glitch to manipulate the clock would possibly add more than a minute of actual ingame time even though the clock would be lower.
Agare Bagare Kopparslagare
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
OP wrote:
An interesting side effect of the pause glitch is that the game clock stops running while Samus health is 0
Btw, this is a good reason why "fastest in-game time" should be removed as a valid branch. Why? Because the "fastest" run would get Samus' health to 0 as fast as possible, and then just use the pause-glitch throughout the run. The run would take ages to complete, but the in-game timer would not advance. Thus it would be a definite word-record... that takes hours and hours to finish.
Joined: 2/19/2007
Posts: 424
Location: UK
Warp: Unless one excludes the undead pause trick from the category. The in-game tases are in the moon tier, meaning that people found them to be entertaining. A tas that used the pause trick would probably not be found to be entertaining, and so couldn't obsolete them. The cleanest and simplest solution is therefore to just disallow the pause trick in in-game category TASes. Why would you want to remove entertaining runs?
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
amaurea wrote:
Warp: Unless one excludes the undead pause trick from the category. The in-game tases are in the moon tier, meaning that people found them to be entertaining. A tas that used the pause trick would probably not be found to be entertaining, and so couldn't obsolete them. The cleanest and simplest solution is therefore to just disallow the pause trick in in-game category TASes. Why would you want to remove entertaining runs?
If the category is "fastest in-game time", then a submission that has a lower in-game time completion ought to obsolete it. Disallowing some glitches (pause-glitching) while allowing others (arbitrary code execution) is arbitrary, subjective and inconsistent. (Hey, if it were up to me, both of those would be disallowed. But speaking from a pragmatic point of view, why allow one but not the other?)
Patashu
He/Him
Joined: 10/2/2005
Posts: 3999
Mike Tyson's Punch Out!! and sequels use in game time in preference to real game time, and disallow glitches that cause the clock to freeze (such as the 'clock stopping glitch').
My Chiptune music, made in Famitracker: http://soundcloud.com/patashu My twitch. I stream mostly shmups & rhythm games http://twitch.tv/patashu My youtube, again shmups and rhythm games and misc stuff: http://youtube.com/user/patashu
Tub
Joined: 6/25/2005
Posts: 1377
amaurea wrote:
Unless one excludes the undead pause trick from the category.
It's not just the undead pause trick (I like the name!) that is excluded from the list of tricks done in ingame-runs. There are a few others that can shave off a few frames of ingame time at the expense of a lot of frames of realtime. Like equipping/unequipping highjump-boots or beams in certain situations. Possibly exiting/re-entering a room to reset enemies for drops (the current runs don't contain much farming, but it'd be a viable option in some hacks). So far, the ingame-TASers have chosen to avoid using these tricks to the extreme, because they knew that a fully optimized ingame-run wouldn't be as entertaining. But as a result, the category has always been somewhat ill-defined, and I believe any of the ingame-runs could be made faster simply by making it look bad.
m00
Eszik
He/Him
Joined: 2/9/2014
Posts: 163
That's funny to see that‚ during the cheat codes debate‚ nobody mentioned Super Ghouls 'n Ghosts run‚ which actually uses a cheat code.(http://tasvideos.org/1296M.html) So why was the movie accepted ? Because without this code‚ the run would have been really boring. So‚ imo‚ it's the same for this run. And I'm really happy that it was published :)
I problably made mistakes, sorry for my bad English, I'm French :v
Skilled player (1703)
Joined: 9/17/2009
Posts: 4952
Location: ̶C̶a̶n̶a̶d̶a̶ "Kanatah"
Tub wrote:
So far, the ingame-TASers have chosen to avoid using these tricks to the extreme, because they knew that a fully optimized ingame-run wouldn't be as entertaining. But as a result, the category has always been somewhat ill-defined, and I believe any of the ingame-runs could be made faster simply by making it look bad.
Someone should try abusing these tricks to the extreme and upload the run on April fools or something and see what happens. ;)
Skilled player (1430)
Joined: 7/15/2007
Posts: 1468
Location: Sweden
My idea for an April Fools submission had always been a "true RBO" run that kills MB first, then Ridley, GT, Draygon, Botwoon, Phantoon, Crcomire, Kraid, Spore Spwan, bomb Torizo and finally Ridley on Ceres with the help of Space/Time beam. The problem is that it would be an insane amount of work (probably longer than the 100% run) for a joke submission. Not entirely sure that it's possible to escape after killing MB either but it definitely might be with Space/Time.
Agare Bagare Kopparslagare
Patashu
He/Him
Joined: 10/2/2005
Posts: 3999
It should kill Mother Brain phase 2 before phase 1 :)
My Chiptune music, made in Famitracker: http://soundcloud.com/patashu My twitch. I stream mostly shmups & rhythm games http://twitch.tv/patashu My youtube, again shmups and rhythm games and misc stuff: http://youtube.com/user/patashu
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
Cpadolf wrote:
My idea for an April Fools submission had always been a "true RBO" run that kills MB first, then Ridley, GT, Draygon, Botwoon, Phantoon, Crcomire, Kraid, Spore Spwan, bomb Torizo and finally Ridley on Ceres with the help of Space/Time beam. The problem is that it would be an insane amount of work (probably longer than the 100% run) for a joke submission. Not entirely sure that it's possible to escape after killing MB either but it definitely might be with Space/Time.
Actually if well executed, it could be a genuine publication (at least if we allow yet another branch.)
Editor
Joined: 11/3/2013
Posts: 506
Warp wrote:
Actually if well executed, it could be a genuine publication (at least if we allow yet another branch.)
Of course it would be accepted, it's Super Metroid! Though in true Super Metroid tradition, we'd have to have a fair amount of pointless bickering first.
Joined: 7/2/2007
Posts: 3960
Cpadolf wrote:
My idea for an April Fools submission had always been a "true RBO" run that kills MB first, then Ridley, GT, Draygon, Botwoon, Phantoon, Crcomire, Kraid, Spore Spwan, bomb Torizo and finally Ridley on Ceres with the help of Space/Time beam. The problem is that it would be an insane amount of work (probably longer than the 100% run) for a joke submission. Not entirely sure that it's possible to escape after killing MB either but it definitely might be with Space/Time.
I'm pretty sure that Space/Time can toggle the bit that determines if the planet is exploding. At least, I'm nearly positive I've seen a run that "wins" by triggering the escape sequence without ever going to Tourian; if you can set the explosion bit to 1, then you can probably set it to 0 as well by triggering the glitch in different circumstances. The place where I did the reset-items/bosses glitch on console is the side area from the Old Tourian Escape Shaft (where you have to freeze some monsters, then run over them to charge a shinespark). Since you'd have to do space/time anyway to stop the planet from blowing up, you might as well reset the items at the same time.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Player (38)
Joined: 1/22/2014
Posts: 38
Location: Sweden
Derakon wrote:
I'm pretty sure that Space/Time can toggle the bit that determines if the planet is exploding. At least, I'm nearly positive I've seen a run that "wins" by triggering the escape sequence without ever going to Tourian; if you can set the explosion bit to 1, then you can probably set it to 0 as well by triggering the glitch in different circumstances. The place where I did the reset-items/bosses glitch on console is the side area from the Old Tourian Escape Shaft (where you have to freeze some monsters, then run over them to charge a shinespark). Since you'd have to do space/time anyway to stop the planet from blowing up, you might as well reset the items at the same time.
Actually, just triggering space-time in pretty much any place or any way will reset the items and also disable the planet explosion sequence since it will overwrite those bits with 0 in most cases. There's a quite specific way you need to use space-time to turn it back on though. I'm not sure if that will deactivate the timer though, so it's possible that you will have to use space-time to escape the room after killing MB before the timer is set.
Joined: 7/2/2007
Posts: 3960
Ah, okay. That makes sense in hindsight. Thanks for the correction.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Player (38)
Joined: 1/22/2014
Posts: 38
Location: Sweden
I do think doing a real RBO run would be cool though. I was actually thinking about a similar idea recently where we'd use arbitrary code execution to just chain the boss fights together in a big reverse boss rush, ending with bomb torizo. And when finally leaving his room you'd end up at the ship with the planet exploding or something like it.
Skilled player (1430)
Joined: 7/15/2007
Posts: 1468
Location: Sweden
That would certainly be pretty cool. Anyway it seems to be possible to escape MB after killing her in one of two ways depending on when you consider her to be dead. You can trigger Space/Time directly after her HP hitting 0 in her final form to escape the room and then work your way backward through Tourian. But if you only consider her dead after the death animation and the timer being set, you'd have to charge Space/Time and then switch to a missile to store the charge to be able to use it after you get Hyper beam, then trigger the door out of the room and finally save warp back to ceres in order to get out of Tourian/get rid of the timer.
Agare Bagare Kopparslagare
Joined: 2/19/2007
Posts: 424
Location: UK
Are we talking about a non ACE RBO here? Otherwise, there aren't any restrictions on being able to shoot the beam in the mother brain battle. You just shoot the charged space-time beam somewhere (probably right after you get the plasma beam), use that to get full control and make the game call your code every frame. From that point on you can make anything happen whenever you want. So you can escape from the mother brain battle at any moment, no shooting required.
Skilled player (1430)
Joined: 7/15/2007
Posts: 1468
Location: Sweden
Yeah I meant without ACE.
Agare Bagare Kopparslagare
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
total wrote:
I do think doing a real RBO run would be cool though. I was actually thinking about a similar idea recently where we'd use arbitrary code execution to
Please no. That would just ruin the whole idea.
Senior Moderator
Joined: 8/4/2005
Posts: 5769
Location: Away
Acheron86 wrote:
I think the spirit of this rule was made to avoid people creating runs where technical precision in managing elements like health, enemy damage, and other mechanical factors could be nullified with cheat codes that would remove a large factor of what makes TASing unique. I don't think the rule was made to preclude a route that makes the current real-time run faster than the TAS run would be without it.
It's the obvious part, i.e. "is TASing like cheating". A typical cheat code, or Gameshark, or anything else silly like that offends the most in this respect by the simple virtue of being 1) widely known, 2) easily accessible, and 3) not requiring any TAS-exclusive features. The less obvious part is that, regardless of rules and methods involved, abusing a feature that provides the player character with unlimited or otherwise endgame-worthy resources at a subjectively early point where for us the viewers it would interfere with the progression of the game—the character's visible effort of dealing with its obstacles. Just like with real movies, we actually get a lot more entertainment out of seeing how the character is developing and being pushed to their limits than seeing how there is neither development nor actual limits. It's the limits that give shape to everything in the first place! They make us emotionally connect to the onscreen action, and where there is no limits, there can be no such connection. Unlike a cheat code, stuff like ACE, memory corruption, and accessing hidden game-breaking debug features—i.e. completely ignoring in-game limits—at least get geek points for being ingenious and unexpected, but entertainment-wise they roughly amount to Luke Skywalker asking Obi-Wan to teach him how to use the Force, and then promptly killing Darth Vader with a lightsaber in the next ten minutes of the original Star Wars. Cheapening the experience is what it's called. I, for one, enjoy it a lot more when I see the awesomeness of an in-game character develop, not come "for free". This run's main (and only?) saving grace is that it ends at pretty much the same moment the "free" power comes, and before that comes some pretty hardcore "development".
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
You make good points. Many people here seem to think that cheat codes are ok if they are executed in a way not intended by the developers, or by abusing a glitch, or even simply in a manner that's "harder" than the intended manner (ie. via a key sequence that has been programmed into the game). I cannot comprehend the logic behind this. The point is not how easy the cheat code is to execute. The point is what the cheat code does. It doesn't matter how the cheat code is executed. Abusing cheat codes, or outright "soft-gamesharking" the game via glitches, feels more like circumventing the spirit of the rule, its original purpose. It was interesting the first few times it was achieved, but since it has steadily become more and more frequent as new glitches are being discovered, I have grown a great distaste towards the technique. This is not to say that we couldn't have them on the site at all. It can be useful to kind of document and archive all the ways that a game can be broken. However, once those start obsoleting the more "genuine" (in a sense) playthroughs, which are then dropped off completely, that's where I personally draw the line. It kills the fun in watching the game being played by a perfect being for me.
Joined: 8/23/2008
Posts: 417
moozooh wrote:
The less obvious part is that, regardless of rules and methods involved, abusing a feature that provides the player character with unlimited or otherwise endgame-worthy resources at a subjectively early point where for us the viewers it would interfere with the progression of the game—the character's visible effort of dealing with its obstacles. Just like with real movies, we actually get a lot more entertainment out of seeing how the character is developing and being pushed to their limits than seeing how there is neither development nor actual limits. It's the limits that give shape to everything in the first place! They make us emotionally connect to the onscreen action, and where there is no limits, there can be no such connection.
Would you say maybe it'd be a good line in the sand to judge a cheat code based on how it's accessed? Button input on a title screen and the Golden Torizo debug code may both have similar results, but in this particular TAS the code is used in a manner that is effectively TAS-only due to the route. More importantly, even in a console playthrough, a serious speedrun that uses this cheat will still display adept execution in the setup process. I don't want to get stuck on that aspect of the code, but it's almost more like an earned bonus, given the difficulty of getting it in any competitively fast route. Maybe we could view it akin to, say, a run of Goldeneye that earned cheats along the way that required good play to unlock, and then activated them if they sped up the run. Obviously it would not obsolete a non-cheated run, but isn't there some real entertainment value there that should give us pause?
moozooh wrote:
Unlike a cheat code, stuff like ACE, memory corruption, and accessing hidden game-breaking debug features—i.e. completely ignoring in-game limits—at least get geek points for being ingenious and unexpected, but entertainment-wise they roughly amount to Luke Skywalker asking Obi-Wan to teach him how to use the Force, and then promptly killing Darth Vader with a lightsaber in the next ten minutes of the original Star Wars. Cheapening the experience is what it's called. I, for one, enjoy it a lot more when I see the awesomeness of an in-game character develop, not come "for free". This run's main (and only?) saving grace is that it ends at pretty much the same moment the "free" power comes, and before that comes some pretty hardcore "development".
I think the movie analogy is a little off, since games are repeated experiences and presumably viewers are not going to watch a TAS of a game they've never played expecting the storyline to be preserved. I get what you mean, of course. I think the argument should never consider throwing out the "movie" as it is. The appeal for these situations is more like an alternate ending, where the use of the code serves to cut out parts of the run that would be redundant otherwise compared to the non-cheated run. It's more like we have the original Star Wars, then we have two possible versions: one where Luke destroys Vader and explodes the Death Star with amazingly over-the-top superpowers within the hour, or one where he does the exact same thing but we still watch through the whole trilogy until the end. The rule itself should maybe be relegated to a guideline: something along the lines of "cheat codes should not be used except in specific situations, and TASers who want to use them should discuss their reasoning in the forums ahead of time." Anyway, it's a moot point as the run was published. I think the rule is better as a guideline for the reasons I've mentioned, but in general I have faith in the publishers to know to judge such situations on their individual merits. Removing the rule does away with the "concreteness" of such an argument, and I'm just opposed to black-and-white reasoning in such grey areas as I think it creates noise in the discussion that doesn't contribute to the determination of the best resolution. I absolutely agree with Warp that cheat-code runs have no business obsoleting non-cheated runs. Fortunately, I don't think anyone who has a say in the matter would seriously consider such a move.
I will not use self-reference in my signature.
Editor, Experienced player (607)
Joined: 11/8/2010
Posts: 4012
CoolKirby wrote:
We now have two runs of Super Metroid with no branch name, this and the "X-Ray glitch" run. One of them needs to have one, so how about labeling the X-Ray run "low%", as Cpadolf suggested?
As there were no objections in the 3 weeks since I posted this question, I'm going to go ahead and set the branch name to "low%". If needed, it can always be changed.
1 2
5 6