Étant donné que tout dans Transistor est présenté comme un code ou une programmation, je pense qu'il est juste de voir cela sous l'angle de l'informatique.
Alors regardons le jeu comme s'il s'agissait d'une fonction de programmation.
En informatique, on parle de récursion lorsqu'un la fonction s'appelle elle-même en elle .
Ce faisant, la fonction est réinitialisée à la première ligne. Le problème est que lorsque vous faites cela, vous avez besoin d'une condition de sortie. Une condition qui empêchera le code de toujours exécuter la fonction, d'arriver à l'appel de la fonction et de revenir au début de celle-ci. À un moment donné, il faut une condition qui empêche la fonction de s'appeler à nouveau.
Si vous considérez le jeu comme une fonction de programmation linéaire, la récursion se situe dans la fonction "Transistor", qui se réinitialise d'elle-même. Et Royce a été mis dans le Transistor à la fin de la première partie. Je suppose donc qu'ils montrent ce parcours récursif (où l'une des différences est que Royce est un "objet" qui est présent dans cette exécution de la fonction Transistor, mais qui n'était pas là dans la première exécution).
Ou pour le mettre en instructions linéaires
- Royce n'existe pas dans le Transistor. Donc le boxeur (le gars dans le Transistor) raconte la ligne.
- La fonction Transistor() suit son cours.
- Tous les éléments absorbés dans le Transistor (objet) pendant le jeu sont des objets qui existent maintenant dans la fonction Transistor. (Comme on peut voir que le boxeur, tué par le transistor, est en fait absorbé puis présent en son sein)
- Vous absorbez Royce à la fin du jeu, puis vous "recyclez", en relançant la fonction Transistor().
- Royce étant un élément désormais disponible, Royce raconte la ligne.
Ou tout simplement écrire un code approximatif de l'histoire du jeu.
var Royce = null;
function Transistor(){
Boxer.kill();
if(Royce){
Royce.NarrateIntro();
}else{ // Royce being set to null on the first play through, it goes to the else
Boxer.NarrateIntro();
}
SingGreatMusic();
RideAwesomeMotorcycle();
ShowCoolGraphics();
SurfOnCoolCloud();
Royce = new Character.Royce(); // The character Royce now exists in Transistor()
Transistor(); // The function is called again, starting back at the beginning.
//This code probably doesn't run in anything, but is just to illustrate.
}
Cela explique donc le point de vue de la programmation. Mais qu'en est-il de la narration ?
Lorsque vous commencez une partie récursive, Royce comprend que la fonction est une boucle infinie. Tout est pareil qu'au début de la fonction, sauf qu'il est maintenant aussi là.
La raison pour laquelle les autres personnages ne comprennent pas est inconnue, mais Royce est présenté comme l'un des leaders de Cloudbank, et pourrait donc être un processus plus élevé que Red ou le boxeur, et donc en savoir plus ou être plus intelligent.
La fin de la première partie a été une surprise pour lui, mais il voit maintenant que nous sommes de retour au début avec les mêmes paramètres. Donc c'est une boucle. Mince alors. Il sait donc que Red va tout recommencer, le tuer à nouveau, et recommencer. Le "programmeur" qui a codé cette fonction a merdé. Il n'y a pas de condition de sortie. Aucun point où la fonction est considérée comme terminée et où le processus se termine naturellement.
Donc dans ce contexte, lisez la ligne :
Hey Red... on ne va pas s'en sortir comme ça, n'est-ce pas ?
On ne va pas s'en sortir comme ça. Nous sommes coincés à nous battre les uns contre les autres jusqu'à ce que le processus se fige ou meure. (Et à ce moment là, ils cessent d'exister donc ce n'est pas une victoire)
TLDR : Errr... L'histoire de Transistor est une dramatisation de chaque fois que je me plante et crée une boucle infinie en programmant ?
0 votes
Les développeurs ont l'air de s'acharner sur le sujet. Au moins, il n'y a pas de raison officielle, il s'agit surtout d'interprétations.