So from what I understand, TAS are created by adjusting controller inputs frame by frame, either by hand or with the use of scripted inputs to record a series of inputs which are played back in real-time in the game. This method seems to require a stable emulator to work well and every input is determined in advance.
My question is, is this the only means of doing a TAS?
Has anyone attempted to use feedback from the audio or video in the game to change the series of inputs that will be executed in real-time?
I know there are means to manipulate RNG in a lot of games to not require this, but i'm sure there are some games where the RNG is too sophisticated to manipulate consistently.
Also is it possible to use scripted inputs on real hardware using a controller interface and not require emulation?
Just curious if anyone has explored these options or if they are just seen as unnecessary or inferior?
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Hello Rapatap, welcome to TASVideos!
TASs are primarily made and played back using emulators, created by people looking at the game's memory, and at standard audio and video output to figure out how to go forward.
Sometimes we have computer programs analyze a game and create favorable results for various segments.
Please see our intro page for more details: http://tasvideos.org/WelcomeToTASVideos.html
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
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.
Oh I see, I think I have misunderstood the procedure a little bit. So you are saying that the frames that make up the final TAS video are recorded as the run is created, not in a replay of the game where the input sequence is fed into the game in real-time after the fact?
I had watched the "TASbot" segment of AGDQ and noticed they had issues with console desync and things like that and was curious if anyone had tried using some sort of hardware based audio/video feedback with code to auto-correct things like desync, but i'm guessing most TAS aren't done the way that was demonstrated.
Also, if that is the case, is console verification even considered important then?
So you are saying that the frames that make up the final TAS video are recorded as the run is created, not in a replay of the game where the input sequence is fed into the game in real-time after the fact?
No, encodes are recorded from the completed TAS movie (unless the TASer makes a screen recording of the TAS creation itself, but that's a separate topic).
Rapatap wrote:
I had watched the "TASbot" segment of AGDQ and noticed they had issues with console desync and things like that and was curious if anyone had tried using some sort of hardware based audio/video feedback with code to auto-correct things like desync
Emulators are used because they allow resetting the system to a previous state very easily; with real hardware the most you can do is pressing the Reset button (if there is one) or cut the power. So experimenting becomes very time-consuming, especially with long movies. And finally, when a desync is detected (which in itself might not be trivial), increasing the number of frames that need to be changed and tested increases that time investment geometrically. (E.g. testing 1 frame is <number of buttons> possibilities, 2 frames is <number of buttons>² possibilities etc.)
Rapatap wrote:
Also, if that is the case, is console verification even considered important then?
It's very important to make sure that the tricks don't depend on emulator bugs, which would make the run feel "artificial" (imo).
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Rapatap wrote:
Oh I see, I think I have misunderstood the procedure a little bit. So you are saying that the frames that make up the final TAS video are recorded as the run is created, not in a replay of the game where the input sequence is fed into the game in real-time after the fact?
Correct.
Although we do the latter when creating normal (MP4, MKV) movie files.
Rapatap wrote:
Also, if that is the case, is console verification even considered important then?
In my opinion, it's not that important, as I view these things more theoretically, and care about multiple compatible platforms, and less about the reference implementation. However others, do find it quite important.
In any case, out of our current 2758 published movies 79 of them have been console verified.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Oh I see, I think I have misunderstood the procedure a little bit. So you are saying that the frames that make up the final TAS video are recorded as the run is created, not in a replay of the game where the input sequence is fed into the game in real-time after the fact?
Correct.
Although we do the latter when creating normal (MP4, MKV) movie files.
Alright, so then are there some games in which upon replay desync is either inevitable or there are RNG elements that cannot be manipulated?
Joined: 3/9/2004
Posts: 4588
Location: In his lab studying psychology to find new ways to torture TASers and forumers
Rapatap wrote:
Alright, so then are there some games in which upon replay desync is either inevitable or there are RNG elements that cannot be manipulated?
Replay in most emulators rarely if ever suffers from a desync.
The issues with desyncing of an emulator run played back on a console is generally when the emulator implemented something slightly differently than the console, or that the emulator is deterministic, and the console for whatever area the game makes use of is not.
Although in the case at AGDQ, desyncs were because electrical interference was causing the data traveling over the controller wires to be altered.
Warning: Opinions expressed by Nach or others in this post do not necessarily reflect the views, opinions, or position of Nach himself on the matter(s) being discussed therein.
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
TASing emulators provide determinism as reliable as possible, so RNG is the same every time you replay the movie, given all sync-related conditions are met (like emulator version, game version, there are also options that don't sync with each other, but provide perfect sync if you stick to one of them).
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.
Moderator, Senior Ambassador, Experienced player
(907)
Joined: 9/14/2008
Posts: 1014
Just to throw it out there, yes, the issues we ran into at the marathon were largely due to electro-magnetic interference, and most of that was caused by using the metal rolling cart that was shaped vaguely like a rooftop antenna and performed about as well as one as far as I could tell from how awful it was when we were around it. We realized something was amiss when we started testing with our equipment on the cart and even in the hotel room we were getting desyncs - moving everything to a desk helped, and wrapping the controller cables in tinfoil (placed between gaffer's tape) made an even bigger improvement.
A lot of our problems stem from the fact that we're pushing *far* more data across the cables than they were ever designed to handle, and the lack of any kind of retransmission method means that if we have even a single bit wrong the whole thing usually unravels. What we're doing in the TASBot block / console verification arena is a far cry from the typical methods of using an emulator and savestates to create the perfect emulator-based movie. But, I'm now rambling, so I'll be quiet now. :)
Yeah I understand what happened. After watching it though, I was really curious if anyone had explored any methods of hardware or software based error correction for this type of problem or other problems based on non-deterministic game play mechanics.
Joined: 4/17/2010
Posts: 11475
Location: Lake Chargoggagoggmanchauggagoggchaubunagungamaugg
Rapatap wrote:
Yeah I understand what happened. After watching it though, I was really curious if anyone had explored any methods of hardware or software based error correction for this type of problem or other problems based on non-deterministic game play mechanics.
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.
