<pclass="rvps10"><spanclass="rvts21">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 </span><aclass="rvts27"href="BeginnersGuide.html">Beginner's Guide</a><spanclass="rvts21">.</span></p>
<pclass="rvps10"><spanclass="rvts21">It's recommended to read the Glossary at once, because many terms are interconnected.</span></p>
<pclass="rvps10"><spanclass="rvts21">Data about player's actions, that can be received by a game.</span></p>
<pclass="rvps10"><spanclass="rvts21">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).</span></p>
<pclass="rvps10"><spanclass="rvts21">Examples of Input: pressing a button on a gamepad, pushing analog stick, touching by stylus, shouting into a microphone, etc.</span></p>
<pclass="rvps10"><spanclass="rvts21">Taseditor works with Input in the form of "sequence of buttons states".</span></p>
<pclass="rvps10"><spanclass="rvts21">Note: the fact of player not pressing any button is also considered an Input.</span></p>
<pclass="rvps10"><spanclass="rvts21">Data sent from a game as a result of processing player's Input.</span></p>
<pclass="rvps10"><spanclass="rvts21">The process of playing a game can be depicted as a loop of interaction between a subject (player) and an object (game).</span></p>
<pclass="rvps10"><spanclass="rvts21">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.</span></p>
<pclass="rvps10"><spanclass="rvts21">A sequence of player's actions needed for successful completion of the game.</span></p>
<pclass="rvps10"><spanclass="rvts21">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. a log of button presses). The latter form allows editing of the sequence.</span></p>
<pclass="rvps10"><spanclass="rvts21">A walkthrough aimed on fastest completion of the game.</span></p>
<pclass="rvps10"><spanclass="rvts21">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.</span></p>
<pclass="rvps10"><spanclass="rvts21">A walkthrough made with use of tools for editing the sequence of player's actions.</span></p>
<pclass="rvps10"><spanclass="rvts21">The process of creating TASes is called "TASing", authors are usually called "TASers".</span></p>
<pclass="rvps10"><spanclass="rvts21">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).</span></p>
<pclass="rvps10"><spanclass="rvts21">TASes can be distributed:</span></p>
<pclass="rvps10"><spanclass="rvts21">Container for storing Input and associated data.</span></p>
<pclass="rvps10"><spanclass="rvts21">Unlike video containers, the movies don't contain Output (game footage). The Output appears only when user applies the movie Input to appropriate game file.</span></p>
<pclass="rvps10"><spanclass="rvts21">The term used when the delay between Input and Output is greater than normally.</span></p>
<pclass="rvps10"><spanclass="rvts21">The loop of interaction between player and game usually establishes fixed amount of time between polling Input and updating Output, for example 60 times per second.</span></p>
<pclass="rvps10"><spanclass="rvts21">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 takes more time than allotted. In such cases the Output update will be delayed, and next Input polling will be delayed too.</span></p>
<pclass="rvps10"><spanclass="rvts21">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".</span></p>
<pclass="rvps10"><spanclass="rvts21">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.</span></p>
<pclass="rvps10"><spanclass="rvts21">Discrepancy between expected and received Output, which results in player's Input not syncing with the logic of the game.</span></p>
<pclass="rvps10"><spanclass="rvts21">Desync may appear when the Input made for one game is applied to another game, using different emulator version or different settings. Also desyncs appear when emulator doesn't support deterministic emulation.</span></p>
<pclass="rvps10"><spanclass="rvts21">Part of the movie, representing the period of time between two in-game events.</span></p>
<pclass="rvps10"><spanclass="rvts21">Breaking the movie into segments is used to decompose huge task to small subtasks.</span></p>
<pclass="rvps10"><spanclass="rvts21">The size of a segment can be measured in frames, but the limits of a segment are 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 for current task solution.</span></p>
<pclass="rvps10"><spanclass="rvts21">The process of searching for optimal (the best) solution of the task in current segment.</span></p>
<pclass="rvps10"><spanclass="rvts21">Almost any task in videogames can be solved in a variety of ways. Every way has its own pluses and minuses. When starting a project, TASer chooses his goal (e.g. pacifist speedrun), thus setting priorities to those pluses and minuses, so all the ways of solving a task can be evaluated and compared to each other to determine which one is better.</span></p>
<pclass="rvps10"><spanclass="rvts21">Optimization of a TAS consists of editing Input and evaluating resulting Output. When TASer gets better result, he marks current Input as the best until he finds even more optimal Input. Final product (TAS movie) contains best solution for every subtask.</span></p>
<pclass="rvps10"><spanclass="rvts21">A way to solve the task better (closer to optimum).</span></p>
<pclass="rvps10"><spanclass="rvts21">Examples of improvements in speedruns: removing inaccuracy, applying unused timesaver, increasing the usefulness of an old timesaver, adding entertainment without losing speed.</span></p>
<pclass="rvps10"><spanclass="rvts21">An in-game trick that can save time.</span></p>
<pclass="rvps10"><spanclass="rvts21">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.</span></p>
<pclass="rvps10"><spanclass="rvts21">Examples of timesavers: features of the game, bugs of the game, luck manipulation.</span></p>
<pclass="rvps10"><spanclass="rvts21">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 one feature of the game), Sonic the Hedgehog TAS without zipping (denying one bug of the game).</span></p>
<pclass="rvps10"><spanclass="rvts21">An intended aspect of the game. </span></p>
<pclass="rvps10"><spanclass="rvts21">Some features are unimportant (or even unnoticeable) for an ordinary player, but substantial for a TASer. So before optimizing Input it's recommended to make a research of the game engine.</span></p>
<pclass="rvps10"><spanclass="rvts21">Examples of such features: damage boost, forced waiting for score countdown, coordinate subpixels, AI peculiarities, etc...</span></p>
<pclass="rvps10"><spanclass="rvts21">An unintended aspect of the game. </span></p>
<pclass="rvps10"><spanclass="rvts21">Bugs abused by TASer should be reproducible on real console (at least theoretically). Bugs caused by emulation are not permitted.</span></p>
<pclass="rvps10"><spanclass="rvts21">Many bugs are discovered during real-time play. Some of them require thorough research and disassembly of the game code.</span></p>
<pclass="rvps10"><spanclass="rvts21">Examples of bugs: simplistic collision detection system, not checking save data corruption, race conditions, mistake in the order of checks, etc...</span></p>
<pclass="rvps10"><spanclass="rvts21">Unrestricted exploiting of certain game features, which are normally limited by the shortage of player's knowledge.</span></p>
<pclass="rvps10"><spanclass="rvts21">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.</span></p>
<pclass="rvps10"><spanclass="rvts21">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.</span></p>
<pclass="rvps10"><spanclass="rvts21">More: </span><aclass="rvts27"href="NonlinearTASing.html#turbo-seeking">Nonlinear TASing</a><spanclass="rvts21"> (example of luck manipulation)</span></p>
<pclass="rvps10"><spanclass="rvts21">The term used when in-game objects have coordinates with fractional parts.</span></p>
<pclass="rvps10"><spanclass="rvts21">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 even allows to see hidden variables of the game, that aren't displayed on-screen normally.</span></p>
<pclass="rvps10"><spanclass="rvts21">One of ways to create Input for a movie.</span></p>
<pclass="rvps10"><spanclass="rvts21">It consists of appending new Input sequentially to the end of current movie, while watching interim results of the Input.</span></p>
<pclass="rvps10"><spanclass="rvts21">Another way would be drawing Input directly in the movie.</span></p>
<pclass="rvps10"><spanclass="rvts21">One of ways to edit Input in a movie.</span></p>
<pclass="rvps10"><spanclass="rvts21">It consists of rewriting old Input sequentially from starting frame to ending frame, while watching interim results of the Input changes.</span></p>
<pclass="rvps10"><spanclass="rvts21">Another way would be direct modification of existing Input in the movie.</span></p>
<pclass="rvps10"><spanclass="rvts21">Step-by-step emulation of a game using the minimum units of measuring time – frames.</span></p>
<pclass="rvps10"><spanclass="rvts21">Used for manual control of progression of time. Considered to be more effective replacement to "slow motion".</span></p>
<pclass="rvps10"><spanclass="rvts21">The feature of speeding up emulation to the maximum possible speed.</span></p>
<pclass="rvps10"><spanclass="rvts21">Used for skipping meaningless in-game events and reducing waiting time when emulator is seeking.</span></p>
<pclass="rvps10"><spanclass="rvts21">Most emulators allow to customize emulation speed, slowing it down or speeding up when needed. Turbo speed means the fastest speed possible, which depends on your computer performance.</span></p>
<pclass="rvps10"><spanclass="rvts21">A type of visual representation of data, similar to table or grid view.</span></p>
<pclass="rvps10"><spanclass="rvts21">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).</span></p>
<pclass="rvps10"><spanclass="rvts21">Taseditor's Piano Roll displays current movie data (Input and Markers) and allows editing the data by mouse clicks. It also displays auxillary information like pointers, Bookmarks, Lag log, etc.</span></p>
<pclass="rvps10"><spanclass="rvts21">Every row of the Piano Roll corresponds to one frame of the movie.</span></p>
<pclass="rvps10"><spanclass="rvts21">More: </span><aclass="rvts27"href="PianoRoll.html">Piano Roll</a><spanclass="rvts21">, </span><aclass="rvts27"href="Ideas.html#PianoRoll">Piano Roll specs</a></p>
<pclass="rvps10"><spanclass="rvts21">Pointer at currently played frame of the movie.</span></p>
<pclass="rvps10"><spanclass="rvts21">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).</span></p>
<pclass="rvps10"><spanclass="rvts21">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 Playback cursor forward (down in Piano Roll). To see the screenshot of previous events you'll have to move Playback cursor backward (up in Piano Roll).</span></p>
<pclass="rvps10"><spanclass="rvts21">The storage designed for speeding up Playback cursor navigation.</span></p>
<pclass="rvps10"><spanclass="rvts21">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.</span></p>
<pclass="rvps10"><spanclass="rvts21">Set of rows in Piano Roll that are highlighted by special color (usually dark-blue).</span></p>
<pclass="rvps10"><spanclass="rvts21">Any row of Piano Roll (and respective frame of the movie) can be either selected or not selected.</span></p>
<pclass="rvps10"><spanclass="rvts21">Selection allows to operate with many frames at once, for example, delete whole section of the movie instead of deleting every single frame in it.</span></p>
<pclass="rvps10"><spanclass="rvts21">Upper row of the Selection is called "Selection cursor".</span></p>
<pclass="rvps10"><spanclass="rvts21">Selection cursor automatically follows the process of Input editing.</span></p>
<pclass="rvps10"><spanclass="rvts21">A numbered mark for a frame of the movie.</span></p>
<pclass="rvps10"><spanclass="rvts21">Bookmark stores all necessary data about the frame it was placed on. Including the movie branch that contains Input that definitely leads the game to events of this frame.</span></p>
<pclass="rvps10"><spanclass="rvts21">Bookmarks can be used for Playback cursor navigation, but their main purpose is to store branches.</span></p>
<pclass="rvps10"><spanclass="rvts21">A copy of the movie, storing its state at the moment of creating the Bookmark.</span></p>
<pclass="rvps10"><spanclass="rvts21">Current movie can be replaced by the branch when necessary, thus restoring saved state of the movie.</span></p>
<pclass="rvps10"><spanclass="rvts21">With branches you can have many different movies in one project, and you can instantly switch among them:</span></p>
<pclass="rvps10"><spanclass="rvts21">A program made for automation of a task.</span></p>
<pclass="rvps10"><spanclass="rvts21">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 strict algorithm made by the programmer.</span></p>
<pclass="rvps10"><spanclass="rvts21">Nowadays bots are only practical for running exhaustive search within a 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.</span></p>
<pclass="rvps10"><spanclass="rvts21">Making bots requires programming skills. TASing bots are either written in Lua or built-in into emulators by modifying open source code.</span></p>
<pclass="rvps8"><spanclass="rvts17">Created with the Personal Edition of HelpNDoc: </span><aclass="rvts18"href="http://www.helpndoc.com">Free EBook and documentation generator</a></p>
