Joined: 10/27/2004
Posts: 1978
Location: Making an escape
It goes back further than that. Morimoto's thing was the first one to reach any degree of popularity.
Generally, credit is given to DOOM.
(this post in response to a now deleted post)
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.
http://www.youtube.com/Noxxa
<dwangoAC> This is a TAS (...). Not suitable for all audiences. May cause undesirable side-effects. May contain emulator abuse. Emulator may be abusive. This product contains glitches known to the state of California to cause egg defects.
<Masterjun> I'm just a guy arranging bits in a sequence which could potentially amuse other people looking at these bits
<adelikat> In Oregon Trail, I sacrificed my own family to save time. In Star trek, I killed helpless comrades in escape pods to save time. Here, I kill my allies to save time. I think I need help.
Depending on how you consider it, anytime someone makes a speedrun using hardware that's not quite up to the task of running the game and responds by slowing down, they could arguably be making a tool-assisted speedrun. That would probably push the date back to, oh, maybe the mainframe days and games like Colossal Cave and Rogue.
They'd probably be unable to record and distribute the run though, so if you consider that a prerequisite then I suspect that Doom is your answer.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
It really depends on your definition of "TAS".
TAS-Doom used many of the same techniques as modern TASes, but one major difference was that it was not run on an emulator and the game itself was hacked (iow. rather than the TAS tools being added to an emulator, they were added to the game code itself, which was then run natively). That would make it ineligible for publication at tasvideos.org.
Morimoto's SMB3 run was most likely not the very first "modern-style" TAS ever made, but it was certainly the first one to gain popularity (and basically the reason why this site exists).
It would not make it ineligible for publication if the movie syncs back with original game code.
Example:
http://tasvideos.org/1673S.html
The TAS was made using hacked ROM (built-in Lag Counter tool, which was then implemented in emulators a year after that).
So Doom TASes were quite similar to modern TASes.
I suppose you are right.
On the other hand, it then becomes a question whether a game's own internal recording format, rather than an emulator's one, is acceptable or not.
(Why wouldn't it be acceptable? IIRC for example Quake demo files do not actually contain key presses but timestamps with player and NPC/object coordinates. The game just puts the camera and all the NPCs and objects to those coordinates at those times. This would easily allow creating a run that's impossible in real-time, for example the player being at the starting spawn point in one frame and in the level's exit at the next frame. I don't know how Doom demo files work, but I'm assuming they are similar.)
The good thing about emulator keypress files is that there's no way of "cheating" and making the game do something that's impossible: They are just timed keypresses, nothing else.
Even before the doom source code release, you could run special TSRs while recording a demo (in the original executable) that could give "slow-mo" capabilities by screwing with timing. These demos would generally sync when played unaltered. I'd guess this was as early as 1996 or before; I know it was a topic of discussion at Compet-N (a website which hosted unassisted demo replays) early in that site's history.
Even before the doom source code release, you could run special TSRs while recording a demo (in the original executable) that could give "slow-mo" capabilities by screwing with timing. These demos would generally sync when played unaltered. I'd guess this was as early as 1996 or before; I know it was a topic of discussion at Compet-N (a website which hosted unassisted demo replays) early in that site's history.
Oh, right, DOS extenders! And slowdown wasn't the only tool available at that time. I also remember playing DOS Lost Vikings in 1998 using Game Wizard 2.0x which allowed saving and loading anytime without crashes, that was incredible. Although it didn't work with games that used protected mode of i386, so no Doom or Quake.
Now that I've searched a bit, it seems like in 1993 there already was similar tool called GameBuster 4.0:
http://gamehacking.cs1.dlh.net/tutorials/toolsstory.php wrote:
Kingformation in 1993 sold GameBuster 4.0 by Neil Ho. This utility was really interesting for three reasons: it was capable of saving the entire machine status, so gave us support of load and save for all that games who does NOT supported load and save functions; it supported a 'magic window': in other word, it was able in splitting the monitor in two windows: one was for the game, and the other was for gamebuster, simultaneous; it had the capability of automate modifying code, f.e. setting to nop, nop, nop all processor instructions who f.e. decremented our life.
It's commonly thought that the Doom TASes were the first ones, but the first one was actually done by me in Sonic 1 already in 1991, which is a couple of years earlier. The game has debug mode you can access with a button code which gives you some TAS capabilities, such as frame advance.
I'm sure at least some of the pre-game arcade game demos are TASes. I mean the demos played while "Insert coin" is flashing on the screen.
I tried to remember a single one that wasn't average at best, and even asked some of the knowledgeable people, but couldn't find any. I'm sure none of them were deliberately played close to the limits—let alone above—of human abilities, because that wouldn't look inviting for newcomers.
Warp wrote:
Edit: I think I understand now: It's my avatar, isn't it? It makes me look angry.