<pclass="rvps10"><spanclass="rvts21">This chapter is dedicated to the principal activity in TASing – the way of creating an optimal Input for any given segment of the movie. TASes look so shiny exactly because of persistent manual polishing of Input. The size of working segment can be anything, criteria and factors of optimality can vary, but the method is basically one and the same</span><spanclass="rvts21">: retry all sorts of approaches and choose the best one. The only question is how to do it with minimum time and effort.</span></p>
<liclass="rvps10"><spanclass="rvts34">Gamers</span><spanclass="rvts21"> erroneously think that to make a TAS you only have to complete the game once, using savestates when you make some fatal mistakes (those resulting in inability to complete current segment, for example, death of the character).</span></li>
<liclass="rvps10"><spanclass="rvts34">Newbie TASers</span><spanclass="rvts21"> understand that to make a beautiful TAS you have to revert and fix </span><spanclass="rvts25">all</span><spanclass="rvts21"> noticed mistakes (e.g. even such minor flaws as stumbling over a threshold). They also complete each segment only once, but spend more time than regular players, because of saving and loading savestates much more often. For TASing simple games this can be sufficient.</span></li>
<liclass="rvps10"><spanclass="rvts34">Experienced TASers</span><spanclass="rvts21"> know that to make a perfect TAS it's not enough to fix all noticed mistakes. You also have to fix unnoticed mistakes. Consider unknown factors. Approach the task from an unobvious side. To do all this they play through the same segment several times, both fixing all noticed mistakes and trying to somehow avert unnoticeable mistakes.</span></li>
<pclass="rvps10"><spanclass="rvts21">It's rather difficult to convince yourself to spend time on alternative ways to play through the segment once it's already completed and all obvious mistakes are already fixed. After achieving the current in-game goal people usually want to set another in-game goal. But you must remember that TASer's goal is different from player's goals. So try to abstract away from the game rules and not to retreat from the segment until you complete real goal, not just player's small goal.</span></p>
<pclass="rvps10"><spanclass="rvts21">That's actually the most difficult part – to invent new approaches to solving one and the same task. TASers mainly consider the same approach a regular player would have used in this place of the game. That's why people mostly use evolutionary way instead of revolutionary. You keep modifying the existing basic approach, both fixing its mistakes and conducting experiments. In the process of these thoughtful modifications you enrich your knowledge base about the game, and as a result you produce an Input that isn't immediately obvious.</span></p>
<pclass="rvps10"><spanclass="rvts21">Of course, sometimes you have a flash of inspiration, when a revolutionary idea leads to tremendous improvements that surpass all polishing gains. People love TASing exactly for these emotional moments. Yet it doesn't exempt you from the need to polish this new revolutionary approach using the same methods to bring it even closer to an ideal.</span></p>
<pclass="rvps10"><spanclass="rvts21">Instead of reading the techniques described here you can just immediately start real TASing, so in a course of several projects you would work out your own methods. But most likely after a year of TASing you'll come to the described scheme of work.</span></p>
<pclass="rvps10"><spanclass="rvts21">So, the process of creating the best Input for the segment of optimization can be basically described as a loop of fixing mistakes in previous versions of Input of the segment. A mistake is any kind of divergence from the perfect yet unknown Input. Such statement of question is very advantageous, because it means that you can gradually approach the perfect Input by making small steps that you can elaborate even without being a genius. </span><spanclass="rvts25">The majority of mistakes can be successfully fixed by repeated examination and modification.</span><spanclass="rvts21"> That is, even when you don't have any original ideas, you can achieve a success by persistence. The successful progress motivates you to continue the work and thus prepare the ground for breakthrough ideas.</span></p>
<pclass="rvps10"><spanclass="rvts25">1. </span><spanclass="rvts21">Realizing a mistake happens either when watching the movie in Read-Only mode or right when recording/editing the Input.</span></p>
<tdstyle="border-color: #000000; border-style: solid; height: 15px;"><pclass="rvps10"><spanclass="rvts41">Comment: </span><spanclass="rvts42">Instead of detecting a tangible mistake TASers often just assume that current segment is still improvable. It's always wise to doubt the perfectness of current result and try experimenting with the Input – sometimes you indeed find unused possibilities.</span></p>
<pclass="rvps10"><spanclass="rvts25">2. </span><spanclass="rvts21">The means of solving the mistake are either immediately obvious or are found experimentally. In rare cases you have to resort to calculations and comparisons. A correctly chosen segment usually encompasses all key factors of optimality. The information from previous or next segments is rarely needed.</span></p>
<tdstyle="border-color: #000000; border-style: solid; height: 15px;"><pclass="rvps10"><spanclass="rvts41">Comment: </span><spanclass="rvts42">Sometimes while fixing one mistake we unwittingly create another mistake. In this case the optimization process would go in wrong direction, but fortunately such situations are extremely rare in TASing, because videogames are much more straightforward than real life, so player can find all factors and an unambiguous criterion of optimality. Taseditor additionally simplifies the process by data visualization.</span></p>
<pclass="rvps10"><spanclass="rvts25">3. </span><spanclass="rvts21">The ability to navigate to the place of making the mistake is the essential distinction between TASing and normal speedrunning. Regular players can detect the mistake post factum, but it's TASers who always return back to correct it.</span></p>
<pclass="rvps10"><spanclass="rvts21">In traditional method of TASing the navigation may take noticeable amount of time and effort. Taseditor makes the navigation much faster.</span></p>
<tdstyle="border-color: #000000; border-style: solid; height: 15px;"><pclass="rvps10"><spanclass="rvts41">Comment: </span><spanclass="rvts42">Sometimes the place of making the mistake is located long before the segment where it is revealed. In this case you have to find the segment affecting the mistake and edit it according to the information given by the played segment. And in this case the speed of navigation between those two segments is even more important.</span></p>
<pclass="rvps10"><spanclass="rvts25">4. </span><spanclass="rvts21">Applying modifications to Input is how you make your thoughts real. The less the delay between an idea and its implementation is, the better.</span></p>
<pclass="rvps10"><spanclass="rvts21">In the traditional method of TASing the Input modification generally takes longer, because in addition to rewriting erroneous frames you also have to rewrite adjacent frames In Taseditor this is often not necessary.</span></p>
<tdstyle="border-color: #000000; border-style: solid; height: 15px;"><pclass="rvps10"><spanclass="rvts41">Comment: </span><spanclass="rvts42">Since any Input modification entails a change in the game flow, sometimes even in Taseditor you have to resync the old Input that follows the place of fixing mistake.</span></p>
<pclass="rvps10"><spanclass="rvts25">5. </span><spanclass="rvts21">To see the outcome you need to resume playing the movie from the beginning of current segment of right from the frame of fixing the mistake. There's no need to re-check previous segments of the movie, because the mistake fixing affects only subsequent events.</span></p>
<tdstyle="border-color: #000000; border-style: solid; height: 15px;"><pclass="rvps10"><spanclass="rvts41">Comment: </span><spanclass="rvts42">Although, when you're making an entertaining playthrough instead of a pure speedrun, after fixing a mistake (e.g. making the movement trajectory more smooth) you should ensure that this correction fits with the general sequence of in-game events, so it's recommended to rewatch some previous events together with the current segment.</span></p>
<pclass="rvps10"><spanclass="rvts21">You almost always have to watch the current segment up to its end, that is, to the moment when the target event occurs, so that you can confidently apply the optimality criterion. Because the correction may seem profitable at first but appear worse in the end.</span></p>
<pclass="rvps10"><spanclass="rvts21">After evaluating the outcome, the mistake is either considered to be fixed/non-existent, or you have to return to </span><aclass="rvts27"href="TASingMethodology.html#loop">step 2</a><spanclass="rvts21"> and rethink the situation.</span></p>
<pclass="rvps10"><spanclass="rvts21">Before Taseditor, all mistakes (both explicit and supposed) were being fixed by creating and reloading savestates. If you're not familiar with the traditional method of TASing, here's its basic principles:</span></p>
<liclass="rvps10"><spanclass="rvts21">The game emulation is almost always paused. You only unpause it to rewatch finished segments.</span></li>
<liclass="rvps10"><spanclass="rvts21">TASer sequentially types the Input into frames pointed by the Playback cursor. You see the outcome of the committed Input next frame (or sometimes in several frames). Experienced TASers create a new savestate after each </span><spanclass="rvts37">hard-to-reproduce action</span><spanclass="rvts21">, so they are able to return back without the need to replay the whole segment from the beginning.</span></li>
<liclass="rvps10"><spanclass="rvts21">To correct a mistake, TASer returns to the supposed place of making the mistake and rerecords the whole Input, starting from the frame that needs to be changed. If there was a savestate created at this frame, you can instantly load the savestate in Read+Write mode and begin typing buttonpresses right away. But if you only have a savestate created at some distance before the frame, there are two options. </span><spanclass="rvts34">Option 1:</span><spanclass="rvts21"> load the nearest savestate in Read-Only mode and replay the movie up to the needed frame, then switch back to Read+Write mode and start the correction, thus not touching the Input in the interval from the savestate frame to the mistake frame. </span><spanclass="rvts34">Option 2:</span><spanclass="rvts21"> just load the nearest savestate in Read+Write mode and repeat the old Input by memory, thus rewriting it up to the needed frame, and then start the correction. The 2nd way is used more often, because after the nearest savestate there's usually an </span><spanclass="rvts37">easy-to-reproduce Input</span><spanclass="rvts21"> (e.g. simply holding </span><spanclass="rvts29">R + B</span><spanclass="rvts21">). Also, upon arriving to the supposed frame of the mistake, an experienced TASer mechanically creates a savestate (just in case!), so next time he will be able to return directly to the frame, without wasting time on navigation. Such a prudence makes sense, because mistakes are seldom fixed at the first attempt, usually you need to repeatedly rerecord the same section of Input, starting from about the same frame.</span></li>
<liclass="rvps10"><spanclass="rvts21">The disadvantages of the traditional method clearly reveal when you need to see a distant result of your Input (for example, you press the button now, but the roulette only stops in several seconds). In such cases TASer makes a savestate before entering the Input, records the decisive Input and makes a savestate after it, then unpauses the emulator and carelessly (suboptimally) plays through the game up to the point of seeing the result. If the result is satisfactory, TASer loads the savestate made after the decisive Input and records an optimal playthrough, already being sure in successful outcome. And if the result is unsatisfactory, TASer loads the initial savestate, changes the decisive Input and repeats previous actions (creates a savestate after the Input and hastily plays up to the result). And this process may go for a long while.</span></li>
<liclass="rvps10"><spanclass="rvts21">In order to copy an old Input (for example, the complex acceleration of Mario at the beginning of every level), TASer either learns the button combination by heart or copies it in parts by making several jumps between the source and the destination. First the game is sent to the place of old Input (by loading the savestate prepared at that frame) to watch the replay in Read-Only mode and memorize a few buttonpresses, then it's sent to the current segment (by loading the latest savestate in Read+Write mode) to lay out the buttonpresses. This way sounds tiresome, but if you keep moving both savestates a bit forward after every jump, the navigation between source and destination becomes rather quick. Still, when TASers need to copy a long sequence of buttonpresses, they use an external editor of Input, allowing to copy/paste. But the downside is that switching contexts is very distracting, so often it's less troublesome to just copy the Input manually.</span></li>
<liclass="rvps10"><spanclass="rvts21">To examine the current progress, TASer makes a savestate, turns off the Recording and loads the savestate left at the beginning of current level (usually it's the slot assigned to a rarely used key, such as </span><spanclass="rvts26">F10</span><spanclass="rvts21">). Then he unpaused the emulator and watches the movie like an outsider. To continue the recording, he switches to Read+Write mode and returns directly to the latest recorded frame by loading the latest savestate (usually it's the most often used slot, like </span><spanclass="rvts26">F1</span><spanclass="rvts21">). If while watching TASer decides to modify the old Input, he makes a savestate at this point, switches to Read+Write and loads the just created savestate. Beforehand, you should make sure the last state of the movie is saved to both </span><spanclass="rvts26">F1</span><spanclass="rvts21"> and another slot that won't be used in your experiments with the old Input. This is necessary in case your experiments fail, so you could restore the old movie even if the </span><spanclass="rvts26">F1</span><spanclass="rvts21"> slot becomes overwritten in the course of the experiments.</span></li>
<liclass="rvps10"><spanclass="rvts21">So, the majority of the 10 available slots is used for navigation between different moments of the game. Or, using Taseditor's terms, they are used for Playback cursor navigation along the movie. The 10 slots are more than enough to teleport back and forth among all places of interest, even when current segment is very large. Usually 3-5 slots are enough. Experienced TASers juggle these slots with astounding speed.</span></li>
<liclass="rvps10"><spanclass="rvts21">A couple of another slots are used to store alternative strategies of playing. When you don't know which approach to playing a large segment (e.g. a whole level of the game) will be better, you first polish the 1st approach and save it into a separate slot (say, </span><spanclass="rvts26">F8</span><spanclass="rvts21">), then you polish the 2nd approach and save it into an adjacent slot (e.g. </span><spanclass="rvts26">F7</span><spanclass="rvts21">). After that you can alternately load these slots (or even alternately watch the two branches of the movie) and choose the best one, save it to </span><spanclass="rvts26">F1</span><spanclass="rvts21"> and continue TASing in this branch.</span></li>
<pclass="rvps10"><spanclass="rvts21">As you see, almost everything in the traditional method of TASing is done using savestates (Bookmarks). In Taseditor some of their functions are replaced by the Greenzone and the History Log, yet Bookmarks still play important role, allowing to keep alternative branches of the movie in a single project. The Playback cursor navigation now can be done faster by either drag'n'drop or mouse wheel. In fact, now you don't need to put Playback cursor to the frame of modification, you can just scroll the Piano Roll to the place and change the Input by mouse.</span></p>
<pclass="rvps10"><spanclass="rvts21">Since the Recording is less effective than direct editing, there's no more need to constantly switch modes. Now the emulator is always in Read-Only mode.</span></p>
<pclass="rvps10"><spanclass="rvts21">The game is always paused, as before. But now you are seeing the outcome of your Input only when you actually want to see it. At first this may seem inconvenient (as you don't feel the habitual feedback from your keypresses), but it's actually very advantageous, because it means the higher level of independence from the game. Instead of the standard mechanism of "involvement into the gameplay" there are other mechanisms of data transmission. So in any case you will receive all needed information on how the game interprets your Input, it's just that this data stream won't continually flow into your mind, it will be delivered on command.</span></p>
<pclass="rvps10"><spanclass="rvts21">And when it's really necessary, you can have an intensified feedback by switching to the third method of TASing in Taseditor.</span></p>
<pclass="rvps10"><spanclass="rvts21">Let's review pros and cons of all three methods, one by one.</span></p>
<liclass="rvps14"style="text-indent: 0px"><spanclass="rvts21">navigating the Input using the mouse</span></li>
<liclass="rvps14"style="text-indent: 0px"><spanclass="rvts21">editing the Input using the mouse/</span><spanclass="rvts21">keyboard/joypad</span></li>
<liclass="rvps14"style="text-indent: 0px"><spanclass="rvts21">watching interim or final results of the Input </span><spanclass="rvts21">automatically</span></li>
<pclass="rvps8"><spanclass="rvts17">Created with the Personal Edition of HelpNDoc: </span><aclass="rvts18"href="http://www.helpndoc.com/feature-tour">Easily create Web Help sites</a></p>
