Glossary
Glossary
Here you can find definitions for many terms that are used throughout this Manual. Most of them were used in the context of TASing before TAS Editor was created. Some of those terms are described more thoroughly in the Beginner's Guide.
It's recommended to read the Glossary at once, because many terms are interconnected.
Input
Data about player's actions, that can be received by a game.
TASing became feasible because of general assumption that behavior of a game is always determined by its initial state and player's input, and nothing else (see Determinism).
Examples of Input: pressing a button on a gamepad, pushing analog stick, touching by stylus, shouting into a microphone, etc.
Taseditor works with Input in the form of "sequence of buttons states".
Note: the fact of player not pressing any button is also considered an Input.
Output
Data sent from a game as a result of processing player's Input.
The process of playing a game can be depicted as a loop of interaction between a subject (player) and an object (game).
Examples of Output: displaying an image, producing a sound, vibrating gamepad, changing the value of an observed RAM address, providing an information about lag, etc.
Playthrough / Walkthrough (Solution)
A sequence of player's actions needed for successful completion of the game.
This sequence is inputted into the game using an input device (e.g. gamepad). The sequence can be either performed live (created in real-time) or constructed in advance in a form of reproducible recording (e.g. log of button presses). The latter form allows editing of the sequence.
Speedrun
A walkthrough aimed on fastest completion of the game.
Some games have build-in "Speedrun" or "Time Attack" mode, where the game counts the time spent while playing. For other games it's possible to use external timer, measuring time in seconds or TV frames.
TAS (Tool-Assisted Superplay / Tool-Assisted Speedrun)
A walkthrough made with use of tools for editing the sequence of player's actions.
The process of creating TASes is called "TASing", authors are usually called "TASers".
The Input editing exempts TASers from certain human limitations (e.g. slow reflexes), allowing to spend full energy on making extraordinary walkthroughs. It can be either speedruns or entertainment videos (playarounds).
TASes can be distributed:
Movie (replay)
Container for storing Input and associated data.
Unlike video containers, the TAS movies don't contain Output (game footage). The Output appears only when user applies the movie Input to an appropriate game file.
Lag
The term used when the delay between Input and Output is greater than normally.
The loop of interaction between player and game usually establishes some fixed amount of time between polling Input and updating Output, for example 60 times per second.
A computer processor can only make fixed amount of operations in this fixed amount of time. But videogames try to mimic the unboundedness of real life, so the quantity of in-game objects may vary greatly. Thus it's possible that processing all objects will take more time than allotted. In such cases the Output update will be delayed, and next Input polling will be delayed too.
Speedrunners try to avoid excessive delays, and the lag is often considered as a factor when TASing. Usually TASers try to minimize the number of "frames containing lag".
Emulators can detect lag in a frame right after finishing the frame emulation. The criterion is simple: if the game didn't poll Input during the frame then it's the lag frame. If it did poll Input then this is normal frame. Taseditor highlights lag frames with red color, and it's useless to draw any Input on these frames.
Desync
Discrepancy between expected and received Output, which results in player's Input not syncing with the logic of the game.
Desync may appear when the Input made for one game is applied to another game, or using different emulator version or different settings. Also, desyncs appear when emulator doesn't support deterministic emulation.
Segment
A part of the movie, representing the period of time between two in-game events.
Breaking the movie into segments is used to decompose big tasks to smaller subtasks.
The size of a segment can be measured in frames, but the limits of a segment are usually defined by in-game events. The beginning event cuts all previous tasks and concentrates TASer's attention on the nearest set of conditions. The ending event serves as an optimality criterion for all possible approaches to the current task solution.
More: TASing Process
Optimization
The process of searching for the optimal (the best) solution of the task in current segment.
Almost any task in videogames can be solved in a variety of ways. Every way has its own pros and cons. When starting a project, TASer chooses his goal (e.g. pacifist speedrun), thus assigning priorities to those pros and cons, therefore all the ways of solving a task can be evaluated and compared to each other to determine which one is better.
Actual process of TAS optimization consists of editing Input and evaluating resulting Output. When TASer gets better result, he marks current Input as the best, until he finds an even more optimal Input. The final product (TAS movie) contains the best solution for every subtask.
More: TASing Methodology
Improvement
A way to solve the task better (closer to optimum).
Examples of improvements in speedruns: removing inaccuracy, applying unused timesaver, increasing the usefulness of an old timesaver, adding entertainment without losing speed.
Timesaver
Any in-game trick that can save time.
When making a speedrun, TASer is supposed to use every unprohibited opportunity to make the walkthrough become as fast as possible. One thing is polishing the Input to find the best outcome from current knowledge about the game. Another important activity is expanding this knowledge base – finding and applying tricks. True TASer strives to gather the maximum information about the game and use all known tricks to full extent, so that his record wouldn't be easily beaten.
Examples of timesavers: features of the game, bugs of the game, luck manipulation.
Note: sometimes TASers deliberately refuse certain timesavers, in this case the TAS aims for extra category. Examples: Super Mario Bros TAS without using B button (denying certain feature of the game), Sonic the Hedgehog TAS without zipping (denying certain bug of the game).
Feature
An intended aspect of the game.
Some features are unimportant (or even unnoticeable) for an ordinary player, but substantial for a TASer. So, before optimizing Input it's recommended to research the game engine.
Examples of such features: damage boost, forced waiting for score countdown, coordinate subpixels, AI peculiarities, etc...
Bug / Glitch
An unintended aspect of the game.
Bugs abused by TASer should be reproducible on real console (at least theoretically). Bugs caused by emulation are not permitted.
Many bugs are discovered during real-time play. Some of them require thorough research and disassembly of the game code.
Examples of bugs: simplistic collision detection system, not checking save data corruption, race conditions, mistake in the order of checks, etc...
Luck Manipulation
Unrestricted exploiting of certain game features, which are normally limited by the shortage of player's knowledge.
Although any experiments with Input modification are manipulations of game features, but some aspects of games appear especially unpredictable for an ordinary player. Developers intentionally entangle algorithms of those features, so that for a naked eye they seem completely random and uncontrollable.
However, in deterministic world all aspects of videogames are predictable (defined by Input). Using tools and careful analysis you can reveal those hidden laws and dependencies, and then use the knowledge when creating the Input. And sometimes you don't even have to dissect algorithms, when you can use trial-and-error method.
More: Nonlinear TASing (example of luck manipulation)
Subpixels
The term used when in-game objects have coordinates with fractional parts.
Generally, there's difference between on-screen coordinates of a sprite and in-game coordinates of the object this sprite represents. In some games those coordinates have the same scale and their values coincide, but usually on-screen images represent a rough outline of the real state of things. So, to get max precision TASers observe the memory of emulated console, using Memory Watch tool or custom Lua HUD. This way also allows to see hidden variables of the game, those that aren't displayed on screen normally.
Recording
One of possible ways to create Input for a movie.
It consists of appending new Input sequentially to the end of current movie, while watching interim results of the Input.
Another way would be drawing Input directly in the movie.
More: Toolbox, TASing Methodology, Traditional TASing
Rerecording
One of possible ways to edit Input in a movie.
It consists of rewriting old Input sequentially from starting frame to ending frame, while watching interim results of the Input changes.
Another way would be direct modification of existing Input in the movie.
More: TASing Methodology, Traditional TASing, Rerecords counter
Multitracking (multi-track recording)
One of ways to record Input for a walkthrough of the game in multi-player mode.
It consists of recording Input for a segment of the movie by taking turns for every player separately.
Another way would be recording Input for all players simultaneously.
More: Toolbox
Frame Advance
Step-by-step emulation of a game using the minimum units of measuring time – frames.
Used for manual control of progression of time. Considered to be more effective replacement to "slow motion".
Turbo (turbo speed)
The feature of speeding up emulation to the maximum possible speed.
Used for skipping meaningless in-game events and reducing waiting time when the emulator is seeking.
Most emulators allow to customize emulation speed, slowing it down or speeding up when needed. Turbo speed means the fastest speed possible, which is only limited by your computer speed.
More: Toolbox, Nonlinear TASing, Semiautomatic TASing
Savestate
A snapshot of the emulated system's state at that current moment.
Unlike in-game saves, a savestate contains all the comprehensive data on the state of emulated hardware.
Piano Roll
A medium for visual representation of data, similar to table or grid view.
The interface is used in many music editing programs (MIDI sequencers and MOD trackers). Its name and basic concept was derived from existing storage medium used to operate a mechanic piano (paper rolls).
Taseditor's Piano Roll displays current movie data (Input and Markers) and allows to edit the data by mouse clicks. It also displays auxiliary information like pointers, Bookmarks, Lag log, etc.
Every row of the Piano Roll corresponds to one frame of the movie.
More: Piano Roll, Piano Roll specs
Playback cursor
Pointer to currently played frame of the movie.
Events of this frame are displayed in emulator's main window as current screenshot. Piano Roll marks respective row with light-blue color and the "Play" symbol (light-blue arrow).
Only one frame of the movie can be seen at any given moment. To see the screenshot of upcoming events you'll have to move the Playback cursor forward (down in the Piano Roll). To see the screenshot of previous events you'll have to move the Playback cursor backward (up in the Piano Roll).
More: Piano Roll, Playback cursor Navigation
Greenzone (access zone)
The storage designed for speeding up Playback cursor navigation.
This storage automatically collects savestates for all emulated frames of the movie, and when it's necessary to rewind or jump forward to a frame, Taseditor loads respective savestate from Greenzone.
More: Toolbox, Program Customization, Greenzone specs
Selection
Set of rows in the Piano Roll that are highlighted by special color (usually dark-blue).
Any row of the Piano Roll (and thus any frame of the movie) can be either selected or not selected.
Selection allows to operate with many frames at once, for example, delete a whole section of the movie at once instead of deleting every single frame in it.
The upper row of the Selection is called "Selection cursor".
The Selection cursor automatically follows the process of Input editing.
More: Piano Roll, Selection cursor Navigation
Marker
Yellow mark for a row in Piano Roll that emphasizes the frame among its neighbors.
Any row in the Piano Roll can be marked. Markers allow to improve the distinctness of movie data.
Markers can be used to:
More: Piano Roll, Markers specs
Note
A single line of text accompanying every Marker.
More: Piano Roll, Controls, Advanced Features
Bookmark
A numbered mark for a frame of the movie.
Taseditor has 10 slots for Bookmarks.
A Bookmark stores all necessary data about the frame it was placed on. Including the movie branch that contains an Input that definitely leads the game to the events of this frame.
Bookmarks can be used for Playback cursor navigation, but their main purpose is to store branches.
More: Toolbox, Bookmarks specs
Branch
A full copy of the movie, storing its state at the moment of creating the Bookmark.
The current movie can be replaced by the branch when necessary, thus restoring saved state of the movie.
With branches you can have many different movies in one project, and you can instantly switch among them:
More: Toolbox, Program Customization, Branches specs
Project
Container for storing working data in Taseditor.
More: Advanced Features
Lua
Programming language used in many TAS-friendly emulators.
Useful for making custom tools and for data visualization.
More: Advanced Features, Lua, Lua API
Bot (robot)
A program made for automation of a specific task.
Bots are created to free humans from tedious work that doesn't require high intelligence. Unlike humans, bots don't invent the solution, they just methodically test all possible approaches within given limits, following an algorithm made by the programmer.
Nowadays bots are only practical for running exhaustive search within a very small segment of the movie. Most of time it's faster to search for best solution manually, using human intuition to eliminate dead ends without unnecessary tests.
Making bots requires programming skills. TASing bots are either written in Lua or built-in into emulators by modifying an open source code.
Pattern
A predefined sequence of Input values for a button.
More: Advanced Features, Patterns specs
Created with the Personal Edition of HelpNDoc: Free EBook and documentation generator