By Quentin H. / February 4th, 2020
There are two types of speedrun categories: speedruns done by humans (which comprised almost all of the speedruns at AGDQ 2020 that oprainfall attended last month) and tool-assisted speedruns. At AGDQ 2020, I met up with Allan Cecil, who is the keeper and spokesperson for TASBot. After AGDQ was done (raising over three million dollars in the process), we wound up talking a short period after the event about all things TASBot and tool-assisted related.
In Part One of this two-part interview, Allan Cecil and I talk about what a tool-assisted speedrun is and how they are still in fact speedruns, how the community decides upon the rules for tool-assisted speedruns, and both the history of tool-assisted speedruns (and TASBot in particular) at Games Done Quick Events and how runs are selected for these events. In Part Two, which is coming soon, we talk in depth about the Super Mario Maker 2 TAS run that premiered at Awesome Games Done Quick 2020, the future of TASBot, and more.
You can find out more about Allan Cecil and TASBot at their official website, by tweeting at them on Twitter, following on Reddit, chatting on the official Discord, subscribing on Twitch and on YouTube, and at their Patreon page.
You should also check out the official TASVideos website.
Finally, you can find out more about the Prevent Cancer Foundation at their official website, on Facebook, on Twitter, on linkedin, on Pinterest, on Instagram, and on YouTube. And you should definitely go donate now.
This interview has been edited for clarity and content.
Operation Rainfall: My name is Quentin H. with Operation Rainfall, and you are?
Allan Cecil: I am Allan Cecil, also known as ‘dwangoAC’.
OR: What is a tool-assisted speedrun?
AC: A tool-assisted speedrun is, as lame as it sounds, a speedrun where the human is assisted by using tools. The best definition of this is placing a game inside an emulator and using tools to play the game at a different speed. You can play a game in slow motion to make it easier to hit enemies.
But that’s not quite as interesting as it could be. So let me try this again.
A tool-assisted speedrun is usually a sequence of button-presses being recorded in an emulator that is showing a completion of the game as perfect as possible. In other words, removing human skill and reflexes and other limitations such as memory, and using tools to assist a human to produce a perfect speedrun of the game.
“And that is a funny way of saying [that] when you’re making a tool-assisted speedrun, the expectation is that the result will be perfect or very-nearly perfect. Because you have an infinite number of chances to go back and try again, the expectation is that it is a very high quality effort. That your movement is as perfect as possible, that you’re not making mistakes.”
OR: And what is TASBot, exactly?
AC: TASBot is taking a tool-assisted speedrun, made in an emulator, and playing it back on a real console through a sequence we call ‘console verification’. It’s very similar to a player piano. If you’ve ever seen an old player piano, with a piano roll in it- it’s a roll of paper with perforations or holes that, when played through a player piano, plays back a pre-defined sequence of notes and plays back an entire song.
TASBot is doing almost the same thing, but instead of playing back a sequence of notes, he’s playing back a sequence of button presses.
OR: Now you’ve connected to TASVideos.org. What is that website and what role do you play with them?
AC: TASVideos.org is a website that contains a large number of tool-assisted speedruns. I am the ambassador on staff for TASVideos.
OR: At Summer Games Done Quick 2018, you [hosted] a panel and said “A TAS is nothing more and nothing less than a scripted series of buttons to press on a controller.” How are TAS runs still speedruns, if they are just scripted?
AC: I would say that a speedrun is an attempt to complete a game as fast as possible, using any means. And when using human skill, you can become very, very fast at a particular game that you’ve practiced. But you could never be perfectly fast. A human real-time attempt at speedrunning a video game is pressing the limits of a human. A tool-assisted speedrun is still very much a speedrun, pushing the limits of the game.
So I would answer by saying that a tool-assisted speedrun is as perfect as possible, within the limits of the coding of the game.
OR: How do you build a speedrun?
AC: Patience. *laughs* Lots and lots of patience.
So you make a tool-assisted speedrun by sitting down with an emulator of a video game console. And you start recording the button presses that you’re sending to the game. At any time, you can create a save state- a snapshot in time of the game’s state. Every byte in memory, every register in the CPU, everything that is happening in the game. Everything is saved. You can then play from that point, and if you make a mistake or you don’t like the outcome, you can load that state and go ‘back in time’. You can keep rocking back and forth in time and trying different techniques to complete the game. And if you find a section you like, you can save a new save state and proceed from there. And you go through this process of doing what we call ‘re-records’ every time you restore a state and save again. And you go through this process over and over again, and with enough persistence and time and effort, you will eventually get to a point where you’ve completed the entire game to a level of a quality that is sufficient to submit to the website.
And that is a funny way of saying [that] when you’re making a tool-assisted speedrun, the expectation is that the result will be perfect or very-nearly perfect. Because you have an infinite number of chances to go back and try again, the expectation is that it is a very high quality effort. That your movement is as perfect as possible, that you’re not making mistakes.
“And ultimately, what we showed at AGDQ 2014 was tool-assisted speedrun content being played back on real hardware.
But there was one piece missing that I really wanted. I wanted to have a mascot, something that people watching this unnamed player could root for.”
OR: With TAS, there are self-imposed restraints that the community places on themselves such as only connecting to exposed ports and not interfering with communication between the game cartridge and the console. And there are games-specific limitations such as not pressing left and right or up and down simultaneously in Super Mario Bros. 3.
How does the community decide what limitations to set on themselves when a new game comes out?
AC: There’s two answers for that. In the context of a tool-assisted speedrun, made on an emulator, the emulator might allow left and right or up and down on a game that ordinarily wouldn’t. Sometimes, that input is still being processed by the game engine even though it isn’t apparent. And sending those button presses results in unexpected behavior. A good example is The Legend of Zelda: A Link to the Past, where pressing left and right at the same time while going up a staircase can cause a glitch. Some runs are in a category that don’t allow those types of major glitches. So sometimes, the runners know about them and they agree to not use those glitches.
Other times, there are limitations that are hard limits, so we can’t press left and right at the same time. A good example of that is that we once did a run with the Super Game Boy. The input is completely stripped so we cannot use it- left and right button presses never arrive at the game. So sometimes there are hard limitations that prevent that kind of thing. But in most cases, it’s just part of the category. This category is a ‘no-save-state corruption’ category. Or things like that.
OR: How do you check to make sure that people aren’t ‘cheating’ at the TAS-run?
AC: You need to define ‘cheating’ in this context.
OR: So that they aren’t breaking the rules, so to speak. Is there any way to check what their TAS does, the button presses? Is that required to be disclosed?
AC: So the only time you could cheat is if you modified the game. I’m going to talk about FINAL FANTASY for a second, as a very good example.
In the game FINAL FANTASY made by Nasir [Gebelli], there are certain glitches that the community is aware of. One of them is that on the easternmost peninsula, there are four squares where you would get encounters that should be for an entirely different section of the game. Due to a programming oversight, those four tiles or squares on the map result in fights that are much harder than anywhere else in that island. There are enemies that you shouldn’t encounter until much later in the game. Nasir wrote FINAL FANTASY and released it on the cartridge. And the game works exactly as he wrote it. It doesn’t necessarily work exactly as he thought it would work. And so there are often times glitches in the game that real-time runners will exploit in attempting to do a speed-run. A tool-assisted speedrun is no different. The only time you wind up with a situation that’s considered ‘cheating’ is if you modify the game. A tool-assisted speedrun is about playing the game at the very limits of how it was coded. In other words, Nasir did not know these glitches existed when he released the game. But they are in fact in his released game. And we’re playing by those rules, we are not modifying these rules in any way.
The only time you would consider a run to have ‘cheated’ is to use a Game Genie [to] modify the actual state of the game or to how the game worked or how the values of addresses in memory are stored. So a tool-assisted speedrun generally can’t cheat. But having said that, there is something that is a concern. And that’s when someone uses tools to assist gameplay in a speedrun and passes it off as a human effort. That’s a big problem, we don’t ever want to see that happen.
Tool-assisted speedruns can be used to help validate -or void- video game record runs. One such example is how, through the work of ‘Omnigamer‘, Todd Roger’s world-record time of 5.51 for the Atari-classic Dragster was proven to be impossible to produce and therefore caused his record to be stripped after thirty-odd years. This linked video shows TASBot performing the lowest possible score of 5.57.
OR: You recently showed off TASBot at Awesome Games Done Quick 2020. What has the history of TASBot been like at Games Done Quick Events, and what was the community reception like?
AC: In 2013, I ‘dwangoAC’ -the person- knew about Games Done Quick charity events, and I really wanted to go to one of them and participate. But I quickly discovered that I could not use my own human skill to do so. I attempted to practice the game Scribblenauts Unlimited to become good enough to submit as a run, but I discovered rather rapidly that I did not have the requisite skills. But I still wanted to do something. And I got the idea of submitting a tool-assisted speedrun to the event. I was, at the time, not on [TASvideos.org] staff, but I had been discussing in the speeddemo archive forums back in 2013 where that was the main location of discussion.
And I offered to show up and play back tool-assisted speedruns. And there were a few people on the committee that thought that was a good idea. I ultimately started working with a large group of people to make a replay device specifically for AGDQ 2014. I worked with someone named ‘true’ to make a physical board that we could use to connect to a Nintendo console to play back content. I worked with ‘micro500’ to do the same thing for the Nintendo 64. And ultimately, what we showed at AGDQ 2014 was tool-assisted speedrun content being played back on real hardware.
But there was one piece missing that I really wanted. I wanted to have a mascot, something that people watching this unnamed player could root for. And ‘Adelikat’, who is the main admin for TASVideos.org, suggested a ROB robot base. And I took that, combined it with LEGO and a Raspberry Pi, and I called it ‘ROBberry Pi’. And ‘Mecha Richter’ on the SDA forums totally ignored my name and said “I’m looking forward to this TASBot action!”. The name stuck, so we ended up with this mascot called TASBot. And at AGDQ 2014, ‘Masterjun’ showed off some really amazing content where he took over Super Mario World and started playing Pong and Snake with Mario’s head. It was just so crazy. I would say that our first year really set the tone for everything that came after. It solidified TASBot as a mascot representing a large tool-assisted speedrun community of TAS authors and device makers and creators in general.
It was a way for us to show art at a live event. And the rest is history.
‘micro500’, who developed one of the first TAS devices to be used at a GDQ event, has contributed runs (along side other TAS runners such as ‘xy2_’) for other TASBot showcases.
OR: The TAS Community has been putting on showcases at AGDQ and SGDQ for several years now, including forcing a live IRC Twitch chat into a Super Game Boy to play Pokémon Red and playing a version of Super Mario Maker in Super Mario World in 2016.
How does the community decide what they are going to show off at an event, and how far in advance are these decisions made?
AC: The very first TAS content shown at an event was at SGDQ 2011 when ‘DarkKobold’ took ‘micro500’‘s NESbot device in a shoebox with wires connected to a breadboard and shows Wizards and Warriors III, I think. And it desynchronized- it didn’t go well. And no TAS content was shown again until I led the effort for AGDQ 2014. I’ve led the content selection process for all of the TAS content at GDQ events since that time. So I, ‘dwangoAC’, have been at twelve different events as the organizer and presenter [to] show art content made by a large number of other people.
In general, until recently, I was solely picking the content myself. I was working with content creators, asking them if we could show their content, or in some cases taking advantage of the Creative Commons Attribution Clause of TASVideos and showing runs for content creators who were no longer on the site. And that was good. But as TASBot content grew, it reached a point where we were unable to keep up with the volume. In 2019, I led seven different events across a couple different continents, and it was simply too much work. And so I am, as of right now, moving to a committee model where I’m bringing in other people to assist me in content selection and in identifying runs that are a good fit for Games Done Quick.
We’ve also moved to a model, in the last year, where all of the content we’re showing was picked prior to the Games Done Quick submission process- or ESA [Marathon] or RPG Limit Break. The reason for that is that we need to rehearse commentary for providing good entertainment to viewers. We want to make sure that we have enough time to fully work out what commentary we’re doing and work out any technical issues we have, so everything runs smoothly. So at this point, we’re picking content months in advance of any event.
The first TAS run at a Games Done Quick event was by DarkKobold for the NES title Wizards & Warriors III.
What do you think of tool-assisted speedruns, and what games are your favorite to see played via TAS?
What do you think of TASBot appearing at multiple Games Done Quick events a year?
Let us know in the comments below! And please look forward to Part Two of this interview later this week!
AGDQAllan CecilAwesome Games Done QuickGDQspeedrunTASTASBotTool-assisted speedruns