Speedruns to Watch

It’s not just a divide of popular games and unpopular ones.

There’s also a divide of budget. Lower budget games are more likely to have worse QA with more glitches remaining at time of release. Higher budget games, hopefully less so.

There’s also a divide of newer vs older games. Older games are simpler pieces of software, built using old tools, running on simpler platforms. Often times they were written from scratch in C or even assembly. It’s more likely for them to contain serious bugs, and they are easier to find due to decreased attack surface. Then again, sometimes older games are so small and simple that they are basically bulletproof. Pac-Man might crash when the score gets too high, but there’s no magic glitch to do that instantly. You have to get good.

And yet again there’s a difference of game engines and development tools. Building a game with a modern game engine already puts the weight of so much QA behind the software before development even starts. Sure there might be some out of bounds or something, but finding a magical way to skip to the end of the game will be difficult unless the developers were extremely negligent (or it was intentional).

Even in the cases where there isn’t some ridiculous glitch to skip the entire game, any% runs of almost all games include some exploitation that was not developer intended. Consider the Castlevania SotN any%. There’s no magic glitch to make the end credits roll, but there are some absolutely ridiculous tricks that are basically cheating. The any% world record is about half of the glitchess run.

Speedrunners recognized and solved this problem long ago. The way I think about it is this:

Glitchless is trying to play the game as fast as possible.

Any% is trying to play as little of the game as possible.

What are your thoughts about speedruns that require preparing controllers in advance, before the timer starts, using variable readout tools to position analog joysticks with six figure precision’s, taping the joystick in the correct position, and plugging them in when needed to enter the correct values for code execution?

Because, to me, this feels different than testing human skill in my own understanding of a any% kind of run.

Thankfully we have RTA vs TAS categories for games where there is a big enough community. TAS any% and RTA any% end up being separate categories.

But it gets real interesting where some of these credit warps are RTA-feasible.

Look at Final Fantasy 1 and Final Fantasy 4 speedruns. There is an RTA any% using the stairs to glitch to the end. So there are “stair glitch” and “no stair glitch” categories within any% for both RTA and TAS.

The general rule of speedrunning is that you’re cheating if you’re doing the kind of cheating people do for Counter-Strike. Modifying the software, modifying the hardware, that sort of thing. The only way you can communicate with the game is through the system’s intended inputs. Power, reset, two controller ports, etc.

For a TAS, you can have a computer speak to those inputs instead of a person.

For a non-TAS you need an unmodified input device to speak to those inputs. For example, a controller with a turbo button would not be allowed for an NES speedrun even though Nintendo produced official controllers with turbo buttons.

A human has to interact with these standard inputs to communicate with the game from the time the game boots to the time it shows its ending screen, and anything outside of that is permitted.

For example, it’s legal to take notes during the game. You can do math using a calculator. It’s legal to use software like the splooshkaboom solver for Wind Waker because it is not connected to the game at all. It’s effectively no different than using a calculator on the side.

If somebody were to put a piece of tape on their controller to hold a button down, that’s not ok. That’s entering turbo button territory. Effectively that’s cheating as much as using a Game Genie. But if you just use a calculator on the side to read the controller and are able to hold the buttons in place with your hands, then that’s legit.

We also have to consider being lenient in this rules to make appropriate accommodations for accessibility. If someone needs a non-default controller to play, so be it.

I agree.

And what’s unsatisfying (to me), is that for Ocarina of Time, a vote was held about this kind of thing, and the any% record now allows everything I outlined and more:

Controller Vote Results March 2020

  1. Should it be allowed to add or remove material to your controller to form a custom notch to aid holding specific analog stick positions?

Result: this is now allowed.

  1. Should it be allowed to use tools other than your hands (such as rubberbands) to hold static inputs on a controller during a speedrun?

Result: this is now allowed.

  1. Suppose that before your speedrun begins, you set a controller to some combination of held buttons and non-neutral analog stick which is meaningful to the success of that speedrun. Should it be allowed to begin the speedrun with these inputs held?

Result: also allowed.

  1. Assume the above question results in holding input prior to a run being allowed. In this case, should it be allowed to use external (such as an input viewer) or in game tools (such as ACE or gameplay) BEFORE the run in order to determine whether the held input is exactly as desired?

Result: everything allowed.

So yes, I know what “tool assisted” means, and all the other terms, and all the ways this has been determined in the past.

If you don’t already know what lengths people are going to be able to pull it off (including modifying controllers and using in-game software tools to pre-set controllers before the clock starts), then it seems like a non-issue.

But to me, as someone who thinks a lot about game design, it feels like a line has been crossed with code execution.

1 Like
  1. Disagree with this vote completely. Can’t modify the system. Might as well just modify the game itself then.

  2. Partially agree. The speedrun doesn’t start until you press start. Anything you do beforehand doesn’t matter as long as you aren’t modifying the system. If you have to get the controller into a certain spot for the start of the game, use the tape or rubber band, or whatever. But all those things have to be removed before the clock starts.

  3. Completely agree with the vote on this one.

  4. Partially agree. I don’t know enough about the in-game tools they list to know whether they constitute a modification of the hardware or software. However, the external input viewer is fine. As long as it is a separate and completely stand-alone device that does not directly communicate with the game, it’s philosophically the same as the splooshkaboom calculator.

Right. I consider code execution to be as much of “might as well just modify the game itself” as modifying the controller.

It’s a different version of the game that displays the exact input of the analog stick. You use it to position the stick, hold it in place with tape, and then you restart the game with normal version to do the run itself.

I actually don’t mind a readout like this. But using a tape to hold it in place once set feels like you’re just making a very inefficient memory store for a very TAS-like entry of a specific data.

If they manage to get the game to execute the code they want by only communicating via the games inputs, and don’t directly modify the software or hardware in advance, then it’s legit. The only difference between than and “IDDQD” is that one was intended by developers and the other is not. The author is dead, though. With video games, the software is the rules. If the unmodified software allows it, then it’s allowed. It’s in a separate category, so no big deal.

That’s cheating. The game itself has been modified. It’s perfectly fine to use a tool like that when practicing. Use it to train yourself to master the correct inputs. People do this with emulators all the time. However, during an actual run it is not permitted.

I’m ok with the tape as long as it isn’t on the controller at or after the time the clock starts.

Apparently this is all moot now because a way was found to get this 6 digit number to do code execution that didn’t require modifying the controller or holding down buttons.

But it feels like allowing this specifically for code execution opens up a fuzzy area.

And to me code execution is a fuzzy area.

It’s not fuzzy whatsoever. A person is pushing buttons on the controller. The game responds in a certain way. If I push (very long sequence of inputs that it takes to beat the game the “normal” way) the game displays the ending screen. If I push this (much shorter sequence of inputs that happen to exploit unintended code paths in the unmodified original software) the game displays the ending screen.

Pushing buttons to get the game to display the ending screen as quickly as possible. That’s the competition.

Video games are just software. If someone makes a software version of a game, and they fail to translate their intended ruleset into computer code, allowing for “cheating” that’s not the player’s problem. From the player’s perspective, the code is the rules. If the unmodified game allows it, then it’s allowed.

We definitely have some legit complaints here as game modifications are going on with tape and such, but other than that, it’s all good. If you don’t like glitches, that’s fine. Stick to glitchless categories. Categories solve this problem completely.

As someone who tells people to read what other people write to stop misunderstandings, you sure like to assume I’m talking about one thing when I’ve clearly stated I’m talking about something else. Where did you get the idea I don’t like glitches?

1 Like

From mostly just following Goldeneye speedrunning lately, rwhitegoose and jobst and so-on; there was some commentary regarding the debate as to modding controllers. I think the result of that argument was summed up as “we can’t practically require a proofcall for every single submitted run to have a second video to verify that during the run in question there was basically factory-new-condition unmodified controllers used at all times.” Because most runs are using screen-capture there would have to be a second camera that records that run, and that camera would have to also display the screen of the run being done, and the player would have to prominently display the controller for inspection.

This was deemed too onerous of a requirement.

And so while some specific, egregious mods (like removing the entire housing and putting pressure on the board to cause non-standard inputs) was banned, there was basically no rule against using things like the two-controller styles and using rubber-bands or other ad-hoc sort of input assists (such as just stuffing the controller into the corner of the seat and using your leg to hold forward+strafe constantly.)

Because it was deemed that the band-assist was effectively mechanically comparable to just using awkward body positions and that the whole process was a royal pain in the ass regardless, and the solution was basically what any kid in 3rd grade would likely devise on their own, there is no point trying to regulate it. Use it, or don’t.

Once you start carving notches in the controller, or making sure the controller has 10,000 cycles on the sticks or whatever to make sure it’s broken in, that’s highly dependent. I would favor such mods if they could happen through reasonable wear and tear, so to artificially age them using sandpaper or a knife or what-not is fine. But if even after 20 years there would never be such wear or change to the controller behavior that definitely should be a modded hardware run.

Banning controller modifications is dangerously close to banning handicapped players from participating. What the realistic difference between a controller modded for ease of input vs to allow for disabled use?

If either case gives the user an advantage in terms of button inputs I would argue that’s not against the spirit of speedrunning. You are manipulating the program to achieve a specific condition as fast as possible, not as authentically as possible. Imagine what a pain it would be to enforce PC speedruns with specific keyboards.

I already brought this up above. I think it’s pretty clear that some modifications allow for accessibility while some allow for a play advantage. Moving a button, making it larger, making it easier to press, making it a different kind of button, all of these are fine. Whatever people have to do to make the game accessible must be explicitly permitted.

Putting a rubber band on the controller to permanently hold a button down without the player doing anything, how is that different from TASBot? TASBot is just a very complicated rubber band that presses buttons with no human involvement. A turbo button is pressed once, but an electrical circuit mashes the button several times. A fight stick with a programmed macro that executes a hadouken with a single button press is the same thing.

To be a non-TAS run there has to be a 1:1 mapping of human actions to inputs whatever form that mapping takes.

I guess we can think of it this way. Break down a controller into its component input signals. On a standard modern gamepad you have…

6 analog input axes: two x/y pairs and two stand alone (for the analog shoulders).
14-ish digital buttons. d-pad(4), select, start, a,b,x,y,r,l,analog stick1, analog stick 2.

Make any device you want that has 6 analog inputs and 14 buttons of any shape or size. From the time the clock starts until it ends, the inputs may only send a signal matching their current state, and their state may only be changed via human intervention. Without human intervention, they must send a neutral/off/0 signal. Special extra rules may apply if the original system has other limitations (maximum number of simultaneous inputs, invalid input combinations, etc.)

If those inputs happen to be accelerators, eye-tracking cameras, heart rate monitors, digital thermometers, it doesn’t matter. It might be hard for a thermometer to remain neutral, someone could stick it in the sun, but you get the point.

Moaning about Nintendo continually releasing a version of Mario 64 with bugs fixed seems weird. If this is the most-released and most-available, and speedrunning is the main activity with this game, why don’t the speedrunners treat it like a real game and find strategies for this specific release?

1 Like

Yeah thing is, certainly there will be speedruns for that version of Mario. And being on that platform even if it was the original version, I’m pretty sure the times still won’t be put in the same ranking against those done on the 64 as framerates and controllers will be different right? Console limitations are as much a part of what affects speed as anything else.

So it just means that this new version won’t mimic the wild strats that are known and loved by the community and that it probably means it won’t be as interesting to watch for people who are dialed into the esoteric nuances of the game’s speedrunning lore… Unless the new version gets played enough to develop its own nuance and depth and lore.

This same problem exists for pretty much any game that has had patches or re-releases. The earlier patches are almost always faster because they have more game-breaking glitches. They do setup separate categories for the different versions of the game, and people do run them all. However, whichever version is the most broken and has the fastest times ends up being the one that people care about the most.

If you have a v1 and a v2 of a game where v2 fixes some bugs, the v2 world record run is very likely to also be possible in v1. However, the v1 world record run won’t be possible in v2. Therefore the v2 world record run ends up not being of much interest because the world record in v2 is identical to a failed v1 run.

Sort of like how whenever people try to achieve new vehicle land speed records they always go to the salt flats in Utah. I’m sure there are world land speed records on asphalt, concrete, and other less-flat and less-big surfaces. But nobody really cares who has those records because the salt flat records are the fastest of them all.

Nintendo sells gamers best, most bug-free version of Super Mario 64. Thanks, Nintendo!

Including the original, glitch-filled Super Mario 64 is how Nintendo can actively preserve the game’s legacy.

:laughing:

1 Like

Yeah, I know all the reasons why people are complaining. But sometimes technology moves on.

Do they want to make everyone who wants to take up speedrunning buy an N64 and a crt monitor? Buy N64 controllers? Or do they want people to buy… a three pack of games for the Switch they already own.

Why not make it as accessible as possible?

Also, this is like Formula 1 teams complaining that they can’t use the same engines as 10 years ago. Of course not. The engines now are hybrids, with the idea that the technological advances influences production car designs. The sport has to stay relevant technologically. That’s why even Indycar is going Hybrid in a few years time.

Keeping a hobby/sport relevant is how it grows and thrives, not restricting participation to 20 year old hardware.