It seems to me that Warp's stance is, in practice, that we should pretend that games do not have bugs when we run them. Does that seem accurate to you, Warp?
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
It seems to me that Warp's stance is, in practice, that we should pretend that games do not have bugs when we run them. Does that seem accurate to you, Warp?
No. Absolutely nothing of what I have written can lead to that conclusion.
Are you making fun of me by any chance?
The main point in my modding comparison was not that the game was modified, but that the game was not actually played. There was no "speedrun". It simply shows the end credits by bypassing the actual game code, and that's it. That doesn't feel like you completed the game by playing the game, but by other means.
Hypothetical scenario time.
Let us propose a game, say Ocarina of Time, with a clearly defined "time" point by the running community - in this case, the point of the final hit on Ganon.
Let us also suppose that there exists an exploit that can be done in real-time that puts you in a position where you skip the majority of the game - in this case, a wrong-warp that requires ten minutes' worth setup that moves you from decidedly early in the game to roughly five scenes (room transitions) before the battle with Ganon in which you can reach the clearly defined "time" point.
Is that exploit something you would approve/disapprove of?
Now, let us suppose that, with a slightly different setup, the same exploit can instead be used to jump to roughly the halfway point of the game as opposed to near the end.
Would that exploit, which by itself has not changed, be something you would approve/disapprove of being used in that manner?
Based on the points brought up on the "worrying" side, I can only conclude that the "trends" in question are those which lead players to not play the game that the developers intended, full of its exploits and glitches and bugs that get ignored because they are not the pre-designed route that some team came up with, routes which were rigorously tested to be safe and beatable. The trends, therefore, seem to be anything which breaks this sequence of point-to-point events, skipping cutscenes and story in favour of reaching the endpoint in a shorter time.
These 'trends' seem to be things which the majority of speedrunners and TASers have embraced, welcoming ways to get out of auto-scrolling stages or long, boring cutscenes, and in some larger cases, skipping entire sections of the game. These 'trends' are becoming the face of the speedrunning community, worrying or not, and the people that are worrying might have to turn to (or join) the let's play or longplay communities to get their gaming fixes.
With that said, branches and categories still exist - "100% glitchless" is a thing that exists - and you might find things to be less worrisome over there.
I am still the wizard that did it.
"On my business card, I am a corporate president. In my mind, I am a game developer. But in my heart, I am a gamer." -- Satoru Iwata
<scrimpy> at least I now know where every map, energy and save room in this game is
Let us propose a game, say Ocarina of Time, with a clearly defined "time" point by the running community - in this case, the point of the final hit on Ganon.
Let us also suppose that there exists an exploit that can be done in real-time that puts you in a position where you skip the majority of the game - in this case, a wrong-warp that requires ten minutes' worth setup that moves you from decidedly early in the game to roughly five scenes (room transitions) before the battle with Ganon in which you can reach the clearly defined "time" point.
Is that exploit something you would approve/disapprove of?
Well, as long as the glitch is triggered via gameplay, I suppose it's ok, even though it skips an enormous part of the game.
Sure, the distinction between "skip X levels ahead by triggering a bug in the game" and "skip X levels by ACE" can be fuzzy in some scenarios, I don't deny that. I suppose it depends on the details.
If the skip is done because of a bug in level design, for instance (eg. the level designers never expected the player to be able to jump high enough to get over a wall), then it definitely falls into the acceptable category in my books. If the skip is done by corrupting memory, though... Well, we enter the really fuzzy area. It's hard to give a clear opinion in that case. (I suppose that as long as it's done via gameplay, it's more ok than not.)
Optimally there would at least be a speedrunning category of that game that doesn't skip that much using that technique.
Now, let us suppose that, with a slightly different setup, the same exploit can instead be used to jump to roughly the halfway point of the game as opposed to near the end.
I don't think it makes much of a difference in principle whether it jumps to the middle of the game or the final boss.
Joined: 11/13/2006
Posts: 2822
Location: Northern California
Warp wrote:
Derakon wrote:
It seems to me that Warp's stance is, in practice, that we should pretend that games do not have bugs when we run them. Does that seem accurate to you, Warp?
No. Absolutely nothing of what I have written can lead to that conclusion.
Are you making fun of me by any chance?
I don't think anyone's making fun of you. You've just always had a nasty habit of not being able to eloquently get your point across, which almost always leads people to make the wrong conclusions about your arguments.
TASvideos Admin and acting Senior Judge 💙 Currently unable to dedicate a lot of time to the site, taking care of family.
Now infrequently posting on BlueskywarmCabin wrote:
You shouldn't need a degree in computer science to get into this hobby.
Based on the points brought up on the "worrying" side, I can only conclude that the "trends" in question are those which lead players to not play the game that the developers intended, full of its exploits and glitches and bugs that get ignored because they are not the pre-designed route that some team came up with, routes which were rigorously tested to be safe and beatable.
I don't know what you are talking about. Nowhere have I said that glitches shouldn't be used. I don't understand where you are getting that idea.
Once again: It's not about what is used, but how.
Let us propose a game, say Ocarina of Time, with a clearly defined "time" point by the running community - in this case, the point of the final hit on Ganon.
Let us also suppose that there exists an exploit that can be done in real-time that puts you in a position where you skip the majority of the game - in this case, a wrong-warp that requires ten minutes' worth setup that moves you from decidedly early in the game to roughly five scenes (room transitions) before the battle with Ganon in which you can reach the clearly defined "time" point.
Is that exploit something you would approve/disapprove of?
Well, as long as the glitch is triggered via gameplay, I suppose it's ok, even though it skips an enormous part of the game.
Now, would you find these same exploits to be unacceptable if the final boss is not fought?
Optimally there would at least be a speedrunning category of that game that doesn't skip that much using that technique.
In the specific case of Ocarina, that category would be "MST", "Medallions, Stones, Trials". Most, if not all, communities have similar divisions between "absolute fastest" and "fast but still kinda sorta how the game was intended".
If the skip is done because of a bug in level design, for instance (eg. the level designers never expected the player to be able to jump high enough to get over a wall), then it definitely falls into the acceptable category in my books. If the skip is done by corrupting memory, though... Well, we enter the really fuzzy area. It's hard to give a clear opinion in that case. (I suppose that as long as it's done via gameplay, it's more ok than not.)
Again, I think you prefer when speedrunners play games that the designers intended, rather than when speedrunners operate the programs that the developers release, and thus far your responses to my scenarios have been in line with that. You find design oversights acceptable to take advantage of, but you dislike when programming oversights are taken advantage of.
It seems to me that Warp's stance is, in practice, that we should pretend that games do not have bugs when we run them. Does that seem accurate to you, Warp?
No. Absolutely nothing of what I have written can lead to that conclusion.
Are you making fun of me by any chance?
Not in the slightest, and thank you for assuming the best of me </sarcasm>.
The problem is that as soon as you allow the abuse of bugs, you are in unintended behavior. You are no longer playing the game as the developers intended, because they did not intend for you to encounter buggy scenarios. So everything boils down to a difference in degree: there's a continuum here. At the most conservative (category A), you play the game the developers wrote, and conscientiously avoid using bugs. Next to that (category B) is you make use of bugs that happen to have beneficial effects. Next to that (category C) is arranging things in precise ways so that bugs will have beneficial effects (like the SMB3 wrong warp glitch or any number of different Pokemon glitch runs).
And finally you have ACE, category D, where you abuse bugs to enable you to write your own code. Note that subtle versions of category D can look incredibly similar to category C -- like, you can't arrange the precise jump-to-memory that you want by manipulating memory "once", but you can arrange a jump into the sprite data, and then arrange said sprite data so it looks like "jmp address-of-end-cutscene". That's technically ACE, but it's barely different than category C, hence why I said it's a continuum.
You don't like category D runs, but you're okay with A/B/C? Okay, well, there are players who don't like category C runs. And players who don't like category B runs. And there are players who find it offensive that they should be constrained to just category A. Everyone's gotta make peace with the fact that there are different kinds of runs that play to different tastes.
The way I see it, as a consumer of this free entertainment product (viz. speedruns produced by other players), your options are either a) enjoy what is available, or b) learn to make your own speedruns. Telling the people, who work on this in their free time for no compensation, that you don't like what they're doing is not likely to win you any friends.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Now, would you find these same exploits to be unacceptable if the final boss is not fought?
This delves into the question of what constitutes game completion. It's not a trivial subject.
You find design oversights acceptable to take advantage of, but you dislike when programming oversights are taken advantage of.
Not really. The level design was just an example.
Sometimes a wall can be bypassed by abusing actual programming errors or oversights (like bypassing that one gate in HL2 when getting out of the motorboat), and that's fine too.
It's when the glitch pertains to corrupting the game's data or program that it starts veering towards the uncomfortable side. I suppose that as long as it's done via gameplay only, it's still ok.
My original complaint is not about what kinds of glitches are used, but how they are triggered. Are they triggered via gameplay or via non-gameplay.
It's not that I don't like it. As I said, they are marvelous demonstrations of technological knowledge and work, and can be very impressive.
The problem I have is when they are considered proper game completions (which, in my opinion, is one of the fundamental requirements for a speedrun).
Except that the biggest thing that you are arguing against, ACE, is triggered /by gameplay/. Which suggests that gameplay issues are something that you have a problem with.
I am still the wizard that did it.
"On my business card, I am a corporate president. In my mind, I am a game developer. But in my heart, I am a gamer." -- Satoru Iwata
<scrimpy> at least I now know where every map, energy and save room in this game is
My original complaint is not about what kinds of glitches are used, but how they are triggered. Are they triggered via gameplay or via non-gameplay.
Then what is gameplay? For the game there is no definite technical distinction except "byte X being Y means controller input moves the player sprite and the byte being Z uses controller input for doing something else".
Navigating the menus is often an indistinguishable part of playing the game, e.g.
- using a JRPG's inventory
- de-/activating suit functions in Super Metroid
- using the built-in save&reset function in Link's Awakening while the shopkeeper subtracts your money
It's when the glitch pertains to corrupting the game's data or program that it starts veering towards the uncomfortable side. I suppose that as long as it's done via gameplay only, it's still ok. My original complaint is not about what kinds of glitches are used, but how they are triggered.
I think I've reached an understanding of what you're saying. If I understand you correctly, you would always disapprove of an RTA run that replicates the Pokemon Yellow π% ACE movie because it takes advantage of what happens when you interrupt a non-gameplay action, in this case saving the game.
Meanwhile, I'm guessing that you would possibly (though reluctantly) approve of an RTA run that replicates TASBot's AGDQ debut of rewriting Super Mario World to instead play Snake and Pong because everything that was done to make the game accept the payload was done from within gameplay. Disregard the ACE aspect of it all, and just confirm or reject the second scenario, since the first is a known rejection.
(The impossibility of actually replicating the given examples in an RTA scenario is irrelevant, they're just the most extreme examples I could think of that demonstrate what Warp is referring to)
Except that the biggest thing that you are arguing against, ACE, is triggered /by gameplay/. Which suggests that gameplay issues are something that you have a problem with.
I'm getting tired of having to repeat myself. Therefore I'll just start quoting myself.
Warp wrote:
But the reason I don't like ACE to be considered a proper completion of the game is quite different from the subject I'm talking about in this thread (ie. non-gameplay tricks being used in speedruns. After all, ACE is (usually) done purely via gameplay, so it's a different issue.)
Navigating the menus is often an indistinguishable part of playing the game
It's not navigating menus that's the problem. It's when you use none-gameplay elements in those menus.
You might just as well say "pressing keys is an indistinguishable part of playing the game (and therefore quicksave and quickload keys are the same thing as movement keys)".
The ACE question and the "techniques used in speedruns" are completely different. ACE was only mentioned incidentally, unrelated to my original points. Don't confuse the two.
I'm not happy with, for example, deleting savefiles in HL2 speedruns because I don't consider it gameplay, but an external non-gameplay technique used to affect the game.
I'm not happy with considering ACE runs legit game completions, for rather different reasons (completely unrelated to gameplay).
These are two completely different and independent propositions. The latter is not related to the former. And the latter one is not the subject I wanted to discuss in the first place. The discussion veered towards it only because it was incidentally mentioned.
Warp: The fact that it's ACE shouldn't matter for what I'm asking. The first one interrupts saving to invoke a glitch. The second was done entirely from within gameplay. Disregard that they're ACE, tell me how you would react to seeing the second done in real-time. See next post.
Joined: 8/15/2005
Posts: 1941
Location: Mullsjö, Sweden
The way I see it, with "gameplay", is that every input press you make while the game is on, is playing the game. As the game consists of the cartridge/disc/whatever, when you feed it controller inputs, you are playing the game. Not matter if this is moving around on the overworld, equipping your character or deleting a savefile. They are all part of the game, they are all playing the game.
One thing that practically is not playing the game, is standing still and waiting for something to happen. Standing still, not pressing a single button, for 10 minutes until something happens. Are such glitches OK? They are clearly not gameplay, as you don't feed the game any input.
Probably a silly comparision, yes. I just think it's also silly to not say that things done on the file select screen are not part of the game/playing the game, because to me it is.
It occurs to me that I am asking the wrong question and presenting my argument in the wrong manner.
Example 1: Pokemon Yellow, exploiting the interrupting of saving to redefine functions. This is known to be a disapproved method. It is here only as an example of what is meant by "not gameplay."
Example 2: Super Mario World, exploiting programming errors, presumably entirely from within "gameplay." It is the method used in this that I am curious of your reaction to.
I use these examples not because they're ACE, but rather because they are the clearest and most dramatic examples I could think of that demonstrate what you're talking about in the difference between gameplay and non-gameplay. If you have better examples, please link to them. Right now we're hung up on this point because there's nothing concrete to point at.
Please disregard the payload, and comment only on the methodology used in the second example (the Super Mario World one). Do you consider the manner in which the exploit was reached to be entirely "Gameplay?" If so, would you approve of the methodology if the payload was jumping to the level named "Back Door" instead of to a completely unexpected series of instructions?
The way I see it, with "gameplay", is that every input press you make while the game is on, is playing the game. As the game consists of the cartridge/disc/whatever, when you feed it controller inputs, you are playing the game. Not matter if this is moving around on the overworld, equipping your character or deleting a savefile. They are all part of the game, they are all playing the game.
But then we go back to the question of why eg. the developer console in HL2 is disallowed, even though it's fully within the game, usable from the game, using its own input.
What is and isn't allowed is, ultimately, somewhat arbitrary. The community decides "thing X supported by the game itself is allowed, while thing Y supported by the game itself is not."
The speedrunning community draws the line at the developer console. I would prefer the line to be drawn a bit more restrictively. My rationale is that a speedrun should complete the game by playing the game rather than using non-gameplay means (such as the developer console, deleting saves, and saving/loading for the purposes of glitching the game).
Let me put it this way: Would you think it acceptable if the speedrunner alt-tabbed to Windows and then used its file manager to delete the save file? If that's not acceptable, then why is it acceptable to do it from within the game? (And remember: "If it's supported by the game, it's ok" is not a very good argument. Remember the developer console, which is banned even though it is also supported by the game.)
Pokota wrote:
Please disregard the payload, and comment only on the methodology used in the second example (the Super Mario World one). Do you consider the manner in which the exploit was reached to be entirely "Gameplay?"
I didn't check if it uses the reset button. If it does not, then it's done via gameplay yes. (But my problem with ACE is not whether it's triggered via gameplay or otherwise.)
If so, would you approve of the methodology if the payload was jumping to the level named "Back Door" instead of to a completely unexpected series of instructions?
If a glitch causes the execution of the program to jump to an unintended location, then it's a bit in that fuzzy area. In some particular situations I would consider it ok while in others it would be a bit bothersome. (After all, how do we define the execution of the program "jumping to an unintended location"? It can be hard to define in some situations.)
If so, would you approve of the methodology if the payload was jumping to the level named "Back Door" instead of to a completely unexpected series of instructions?
If a glitch causes the execution of the program to jump to an unintended location, then it's a bit in that fuzzy area. In some particular situations I would consider it ok while in others it would be a bit bothersome.
You didn't answer this question. In the specific hypothetical case of Super Mario World, would you approve of the methodology if it were used to skip to "Back Door"?
(I'm giving you a hard time, yes, but that's because I'm trying to establish a common ground here)
You didn't answer this question. In the specific hypothetical case of Super Mario World, would you approve of the methodology if it were used to skip to "Back Door"?
I suppose I don't understand what you are asking.
I don't think it makes a difference how far in the game the glitch jumps, with regards to the question of whether I like it or not.
I asked for a specific answer and got a generic response. This has now happened twice.
The same glitch can be used to either go to a completely arbitrary-but-still-within-gameplay point, to a completely arbitrary-and-after-normal-completion point, or to something that the developers never envisioned. We know C is bad because it's leaving gameplay entirely. We know you disapprove of B on the grounds that it calls into question when the game actually ends. I'm trying to get a specific response to A precisely because it still leaves gameplay to be completed.
We know you disapprove of ACE. What is unknown is how you react to other, non-ACE and non-game end uses of game end glitch, which is the foundation of ACE. What I'm concerned about is that you'll give the same methodology different leniency as a result of payload. Prove me wrong.
I seem to be hung up on ACE, so I'm going to change examples. See next post.
