Salut à tous, je me posais après avoir vu la conférence de realmyop et cdv et je me disais est-ce qu'il faut forcement être un codeur ou être dans le métier de l'informatique pour pouvoir faire un bon voire tri bon tas de jeux très variés que ça aille de la plateforme au SMUP au rpg etc. .. merci de votre réponse :)
Il me semble que cela n'est absolument pas nécessaire, on peut trés bien faire un exellent TAS si on connait trés bien son jeu et sa façon de fonctionner, mais il faut avouer que souvent les "coders" on plus souvent des TAS meilleurs que les notre du fait qu'il comprenne les sources même du jeu (code sources donc!), ce leur permet de trouver les erreurs de codage (rare, mais il y en a..) et d'en abuser afin d'obtenir une production qu'un "non-coder" trouvera "exellent". C'est pourquoi, faire du TAS c'est trés bien, mais c'est mieux si on est "coder" ou si l'on y travaille avec un "coder". Il faut aussi savoir que les erreurs de codage du jeu sont tout d'abord... DANS le jeu, par conséquent, même en jouant uniquement, il arrive souvent que ce soit un joueur "non-coder" qui trouve des bugs de jeu.
Quoi qu'il en soit, si tu pensais que les meilleurs TAS étaient faits uniquement par des "Coders", et bien non... Tu peux très bien devenir toi même un bon TASer, après, il faut quand même le minimum requis:
_les outils
_savoir s'en servir
_une bonne voire excellente connaissance de ton jeu
_et trés important: la volonté!
Avec seulement ça tu peux déjà sortir une production digne d'un pro, mais il faut aussi être au courant des derniers "tricks" et "glitches" connu à ce jour de ton jeu...
Ouais comme par exemple la création d'un emulateur ou de tools?
Ahah, oui, bien évidemment la création de "tools", l'amélioration des émulateurs sont fait par les "coders", mais c'est uniquement pour la simple bonne raison, qu'ils sont les seuls à en être capable, sans eux, aucun TASer n'aurait pu allais aussi loin dans le "surhumain", ils sont donc indispensable, mais pas les meilleurs en terme de course (... si, ils sont les meilleurds, mais pas toujours...)
Merci pour ta réponse instructive ! En fait j'ai juste de très faibles notions de programmation en c (le langage de programmation utilisé dans les TAS est bien le LUA comme pour le LUA scripting? ) et niveau emulateur et tools je pense m'y connaître à peu près j'utilisais déjà plutôt bien les save states et le re-recording sans connaître le TAS c'est en regardant le guide de STBM que j'ai découvert le ram watch etc et je pensais commencer un TAS soit de rayman advance juste pour le fun ou de sm world 1 qui est un jeu que j'adore voilà :) et en plus comme je voudrais devenir développeur, codeur ça m'intéresse et donc je voudrais en apprendre beaucoup plus sur cette discipline ;)
Ouais comme par exemple la création d'un emulateur ou de tools?
Non, plutot la creation de script Lua pour facilité la tache.
Moi je dirais plutot pour les "Tools" ou les "émulateur" comme il le dit, car j'ai beau ne pas être coder, mais je peux quand même écrire des lua script lorsque j'ai besoin d'avoir certaine donnée ou de les écrire (la ça devient du cheat, mais c'est pour l'entrainement uniquement... :) ), bien évidement je parle de lua d'a peine 100 lignes que ne montrent q'une dizaine de chose, aprés pour les Lua de 45 fichiers liés en un par un lua de 300 lignes... oui, la j'en serais strictement incapable, d'autant plus que ces "Coders" ont plus de faciliter que nous à trouver les adresses de ram nécessaire a leur production...
D'ailleurs (excusez-moi de spamer un peu le sujet, mais bon..) on oubli souvent QUI a créer la première run assistée par ordinateur, le premier car il a lui même créer l'émulateur (à l'époque il n'y avait que le "slow mode" comme "tool"), du coup, c'est lui même qui a inventé le TAS! et son métier... ingénieur en informatique... sans surprise... (c'est le boss de tout les "TAS-coders", et c'est pas pour autant qu'il a fait les meilleurs TAS...)
D'ailleurs (excusez-moi de spamer un peu le sujet, mais bon..) on oubli souvent QUI a créer la première run assistée par ordinateur, le premier car il a lui même créer l'émulateur (à l'époque il n'y avait que le "slow mode" comme "tool"), du coup, c'est lui même qui a inventé le TAS! et son métier... ingénieur en informatique... sans surprise... (c'est le boss de tout les "TAS-coders", et c'est pas pour autant qu'il a fait les meilleurs TAS...)
Tu parles bien de morimoto et de son tas de super mario bros 3 ? ou à l'époque des doom honoific title ? et tu peux spamer autant que tu veux ce que tu dis reste intéressant :)
je ne sais pas si il s'appel aussi "morimoto", mais je parle de "Bisqwit", il est tellement àfond dans les codes sources qu'il s'est créer un émulateur... d'éditeur de codes sources... du coup il peut faire des TAS où il s'enregistre en trains d'écrire du code, avec style en plus... quelque chose à voir!
je ne sais pas si il s'appel aussi "morimoto", mais je parle de "Bisqwit", il est tellement àfond dans les codes sources qu'il s'est créer un émulateur... d'éditeur de codes sources... du coup il peut faire des TAS où il s'enregistre en trains d'écrire du code, avec style en plus... quelque chose à voir!
ouais bisqwit c'est le créateur de tasvideos sur la video rien que les première secondes sont impressionnantes! voici le lien pour le tas de morimoto : http://tasvideos.org/668M.html comme tu peux le voir d'après là date il n'est pas tout récent ^^
Morimoto et Bisqwit sont 2 personnes différentes ;)
Je pense qu'on peut résumer comme ça:
-Morimoto est un peu le précurseur du TAS, vu comme sa run de SMB3 a impressionné tout le monde à l'époque (et fait polémique, vu qu'on ne savait pas forcément que c'était un TAS)
-Bisqwit a fondé TASvideos, ce qui a vachement fait avancer le TASing, en rassemblant au final toute cette communauté, au moins la partie anglophone (et est bien sûr un excellent TASer)
Pour revenir au sujet de base, être un bon codeur n'est pas une obligation, mais évidemment ça aide. Simplement "avoir des bases" c'est déjà un gros avantage, puisqu'on peut comprendre à un certain degré comment un jeu "pense" et réagit.
Je m'avance peut-être mais je pense qu'une grosse majorité des TAS qui sont publiés sont faits sans déchiffrer le code source du jeu.
Mais il y a le LUA scripting qui peut être utile pour des tas de choses. C'est un outil assez puissant qui permet de contrôler l'émulateur et faciliter le travail ou aller plus loin dans l'optimisation (en commençant par afficher des infos spécifiques plus ou moins complexes jusqu'à carrément créer un bot pour tester des tonnes de possibilités, entre autres...).
A mon avis, le premier outil "technique" à connaître est le RAM search/watch; c'est pas bien compliqué et c'est extrêmement utile. Un exemple simple: si tu peux observer les coordonnées de ton perso, tu peux très facilement comparer différentes choses et voir quelles actions te font gagner du temps (ou de la distance) dans un jeu style plateforme ou à scrolling... Après c'est qu'une question de patience. Il faut tester et triturer un peu le jeu pour découvrir des petites astuces. Découvrir des glitches peut se faire comme ça, mais on remarque qu'ils sont aussi trouvés souvent par hasard. Lire le code source peut servir ici, soit pour en repérer certains (mais là ça se complique), soit pour mieux comprendre comment déclencher un bug déniché "au hasard".
Au final, être un gros codeur n'est pas obligatoire pour faire un bon TAS, mais avoir des bases peut aider à comprendre certaines choses.
J'ai 2 TAS publiés ici et dans aucun des deux je n'ai utilisé le LUA ni décompilé le jeu ;)
Morimoto et Bisqwit sont 2 personnes différentes ;)
Je pense qu'on peut résumer comme ça:
-Morimoto est un peu le précurseur du TAS, vu comme sa run de SMB3 a impressionné tout le monde à l'époque (et fait polémique, vu qu'on ne savait pas forcément que c'était un TAS)
-Bisqwit a fondé TASvideos, ce qui a vachement fait avancer le TASing, en rassemblant au final toute cette communauté, au moins la partie anglophone (et est bien sûr un excellent TASer)
Pour revenir au sujet de base, être un bon codeur n'est pas une obligation, mais évidemment ça aide. Simplement "avoir des bases" c'est déjà un gros avantage, puisqu'on peut comprendre à un certain degré comment un jeu "pense" et réagit.
Je m'avance peut-être mais je pense qu'une grosse majorité des TAS qui sont publiés sont faits sans déchiffrer le code source du jeu.
Mais il y a le LUA scripting qui peut être utile pour des tas de choses. C'est un outil assez puissant qui permet de contrôler l'émulateur et faciliter le travail ou aller plus loin dans l'optimisation (en commençant par afficher des infos spécifiques plus ou moins complexes jusqu'à carrément créer un bot pour tester des tonnes de possibilités, entre autres...).
A mon avis, le premier outil "technique" à connaître est le RAM search/watch; c'est pas bien compliqué et c'est extrêmement utile. Un exemple simple: si tu peux observer les coordonnées de ton perso, tu peux très facilement comparer différentes choses et voir quelles actions te font gagner du temps (ou de la distance) dans un jeu style plateforme ou à scrolling... Après c'est qu'une question de patience. Il faut tester et triturer un peu le jeu pour découvrir des petites astuces. Découvrir des glitches peut se faire comme ça, mais on remarque qu'ils sont aussi trouvés souvent par hasard. Lire le code source peut servir ici, soit pour en repérer certains (mais là ça se complique), soit pour mieux comprendre comment déclencher un bug déniché "au hasard".
Au final, être un gros codeur n'est pas obligatoire pour faire un bon TAS, mais avoir des bases peut aider à comprendre certaines choses.
J'ai 2 TAS publiés ici et dans aucun des deux je n'ai utilisé le LUA ni décompilé le jeu ;)
Merci grincevent pour ta réponse, j'ai quelque notions de programmation mais bon pas en LUA mais plutôt en c mais du coup je pense que si je regarde un peu comment sont faits les codes je pourrais afficher quelques adresses (faire un bot ça ce serai impossible pour moi ) niveau tools sur l'emulateur ça, pas de problème ram watch, search, save states, recording et re-recording frame advance ça je maîtrise :)
Comme il a été dit par plusieurs messages, être un codeur peut aider à comprendre certaines logiques de jeu, mais n'est absolument pas nécessaire afin de faire un TAS. Le seul vrai avantage est effectivement de pouvoir déchiffrer le code source d'un jeu, mais cela est extrêmement rare, à priori seulement pour des TAS demandant une grande quantité de manipulation de la chance.
Pour les lua il suffit juste d'avoir quelques notions de programmation et de regarder quelques exemples simples, vraiment rien de bien compliqué.
Sinon pour l'histoire, le TAS de Morimoto a été le premier à faire découvrir la discipline à un grand nombre de gens. C'est d'ailleurs comme ça que Bisqwit a découvert les TAS, à la suite de quoi il a créé NESVideos qui est devenu par la suite TASVideos. Plus de détails ici
Et historiquement, le slow motion est apparu sur Quake (ce qui permettait de réduire très légèrement la vitesse du jeu d'après ce que j'ai compris).
J'ajoute mon grain de sel (non, je n'ai pas lu toutes les "reply"): aucunement besoin de connaître quoi que ce soit au "coding" pour être un bon TASeur. Seuls patience et acharnement sont de rigueur!
A mon avis, le premier outil "technique" à connaître est le RAM search/watch; c'est pas bien compliqué et c'est extrêmement utile. Un exemple simple: si tu peux observer les coordonnées de ton perso, tu peux très facilement comparer différentes choses et voir quelles actions te font gagner du temps (ou de la distance) dans un jeu style plateforme ou à scrolling... Après c'est qu'une question de patience. Il faut tester et triturer un peu le jeu pour découvrir des petites astuces. Découvrir des glitches peut se faire comme ça, mais on remarque qu'ils sont aussi trouvés souvent par hasard. Lire le code source peut servir ici, soit pour en repérer certains (mais là ça se complique), soit pour mieux comprendre comment déclencher un bug déniché "au hasard".
Au final, être un gros codeur n'est pas obligatoire pour faire un bon TAS, mais avoir des bases peut aider à comprendre certaines choses.
J'ai 2 TAS publiés ici et dans aucun des deux je n'ai utilisé le LUA ni décompilé le jeu ;)
ouais, je suis tout-à-fait d'accord, mais aprés, d'un point de vue objectif, c'est la même chose dans certains cas :D
La ram watch/search permet d'avoir dans une fenetre juste a coté de son écran les donnée nécessaires au jeu... un Lua permet exactement la même chose, mais l'affiche directement sur l'écran de jeu. Aprés, la principale différence est que le Lua est plus "poussée" niveau technologie (je vais donc parler d'un domaine que je connais =p ), par exemple, pour un jeu tel que "Sonic", nous les Sonic TASers on saient qu'il y a un décalage d'exactement 2 frames entre le moment ou l'on fait une action a la manette, et le moment où le perso à l'écran le fait, du coup, au lieu d'utiliser la ram watch/search, qui affiche la vitesse instantannée, on écrit un Lua qui montre la vitesse du perso et sa position dans 2 frames "in the future" afin d'être sûr que le perso fera exactement ce que l'on veut... chose impossible avec uniquement la ram search/watch ( à moins de connaître par coeur tous les codes du jeu, ...je parle bien des codes sources : ) )
De plus, la ram search/watch donne la donnée "brute", avec les Lua, on peu les faire traiter des opérations ou même carrément changer sa valeur lors de l'affichage à l'écran afin de voir ce que l'on VEUT voir, et pas seulement ce que donne le jeu.
Bien évidement (Appotheoz), les Lua script sont bien plus polyvalent, ils permettent plein d'autres chose (par exemple passer les passages ennuyant pour le TASeur ou même jouer à sa place pour les passage répété et automatiques...).
Aussi, pour répondre à ton autre question (à laquelle je voulais laisser les autres répondre mais personne ne l'a fait), devenir TASeur ne t'aideras pas d'avantage à devenir développeur que si tu lisais et apprenais à écrire du code, car généralement, en tant que débutant, on lie les codes et tente de les réécrire en y modifiant des toutes petites chose à son avantage, ce que tu ferais si tu apprenais les codes sans TASer:
point positif: en plus d'appendre, tu joue!
point négatif: au niveau du TAS, on a besoin de plus en plus de tools, mais on aura toujours une limite, certaines choses sont parfaitelent inutiles, ce qui inclu des codes, des formes, voire des commandes, que tu ne verras jamais...
Sinon tu fais équipe avec un mec qui s'y connait en dev, c'est ce qui arrive assez souvent :p
Et pour faire le perroquet :
Mais sinon oui, TASer ne requiert pas de connaissance dans le développement, tu peux faire le TAS du siècle sans même savoir comment dire hello world en bash.
Ce qui compte, c'est ta motivation et ton acharnement sur ce TAS.
feeuzz22 -> On pourrait simplifier tout ça pour dire que LUA, en plus de lire la RAM, peut également traiter le résultat. On peut penser aux RNG finder par exemple qui calcul tout les inputs en observant les RNG dans la RAM :p
en effet =)
Mais un Lua ça reste bien plus puissant que ce que certains débutants pourraient penser!
Là c'est sûr, avec des très "gros" LUA on peut imaginer et faire des trucs hallucinants. En parlant de Sonic, j'avais lu une discussion sur un projet intéressant, et je sais pas si ça a été fait au final: afficher la position de Tails façon "écran splitté" ou dans une sorte de fenêtre pour quand il est plus à l'écran. Une des pistes envisagées était, à chaque frame, de déplacer Sonic là où Tails se trouve pour créer cette "image" (puis bidouiller pour ne pas l'afficher lui, etc...) et revenir en arrière pour remettre le jeu "normal" après avoir obtenu le bon résultat... Un truc assez poussé, original et très utile, quoi. Mais comme j'ai pas suivi jusqu'au bout, je sais pas si ça s'est vraiment fait.
Waouh tant de reponses ! X) Donc pour continuer dans la discussion je compte regarder quelques exemples de LUA pour mon futur tout premier TAS :) je suis jeune et j'ai encore beaucoup de choses intéressantes à apprendre ;) et en lisant l'histoire avec sonic je pensais pas qu'on pouvait partir d'un simple décalage de 2 frames à un LUA assez complexe d'après ce qui à été dit mais bon je me doute que ca doit étre utile si les TASer le programment :p
en effet =)
Mais un Lua ça reste bien plus puissant que ce que certains débutants pourraient penser!
Là c'est sûr, avec des très "gros" LUA on peut imaginer et faire des trucs hallucinants. En parlant de Sonic, j'avais lu une discussion sur un projet intéressant, et je sais pas si ça a été fait au final: afficher la position de Tails façon "écran splitté" ou dans une sorte de fenêtre pour quand il est plus à l'écran. Une des pistes envisagées était, à chaque frame, de déplacer Sonic là où Tails se trouve pour créer cette "image" (puis bidouiller pour ne pas l'afficher lui, etc...) et revenir en arrière pour remettre le jeu "normal" après avoir obtenu le bon résultat... Un truc assez poussé, original et très utile, quoi. Mais comme j'ai pas suivi jusqu'au bout, je sais pas si ça s'est vraiment fait.
Fait, mais ne fonctionne pas comme voulu... au dernières nouvelles.. mais je ne suis pas sûr. La version que je possédais en tout cas ne marchais pas. Sonic était "fixé" a Tails.
Appotheoz wrote:
Waouh tant de reponses ! X) Donc pour continuer dans la discussion je compte regarder quelques exemples de LUA pour mon futur tout premier TAS :) je suis jeune et j'ai encore beaucoup de choses intéressantes à apprendre ;) et en lisant l'histoire avec sonic je pensais pas qu'on pouvait partir d'un simple décalage de 2 frames à un LUA assez complexe d'après ce qui à été dit mais bon je me doute que ca doit étre utile si les TASer le programment :p
Bien sûr, tout dépend de ce que tu TAS ^^!
Mais à mon avis, tu peu déjà utiliser les Lua existants pour ton jeux, je ne pense pas que tu aie besoin d'en créer à moins que ce soit un jeux pas encore TASer =) .
Ouais je pense faire ça en tant je suis assez content j'était parti pour faire un TAS de rayman advance et il y en à un qui est sorti tres récemment j'aurais peut être la chance de l'améliorer :) mais merci beaucoup pour votre aide en tout cas =)
