Créer un tool-assisted speedrun consiste à trouver l'enchaînement idéal des boutons à presser afin de remplir un critère donné – en général, finir le jeu le plus vite possible. Aucune restriction n'est imposée quant aux outils utilisés, mais le résultat final doit obligatoirement consister en une série de boutons à presser qui, si on l'appliquait à une console de jeu, permettrait d'atteindre l'objectif que l'on s'est fixé. Le moyen le plus simple permettant d'acquérir une telle séquence est d'enregistrer les boutons que l'on presse lorsque l'on joue au jeu voulu sur un émulateur, en sauvegardant et en chargeant à maintes reprises l'état de l'émulateur, et donc du jeu, afin de tester plusieurs possibilités et de garder seulement la meilleure. Dans le but d'être plus précis, le jeu tourne au ralenti. A l'origine, le jeu était seulement ralenti à un faible pourcentage (par exemple 5%) de la vitesse normale. Cependant, grâce à plusieurs avancées dans le domaine, l'avance image par image est maintenant bien plus utilisée. Un tool-assisted speedrun réalisé sans cette technique aura dès lors beaucoup de chance d'être critiqué pour son aspect bâclé.
Le re-recording permet en outre l'utilisation d'une autre technique, la manipulation de la chance, qui exploite le fait que les boutons pressés par le joueur ont une influence directe sur la génération pseudo-aléatoire des variables utilisées dans le jeu. De cette façon, on peut forcer la réalisation de certains évènements. En faisant une sauvegarde d'état avant un événement donné, on peut en effet tester l'influence d'une petite variation des boutons pressés sur l'accomplissement ou non d'un certain résultat. La manipulation de la chance permet par exemple d'obtenir la pièce idéale au moment voulu dans Tetris, ou un objet rare après avoir tué un ennemi. Selon le jeu et l'évènement souhaité, ce processus peut demander beaucoup de temps, du fait qu'il oblige à tester de très nombreuses possibilités, et peut ainsi représenter une part non négligeable du temps passé à réaliser un tool-assisted speedrun.
Une technique assez rarement employée est la recherche par force brute (en laissant un algorithme jouer au jeu) pour tester toutes les possibilités. En théorie, ce processus permettrait de trouver l'enchaînement idéal de boutons à presser pour n'importe quel jeu, mais comme le nombre de possibilités à tester croît exponentiellement avec la longueur de la séquence de jeu à réaliser, cette technique n'est utilisée que pour optimiser quelques petites portions d'un speedrun. Un algorithme heuristique peut aussi être utilisé dans ce but. Bien que ce procédé ne fournit pas une solution parfaite, il peut se révéler particulièrement efficace pour résoudre certains jeux de puzzle.
Une autre technique assez peu utilisée est le désassemblage du jeu lui-même. En analysant la structure interne du jeu, il est possible d'arriver à manipuler la chance sans avoir à procéder par tâtonnements, ou de découvrir des bugs cachés dans le moteur du jeu. Une technique associée et plus communément utilisée consiste à surveiller certaines adresses mémoire qui sont liées à certains paramètres ou évènements afin de voir quand et pourquoi elles changent, et d'utiliser cela à son avantage.
Toutes ces techniques impliquent une certaine interaction avec le jeu dans des proportions qui seraient impossibles sans émulateur, mais le résultat final (le speedrun consistant en l'enchaînement des boutons pressés) ne dépend plus d'une quelconque manipulation de la machine utilisée : tout est théoriquement faisable à la manette. Dès lors, les outils utilisés dans le tool-assisted speedrunning sont foncièrement différents de toutes les manipulations rendues possibles par des outils tels que l'Action Replay, par exemple, car de telles manipulations sont impossibles à retranscrire comme une série de boutons à presser dans le jeu.
Le tool-assisted speedrun repose sur le fait qu'une même séquence de boutons pressés devra toujours produire le même résultat, quel que soit le moment où on l'exécute. En d'autres termes, l'émulation doit être déterministe relativement à une séquence donnée. Si ce n'est pas le cas, un speedrun qui a été optimal à une première lecture risque de ne même pas finir le jeu lors d'une deuxième lecture. Cette perte de synchronisation apparaît lorsque l'état à une date donnée de la machine émulée, lors de la lecture du speedrun, ne correspond pas exactement à l'état où la machine était, à la même date, lors de la production du speedrun. Une désynchronisation peut aussi être due à l'utilisation de sauvegardes d'état incomplètes, qui ne permettent pas de restaurer la machine émulée au même état que lorsque la sauvegarde d'état a été créée.
Les problèmes dus à l'émulation, tels que l'absence de déterminisme ou la création de sauvegardes d'état incomplètes, sont seulement découvertes lorsque l'on utilise l'émulateur sous les strictes conditions d'avance image par image nécessaires au tool-assisted speedrunning. Les développeurs d'émulateurs n'accordent en effet que très peu d'importance aux problèmes rencontrés par les tool-assisted speedrunneurs, car ces problèmes n'ont en général aucun effet lorsque l'on joue normalement à l'émulateur. Par conséquent, la communauté du site TASVideos a du modifier de très nombreux émulateurs afin de les rendre aptes à la production de tool-assisted speedruns. Si un TAS a été crée sur un tel émulateur (souvent caractérisé par le suffixe -rr, ou -rerecording), alors sa lecture sur une version non modifiée de l'émulateur aura de grandes chances de conduire à une désynchronisation.
Consoles | Emulateurs |
---|---|
NES | Famtasia, FCEUX, VirtuaNES, Nintendulator |
Super Nintendo | Snes9x |
Virtual Boy | VBjin |
Nintendo 64 | Mupen64 |
Game Boy, Game Boy Color, Game Boy Advance | VisualBoyAdvance |
Nintendo DS | DeSmuME |
Playstation | PCSX |
Master System | vbsms+, Dega |
Megadrive | Gens |
Saturn | Yabause |
Arcade, Neo Geo | Final Burn Alpha |
PC-Engine | Pcejin, Mednafen |
DOS | JPC-rr |
Les tool-assisted speedruns sont réalisés pour de multiples raisons, dont voici les principales :