Hacking a console game into executing any machine code you want solely by pressing buttons on the gamepad is an impressive feat, worthy of awe in the general public and articles in online magazines (at least the first few times it has happened.)
However, there's a problem in classifying this in the same category as "normal" tool-assisted speedrunning: Once you can input any machine code you want and have it executed by the console, all bets are off. You are basically writing your own custom "ROM" (colloquially speaking, as the technical term is a bit of a misnomer here) into the memory of the console (with a game cartridge plugged in which you can use for whatever you want.) This has stopped being a speedrun of the game, and it has simply become showing off a custom program. (The custom program may be able to use assets from the game cartridge that's plugged in, but it's nevertheless just that: A custom program.)
I don't think this should be even considered a regular TAS anymore. If anything, I think this should be a separate category where the time is not from startup to game completion, but from startup to the point where you can start inputting machine code into the console's memory. At that point the timer should stop, and that's the official time of the "TAS", because after that it's not a speedrun of the game anylonger. And it should not obsolete any of the TASes that do not use the technique.
Consider this: What is a "100%" completion of a game? It of course depends on the game (and not all of them have a sensible meaning), but in many cases it's eg. collecting all items. Well, consider that with arbitrary code execution you can make the game think you have all the items and then jump to the end of the game. This would probably be just some frames slower than a fastest possible jump to the end.
So the question is: Would you think such a "TAS" ought to obsolete a "100%" branch that doesn't use the technique?
If your answer is no, then why would you think it should obsolete the "any%" branch either? IMO it shouldn't.
(Note that I'm not saying that this is what's necessarily happening, or going to happen. I'm just writing some thoughts on the subject for you to consider.)
his has stopped being a speedrun of the game, and it has simply become showing off a custom program.
I don't agree with this. The goal of a speedrun is to reach as fast as possible a point where the game can be considered ended. This point can be the death of the last boss, the end screen of the game... But the way you reach this point doesn't matter (except you're not allowed to use cheats, passwords, etc). So of course ACE TASes shouldn't obsolete old runs (a perfect example is the recent ACE Super Metroid TAS), but they must be timed in the same way that "normal" runs. Look at the recent Pokémon Silver TAS : without all the setup before the ACE, the run would take less than 5 min (probably even less than 2 min), and would be perfectly unintersting.
I problably made mistakes, sorry for my bad English, I'm French :v
I'm inclined to think that gaining total control should always be a category of its own, and should be categorized "total control" (if it turns into a playaround) or "victory via total control" (if it's just used to win the game, with whatever definition you care about at that point). Given that total control, once gained, can be used to do anything this neatly avoids most categorization issues (the only remaining one is what to do when the total control is gained via a cheat code).
And also think that fastest time to gaining the total control (perhaps plus fastest time to enter the resulting program, but that's only a matter of frames in most cases) is the most sensible way to time such runs. This doesn't seem incompatible with either Warp's or Eszik's point of view, given how the exact way in which timing is ended is fuzzy anyway. (I remember writing a long post somewhere on timing issues related to Rosenkreuzstilette, which is interesting because the route changes quite noticeably depending on the exact rules used for when timing ends.)
I'm inclined to think that gaining total control should always be a category of its own, and should be categorized "total control" (if it turns into a playaround) or "victory via total control" (if it's just used to win the game, with whatever definition you care about at that point). Given that total control, once gained, can be used to do anything this neatly avoids most categorization issues (the only remaining one is what to do when the total control is gained via a cheat code).
I agree with this. For all intents and purposes, when a game hits Total Control, all bets are off. Otherwise, we'd get runs like this one, which technically should've obsoleted the current SMW 11-exits run. (And even then, it's technically not the fastest way you could've done it, which would've lead us to further complications.)
So the question is: Would you think such a "TAS" ought to obsolete a "100%" branch that doesn't use the technique?
If your answer is no, then why would you think it should obsolete the "any%" branch either? IMO it shouldn't.
I don't think total control game completion should obsolete "normal" speedruns. There's only one issue: game glitched into completion state, the very thing Warps is so much against, shouldn't obsolete "normal" speedruns either. But one glitched to end TAS can very well obsolete another glitched to end TAS, can't it? They both aren't normal, at least compared to the majority of speedruns, where such glitches are mostly not possible (or not discovered yet).
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Whether highly-glitched runs, which nevertheless do not run custom code, ought to be considered "normal" valid completions of the game is an interesting question in itself. However, I think that the distinction between "arbitrary code execution" and everything else is quite unambiguous: Does the runner input machine code into the console's memory and make the CPU run it? If not, then it's not ACE.
Since the beginning of time there has always been a camp that detests excessive glitching in TASes because it feels like too much of an abuse and too little of actually completing the game by playing it. I understand this sentiment perfectly, and in fact in recent years I have started to appreciate it more because heavy glitching has become more and more like a gimmick and not something so... "cool", I suppose.
Although it depends on the type of "glitching". For example I still like zipping and going out of boundaries (like in Megaman and some of the Castlevania games). In general, techniques that abuse poor boundary checks and similar bugs or defects in the game engine. However, I'm not so fond of glitches that corrupt memory, like filling the player's inventory with extraneous items or things like that via wild pointers or other such bugs. (And as some might remember, I absolutely detest abusing of savedata corruption, and in general abusing anything with the reset button.)
However, I'm perfectly and painfully aware that putting limits to this is extremely hard and arbitrary. "I don't like this type of glitch but that other type of glitch is fine" is very subjective and very much personal opinion.
Regardless, I think it may be a good idea to relegate arbitrary code execution to its own, separate category.
My opinion now: runs that use ACE to glitch to the game end have the latter as a dominant goal, so they don't care if they use ACE for that or not, whatever glitch does it faster is preferred. So I don't want such runs have the label ACE at all. Having them only as "game end glitch" would deal with all obsoletions that can happen to them.
And there are runs that use ACE access to showcase arbitrary code itself, for pure entertainment, just like playarounds. These should have the label. But I suggest switching to the label "total control" for them. First, because arbitrary code doesn't aim for game end at all, like in the above case, and second, because arbitrary code access is extensively used, namely to apply total control to the game, for the sake of itself.
As for secting a separate branch for ACE fastest speed runs, against non-ACE fastest speed runs, is only a matter of viewers' taste, since only they decide what's different enough to go Moon separate branch.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
I think that ACE Runs should be counted as separate categories as once you get to the code part, the goal don't matter anymore as it's just "the code" that would change, and you would do the same "pre code input" to get either any % ( just trigger the ending flag) or 100% (trigger the 100% flag , then trigger the good ending flag )....
Joined: 5/2/2006
Posts: 1020
Location: Boulder, CO
Warp wrote:
Whether highly-glitched runs, which nevertheless do not run custom code, ought to be considered "normal" valid completions of the game is an interesting question in itself. However, I think that the distinction between "arbitrary code execution" and everything else is quite unambiguous: Does the runner input machine code into the console's memory and make the CPU run it? If not, then it's not ACE.
What about glitches that involve running some machine code that the runner has limited or no control over? This is often the case for runs labeled "skips to credits".
It is similar to ACE because the runner might be executing code that is not intended to be part of the code of the game, but it is unlike ACE because the code being executed might not be arbitrary at all-- in fact the runner's control over what code is run might even be fairly limited.
Where does heavily glitched end and ACE begin?
What about glitches that involve running some machine code that the runner has limited or no control over? This is often the case for runs labeled "skips to credits".
It is similar to ACE because the runner might be executing code that is not intended to be part of the code of the game, but it is unlike ACE because the code being executed might not be arbitrary at all-- in fact the runner's control over what code is run might even be fairly limited.
Where does heavily glitched end and ACE begin?
Of course, such a "heavily glitched" run might just be the prelude to a "true ACE" run as the runners figure out how to get more control over what code exactly is executed...
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
As a general rule, if you have to explain to a layman how the game has just been completed, it's enough to warrant its own category. ACE falls under those criteria.
As a general rule, if you have to explain to a layman how the game has just been completed, it's enough to warrant its own category. ACE falls under those criteria.
Considering the amount of people that label jumping over piranha plants in Super Mario Bros. "impossible" and "cheating", that is a very, very poor rule.
I agree that total control seems like a new type of running compared to regular glitches. Take Pokémon Red and Blue. Most of the iconic glitches involve somehow manipulating RAM; the Missingno. glitch pulls data from the player's chosen name and uses it to load data with index numbers matching characters in that name. The Mew Glitch pulls data from the last Pokémon the player battled and uses it to load an encounter with a level matching that Pokémon's Attack modifier and an index number matching its Special stat. Although these RAM glitches are useful for loading unusual data, they don't involve executing the unusual data as code. I agree with Warp that total control TASes should be a separate category from other glitched runs, and I don't think we should allow total control TASes to be the "100%" category.
This is the same discussion we had in the topic about the term "glitched". I can only repeat my opinion: The unnamed (any%) branch should always be the fastest way to reach the credits, no matter how this is achieved.
For 100%, the problem would easily be solved by creating a category called "100%, no arbitrary code execution"
Current project: Gex 3 any%
Paused: Gex 64 any%
There are no N64 emulators. Just SM64 emulators with hacky support for all the other games.
The unnamed (any%) branch should always be the fastest way to reach the credits, no matter how this is achieved.
So if the credits can be reached faster by inputting a cheat code, it should be allowed?
(My point is that "anything goes" implies "within certain rules".)
The unnamed (any%) branch should always be the fastest way to reach the credits, no matter how this is achieved.
So if the credits can be reached faster by inputting a cheat code, it should be allowed?
(My point is that "anything goes" implies "within certain rules".)
Not using cheat codes (except for cosmetic things or gamemodes/characters inaccessible otherwise) is a general rule of the site, just like the usage of the hardest available difficulty. Of course a TAS shouldn't violate those. But what if the fastest way to beat a game was to actually "create" a sort of cheat code by using arbitrary data execution? I think this technically should be allowed.
Current project: Gex 3 any%
Paused: Gex 64 any%
There are no N64 emulators. Just SM64 emulators with hacky support for all the other games.
Not using cheat codes (except for cosmetic things or gamemodes/characters inaccessible otherwise) is a general rule of the site, just like the usage of the hardest available difficulty. Of course a TAS shouldn't violate those. But what if the fastest way to beat a game was to actually "create" a sort of cheat code by using arbitrary data execution? I think this technically should be allowed.
I don't think the existing rules are (nor should be) set in stone, never to he changed or amended.
For example, if a consensus is reached that using ACE to reach the game end is not a valid "any%" game completion (instead being more akin to a "playaround demo"), then the rules ought to be amended as such. (I'm not saying this must be done, even though personally I would advocate it. My point is that the rules ought to not be so rigid as to not allow this.)
Btw, would this be a good occasion to, once again, advocate an old idea of mine? A "uses intended route" branch.
Many people would like to see a game played through (rather than glitched through) with perfect accuracy. Many games lack such a TAS because glitches that skip large portions of the game are the de-facto standard. While this is cool and all, it would still be nice to see the original intended route being played with perfect accuracy. Hence a "uses intended route" branch.
Btw, would this be a good occasion to, once again, advocate an old idea of mine? A "uses intended route" branch.
Many people would like to see a game played through (rather than glitched through) with perfect accuracy. Many games lack such a TAS because glitches that skip large portions of the game are the de-facto standard. While this is cool and all, it would still be nice to see the original intended route being played with perfect accuracy. Hence a "uses intended route" branch.
It really is a nice idea, but there are unfortunately big problems with the "intended route" branch.
1) Who's to say what the route intended by the developers is, particularly in RPGs/sandbox games where exploration is very much the focus? And how strictly does it have to be defined - how large do the shortcuts taken have to be before they are outlawed?
2) Runs in such a category would never get large improvements, since macro-optimisation is impossible once a route has been prescribed for all runs to follow. It is likely that interest in such categories would suffer as a result.
3) It runs contrary to the very philosophy of TASing: the game is just a game, a set of rules, and you must exploit those rules as efficiently as possible.
4) People can already watch real-time speedrunners. They're pretty good. Arbitrary code execution is one of the things that greatly highlights the potential of TASing, at least in the many examples where such tricks are impossible in real time, or if they are possible, require a considerably more tortuous setup.
The unnamed (any%) branch should always be the fastest way to reach the credits, no matter how this is achieved.
Warp wrote:
I don't think the existing rules are (nor should be) set in stone, never to he changed or amended.
For example, if a consensus is reached that using ACE to reach the game end is not a valid "any%" game completion (instead being more akin to a "playaround demo"), then the rules ought to be amended as such. (I'm not saying this must be done, even though personally I would advocate it. My point is that the rules ought to not be so rigid as to not allow this.)
There will never be any consensus, the crowd is exactly halved in opinions on is "glitch X" a part of any% or not. We can't use the either option as it is. So we have retired "glitched" label and "any%" indication. Because both are also subjective and relative. Blank branch will not be an indication of any%.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
1) Who's to say what the route intended by the developers is, particularly in RPGs/sandbox games where exploration is very much the focus? And how strictly does it have to be defined - how large do the shortcuts taken have to be before they are outlawed?
Most games are pretty straightforward. You want to dismiss a branch because with some games it can be difficult to define?
2) Runs in such a category would never get large improvements, since macro-optimisation is impossible once a route has been prescribed for all runs to follow. It is likely that interest in such categories would suffer as a result.
The vast majority of published runs get no significant improvements. I see no problem.
3) It runs contrary to the very philosophy of TASing: the game is just a game, a set of rules, and you must exploit those rules as efficiently as possible.
You could dismiss alternative goals like "100%" or "uses suboptimal character" with the same reasoning. It has never been a problem.
4) People can already watch real-time speedrunners. They're pretty good.
But they are not perfect, and that's exactly the point. Some would like to see the human factor removed from the equation.
I don't mind making more branches when both runs are entertaining and have a good reason to exist, but I think Warp's assertion that it's obvious when a run crosses the line into ACE is wrong. The SMB3 run currently on the bench is a great example of a point somewhere along the spectrum, and there are countless other possible ways that a run might sorta kinda end up executing user input, but not in the distinct, obvious way that, say, the original Pokémon Yellow Total Control run did.
I think that branch creation should be decided on a game by game basis by the run authors and the viewers. I am fine with a vague site precedent for non-ACE branches, for games for which that is well defined. But I think I agree with andypanther that the fastest completion should be the any%.
Now, I am a bit torn about the "but it's not really the same game anymore" argument. This is fundamentally true. One can imagine a game where it is easier to hijack the display routines and create your own facsimile of the game's credits, without actually calling the credits routine. By inspecting the screen, you couldn't tell the difference — but have you really beaten the game?
In the end, though, I think I come down on the side of goals being predefined conditions on memory states, which we as players choose based on our human understanding of the intended end of the game, but which, as soon as we choose them, become abstract, objective mathematical conditions. If achieving the chosen conditions involves entirely ripping apart and rewriting the game, that's fine — in fact, it's pretty damn cool.
That said, there's no reason that we can't let our knowledge of ACE capabilities inform our goal choices, to, for instance, define them in ways that allow calling the credits routine but not drawing something that looks like the credits yourself.
A warb degombs the brangy. Your gitch zanks and leils the warb.
Joined: 10/27/2004
Posts: 1977
Location: Making an escape
All I'm gonna say about this whole thing is that while it's cool, it's a little disheartening to see that games aren't really being "played" anymore. I used to think that the sub-four minute Link to the Past was cool, but I now think it's boring to start a game and then finish it.
A hundred years from now, they will gaze upon my work and marvel at my skills but never know my name. And that will be good enough for me.
All I'm gonna say about this whole thing is that while it's cool, it's a little disheartening to see that games aren't really being "played" anymore. I used to think that the sub-four minute Link to the Past was cool, but I now think it's boring to start a game and then finish it.
I wouldn't worry too much. ACE is getting its time in the limelight right now, like multiruns did awhile back. It won't ever disappear completely but it's not like more "traditional" runs aren't going to continue being made.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
My 2 cents. Keep ACE out of TAS branches by making a new branch solely for that.
The instant we amalgamate these together and obsolete stuff U, U, D, D, L, R, L, R, B, A, Start, then we're going to have to come to the next big resolution to this. That being, what if later down the road there's another huge debate and it's decided that ACE needs to be its own branch.
That's a shitload of extra work that's going to have to be done to fix this. Keeping ti apart for now until things are finally and definitively decided... that makes things easier.
But more so, the opinion part since I got sidetracked... It's a nifty concept. It's got some interesting moments of mysticism... but I agree with others before me... it's not as fun as watching a game gone through. 4 min ALTTP... fun for the first few views... technically sound... but then you start realizing how much is skipped and you kinda wanna see how someone would handle that stuff.
Trying to explain why the new SMB3 TAS does what it does.. even with the description, new people who aren't savvy will have many questions... and not all of them will be the enlighten me ones.
Scepheo wrote:
Considering the amount of people that label jumping over piranha plants in Super Mario Bros. "impossible" and "cheating", that is a very, very poor rule.
And this... WTF? Seriously? Why are you reading Gamefaqs.com
Mr. Kelly R. Flewin
Just another random gamer
----
<OmnipotentEntity> How do you people get bored in the span of 10 seconds? Worst ADD ever.
