<pclass="rvps7"><spanclass="rvts20">Thanks to having a definite goal, creating tool-assisted speedruns is the easiest application of TASing, and all relevant techniques are examined pretty well. Here you can find the summary of generic tasks emerging in the process of polishing the Input for a speedrun. Before reading this, make sure you've learned the materials in </span><aclass="rvts24"href="TASingProcess.html">TASing Process</a><spanclass="rvts20"> and </span><aclass="rvts24"href="TASingMethodology.html">TASing Methodology</a><spanclass="rvts20">.</span></p>
<pclass="rvps7"><spanclass="rvts20">Speedrunners have to search for the shortest way of completing every segment of the game. This process of searching consists of testing a multitude of approaches for playing the segment and finally choosing the best approach. Here we will discuss only the problem of choice.</span></p>
<pclass="rvps7"><spanclass="rvts20">To simplify the problem, TASers usually compare only two approaches: the </span><spanclass="rvts22">new working</span><spanclass="rvts20"> approach and the </span><spanclass="rvts22">old best</span><spanclass="rvts20"> approach; all other old approaches are promptly forgotten (although the interesting ones can always be saved in the Bookmarks).</span></p>
<pclass="rvps7"><spanclass="rvts20">When the new working approach is considered to be better (more optimal) than the old best approach, it's naturally assumed that it's also better than any of the old approaches, so this working approach instantly becomes the best. In the case of using Bookmarks you should re-save the new approach to the slot where the old best approach was stored. At the end of the search the contents of this Bookmark slot are loaded into the final movie.</span></p>
<liclass="rvps7"><spanclass="rvts20">presence/absence of the specific event in the new and old approach </span><spanclass="rvts63">(bool)</span></li>
<liclass="rvps7"><spanclass="rvts20">the time of occurrence of the target event in the new and old approach </span><spanclass="rvts63">(int)</span></li>
<liclass="rvps7"><spanclass="rvts20">the state of the game at the same frame in the new and old movie </span><spanclass="rvts63">(string)</span></li>
<pclass="rvps7"><spanclass="rvts20">Respectively, when you're comparing any pair of approaches you are doing one of the three possible actions:</span></p>
<pclass="rvps7"><aclass="rvts24"href="SpeedrunningSynopsis.html#CompareEvent">1. Comparing presence/absence of the event.</a></p>
<pclass="rvps19"><aclass="rvts43"href="SpeedrunningSynopsis.html#CompareEvent-A">A. By memory</a></p>
<pclass="rvps19"><aclass="rvts43"href="SpeedrunningSynopsis.html#CompareEvent-B">B. Using Bookmarks</a></p>
<pclass="rvps7"><aclass="rvts24"href="SpeedrunningSynopsis.html#CompareTime">2. Comparing the time of occurrence.</a></p>
<pclass="rvps19"><aclass="rvts43"href="SpeedrunningSynopsis.html#CompareTime-A">A. By memory</a></p>
<pclass="rvps19"><aclass="rvts43"href="SpeedrunningSynopsis.html#CompareTime-B">B. Using the green arrow</a></p>
<pclass="rvps19"><aclass="rvts43"href="SpeedrunningSynopsis.html#CompareTime-C">C. Using a Marker</a></p>
<pclass="rvps19"><aclass="rvts43"href="SpeedrunningSynopsis.html#CompareTime-D">D. Using Bookmarks</a></p>
<pclass="rvps7"><aclass="rvts24"href="SpeedrunningSynopsis.html#CompareState">3. Comparing the state of the game at one and the same frame.</a></p>
<pclass="rvps19"><aclass="rvts43"href="SpeedrunningSynopsis.html#CompareState-A">A. By memory</a></p>
<pclass="rvps19"><aclass="rvts43"href="SpeedrunningSynopsis.html#CompareState-B">B. Using Bookmarks</a></p>
<pclass="rvps7"><spanclass="rvts22">1. Comparing presence/absence of the event.</span></p>
<pclass="rvps7"><spanclass="rvts20">Choose the approach where the needed event happens / unneeded event doesn't happen. The occurrence of the event is only the first (and often easy) step in creating the Input for current segment, and next step is to try speeding up the time of the occurrence.</span></p>
<pclass="rvps7"><spanclass="rvts33">The search for approaches goes on until the first successful approach is found, or until you're tired (then the event is considered to be unfeasible).</span></p>
<pclass="rvps7"><spanclass="rvts63">Programming analogy: comparing two Booleans, comparing two arrays of Booleans.</span></p>
<pclass="rvps7"><aname="CompareEvent-A"></a><spanclass="rvts20">A. Most of time it's enough to simply keep in mind the fact that target event didn't occur in previous approaches. Example: </span><aclass="rvts24"href="SemiautomaticTASing.html#FindStartButtonPress">finding the </a><aclass="rvts24"href="SemiautomaticTASing.html#FindStartButtonPress">Start buttonpress</a><spanclass="rvts20">.</span></p>
<pclass="rvps7"><aname="CompareEvent-B"></a><spanclass="rvts20">B. When the target event is complex (e.g. you plan to shoot 3 enemies simultaneously), it's recommended to save the most promising approaches into Bookmarks (e.g. an approach where you shot 2 enemies simultaneously and 3rd one shortly after), because if the target event is unfeasible, you might be satisfied with such partial success.</span></p>
<pclass="rvps7"><spanclass="rvts22">2. Comparing the time of occurrence.</span></p>
<pclass="rvps7"><spanclass="rvts20">Choose the approach where the target event occurs earlier. The time of occurrence is defined by the frame in which the event can be detected, while in previous frame it cannot be detected. The number of this frame is found by bringing the Playback cursor to the frame and watching the FCEUX screen (or Memory Watch) for confirming.</span></p>
<pclass="rvps7"><spanclass="rvts33">The search for approaches goes on until you're tired, or until all possible types of approaches are exhausted (then the current best approach is considered to be frame perfect, until new factors are found).</span></p>
<pclass="rvps7"><spanclass="rvts63">Programming analogy: comparing two Integer Numbers.</span></p>
<pclass="rvps7"><aname="CompareTime-A"></a><spanclass="rvts20">A. For simplest segments and small subsegments it may be enough to just keep in mind the current fastest frame number and compare results of all new approaches with this number. But in general it's not recommended to rely on human memory. Details: </span><aclass="rvts24"href="TASingProcess.html#EndOfSegment">TASing Process</a><spanclass="rvts20">.</span></p>
<pclass="rvps7"><aname="CompareTime-B"></a><spanclass="rvts20">B. On simple segments you can refer to the green arrow of Taseditor. When using it, you're supposed to always leave the Playback cursor at the frame of target event (which is only natural). Thus if the new frame of target event is located above the green arrow, it means the new approach is faster than previous approach. Details:</span><aclass="rvts24"href="NonlinearTASing.html#GreenArrow">TASing Methodology</a><spanclass="rvts20">.</span></p>
<pclass="rvps7"><aname="CompareTime-C"></a><spanclass="rvts20">C. On complex segments use an unbound Marker that always points at the current fastest frame number in the Piano Roll. Every time you beat the old result you're supposed to manually move the Marker higher. Thus if the new frame of target event is located above the Marker, it means the new approach is faster than the old best approach.</span></p>
<pclass="rvps7"><aname="CompareTime-D"></a><spanclass="rvts20">D. On segments of any level of complexity it's recommended to use Bookmarks that are displayed in the icons column of the Piano Roll. Every time you beat the old result you're supposed to manually save the current approach to the same Bookmark slot, replacing the old best approach stored there. Thus if the new frame of target event is located above the Bookmark icon, it means the new approach is faster than the old best approach.</span></p>
<pclass="rvps7"><spanclass="rvts22">3. Comparing the state of the game at the same frame.</span></p>
<pclass="rvps7"><spanclass="rvts20">Choose the approach where properties of the game are more advantageous in a whole. This type of comparison is useful when you need to evaluate compound in-game situations. For example, in Formula 1 racing you have to care both about being as fast as possible and wearing tyres as little as possible, so you need to find an optimal balance on each segment of the track instead of simply rushing.</span></p>
<pclass="rvps7"><spanclass="rvts20">Here our segment has defined end frame, and every new test is supposed to replay the segment up to that frame. Taseditor stores this frame number in the form of the green arrow, which automatically pauses emulation when you watch new approaches. So TASer only needs to edit Input (creating new approaches), launch replaying, wait for the stopping and evaluate the result (judging by FCEUX screen or Memory Watch).</span></p>
<pclass="rvps7"><spanclass="rvts33">The search of approaches goes on until you're tired, or until all possible types of approaches are exhausted (then the current best approach is considered to be perfect, until new factors are found).</span></p>
<pclass="rvps7"><spanclass="rvts63">Programming analogy: comparing two Strings, comparing two arrays of Integer Numbers.</span></p>
<pclass="rvps7"><aname="CompareState-A"></a><spanclass="rvts20">A. For simple segments it may be enough to just keep in mind the value of the most important property of the game state achieved in the old best approach. Every time you watch the replaying of a new approach, you can compare results of the new approach with this value. If you decide the new value is better, you have to memorize it in place of old value. Example: </span><aclass="rvts24"href="NonlinearTASing.html#LuckManipulation">luck manipulation</a><spanclass="rvts20">.</span></p>
<pclass="rvps7"><spanclass="rvts20">When there's more than one important property, it's not recommended to rely on human memory.</span></p>
<pclass="rvps7"><aname="CompareState-B"></a><spanclass="rvts20">B. On complex segments and especially on gigantic segments (e.g. with the size of a whole level of the game) use Bookmarks that store alternative branches of the movie. The best approach for playing the segment is saved into one Bookmark slot and the new approach is saved into another slot. Then you can easily switch between these slots and compare values of each property of the game state. In addition, you can point the mouse cursor to respective Bookmarks to see screenshots of the game state and visually compare their properties with current image on FCEUX screen.</span></p>
<pclass="rvps7"><spanclass="rvts20">To display important RAM data on screenshots you should use Lua graphical output, then Memory Watch window won't be required to judge about hidden properties, and you will be able to successfully judge by screenshots only. Details: </span><aclass="rvts24"href="ProgramCustomization.html#DisplayBranchScreenshots">Program Customization</a><spanclass="rvts20">.</span></p>
<pclass="rvps7"><spanclass="rvts20">In the situation when some properties in the new approach are better and some others are worse you'll have to thoroughly weigh all of them (either in your mind or using a Lua-powered aggregate formula) and then decide which state of the game is better.</span></p>
<pclass="rvps7"><spanclass="rvts20">Every time you beat the old result you're supposed to manually save the new approach to the same Bookmark slot, replacing the old best approach stored there.</span></p>
<pclass="rvps7"><spanclass="rvts20">After finding the fastest approach of playing the segment, a good TASer is expected to improve the entertainment value of the play through the segment. The optimality criteria in such activity may be very diverse, but the general requirement is to keep the same time of playing through the segment.</span></p>
<pclass="rvps7"><spanclass="rvts20">Alternatively, you can postpone the entertainment improvement of the segment and proceed to the next.</span></p>
<pclass="rvps6"style="clear: both;"><spanclass="rvts16">Created with the Personal Edition of HelpNDoc: </span><aclass="rvts17"href="https://www.helpndoc.com/feature-tour/create-help-files-for-the-qt-help-framework">Create help files for the Qt Help Framework</a></p>
