Un bug vieux de 55 ans découvert dans le premier jeu Lunar Lander
(martincmartin.com)- En vérifiant le planning optimal de carburant pour l’atterrissage dans le premier jeu Lunar Landing, créé en 1969 par le lycéen Jim Storer, un bug est apparu : le jeu considérait à tort comme encore en vol un moment où le module aurait dû avoir atterri
- La stratégie en question est un suicide burn : couper le moteur pendant 70 secondes, brûler ensuite 164,31426784 lbs/sec pendant 10 secondes, puis passer au maximum de 200 lbs/sec ; le jeu rate alors l’atterrissage en douceur qui devrait se trouver entre un atterrissage brutal et une remontée sans contact
- Le code original ne faisait pas une simple intégration d’Euler : il utilisait l’équation de Tsiolkovski et des séries de Taylor pour calculer le mouvement sur des tours de 10 secondes, un niveau de sophistication remarquable pour le travail d’un lycéen sur PDP-8 en 1969
- La cause du bug est l’absence d’une division par 2 dans le dénominateur à l’intérieur de la racine carrée d’une formule approximant le point le plus bas de la trajectoire avant le contact avec le sol, ce qui sous-estimait systématiquement le temps nécessaire pour atteindre ce point
- En corrigeant ce facteur 2 manquant et en supprimant la correction de 0,05 seconde, le résultat du suicide burn s’améliore jusqu’à 1,66 MPH, mais l’atterrissage parfait sous 1 MPH reste hors d’atteinte à cause des limites de l’approximation aux deux premiers termes de la série de Taylor et du recalcul du moment d’atterrissage
Lunar Landing en 1969 et la recherche de l’atterrissage optimal
- Quelques mois après l’alunissage de Neil Armstrong, Jim Storer, alors élève à Lexington High School dans le Massachusetts, a écrit le premier jeu Lunar Landing
- En 1973, le jeu était assez répandu pour être décrit comme “by far and away the single most popular computer game”
- Le jeu est textuel, et tous les mouvements du module lunaire se font uniquement dans la direction verticale
- Le joueur choisit, toutes les 10 secondes de simulation, la quantité de carburant à brûler et doit se poser le plus doucement possible à la surface de la Lune
- En cherchant le planning de carburant optimal, la stratégie théoriquement meilleure ne fonctionnait pas correctement dans le jeu
- En réalité, le module était en train de toucher la surface
- Le jeu concluait à tort qu’il ne l’avait pas touchée
- La cause finale était une division par deux manquante passée inaperçue pendant près de 55 ans
Atterrissage à carburant minimal et suicide burn
- Pour atterrir avec un minimum de carburant, il faut descendre dans le temps le plus court possible
- La stratégie optimale consiste à couper le moteur au début pour prendre de la vitesse, puis à freiner à poussée maximale au tout dernier moment possible afin que la vitesse soit proche de 0 au contact avec la surface
- La communauté Kerbal Space Program appelle cette stratégie un suicide burn
- Parce que le timing est extrêmement serré et laisse très peu de marge d’erreur
- Le planning trouvé par essais successifs et recherche binaire manuelle est le suivant
- Ne brûler aucun carburant pendant 70 secondes
- Brûler du carburant à 164,31426784 lbs/sec pendant les 10 secondes suivantes
- Brûler ensuite au maximum, soit 200 lbs/sec
- Le jeu considère qu’un atterrissage sous 1 MPH est parfait
- Avec ce planning, l’atterrissage se fait à plus de 3,5 MPH et reçoit l’appréciation “could be better”
- Pourtant, si l’on brûle seulement 0,00000001 lbs/sec de carburant en plus, le module ne touche pas la surface et remonte à 114 MPH
- Autrement dit, le verdict d’atterrissage en douceur qui devrait exister entre un atterrissage brutal et une remontée sans atterrissage avait disparu
Une physique plus sophistiquée que prévu
- Au départ, on pouvait s’attendre à une intégration d’Euler, courante même dans des jeux actuels
- Calculer la force au début de l’intervalle de temps
- Obtenir l’accélération avec F=ma
- Supposer que l’accélération reste constante pendant cet intervalle
- Le code réel de Lunar Landing était plus sophistiqué
- Jim Storer utilisait la solution exacte de la Tsiolkovsky rocket equation
- Pour calculer les logarithmes, il appliquait un développement en série de Taylor
- La valeur maximale de l’argument est 0,1212
- Avec 5 termes, la précision dépasse 6 chiffres
- Des simplifications algébriques réduisaient aussi les erreurs d’arrondi
- Jim Storer se souvient qu’il était alors familier avec des notions comme le calcul différentiel et les séries de Taylor, et que son père, physicien, l’a aidé à dériver les équations
- Le fait que le suicide burn soit optimal découle aussi de cette équation de la fusée, et ce n’était pas la source du bug
Pourquoi la détection du contact avec le sol est délicate
- L’équation de la fusée fonctionne bien jusqu’à ce que le module touche le sol
- Les collisions entre objets solides sont une zone difficile dans les moteurs physiques, et Lunar Landing rencontre aussi sa principale difficulté dans la détection du contact avec le sol
- Vérifier seulement le début et la fin d’un tour de 10 secondes ne suffit pas
- Au début, le module peut être en descente
- À la fin, il peut être en remontée
- Entre les deux, il a pu passer sous la surface puis remonter
- Dans ce cas, le programme doit remonter le temps pour trouver le moment de contact plus précoce
- Le point naturel à tester est le point le plus bas de la trajectoire, où la vitesse devient nulle
- À partir de l’équation de la fusée, ce point le plus bas ne peut pas être exprimé sous forme fermée avec les fonctions mathématiques de base
- Une note explique que la fonction Lambert W serait nécessaire
- On peut l’approximer en ne gardant que les premiers termes de la série de Taylor du logarithme
- En n’utilisant que les deux premiers termes, le problème se réduit à une équation du second degré
- On peut alors utiliser la quadratic formula de niveau lycée
- Sur un tour de 10 secondes, on peut espérer une précision d’environ 0,1 %
Formule quadratique alternative et stabilité numérique
- Dans le code de Jim Storer, la racine carrée apparaît au dénominateur et non au numérateur
- Cela ne correspond pas à la formule quadratique habituelle, mais à une forme alternative de la quadratic formula où la racine carrée est en bas
- Cette forme alternative a un avantage numérique important
- Après avoir détecté le contact avec le sol, le temps de contact réel est lui aussi recherché en tronquant la série de Taylor pour l’approximer par une équation du second degré
- La forme habituelle entraîne une division par zéro lorsque le coefficient du terme quadratique vaut 0
- Cela se produit quand la poussée de la fusée équilibre exactement la gravité
- C’est une situation qui peut être fréquente pour un joueur flottant près de la surface ou descendant lentement
- Lorsque la poussée est proche de la gravité, la forme habituelle provoque une catastrophic cancellation au numérateur, et le petit dénominateur amplifie l’erreur
- La forme alternative fonctionne aussi correctement dans le cas d’une équation linéaire, quand le terme quadratique vaut 0
- Le fait qu’un lycéen de 1969 ait redérivé ou appris cette forme est impressionnant au regard du contexte de l’époque
Le vrai bug : un facteur 2 manquant
- En dérivant la formule et en la comparant directement, elle correspondait presque au code de Jim Storer, mais le 2 qui devait se trouver dans le dénominateur à l’intérieur de la racine carrée manquait
- Cette omission est probablement une simple erreur survenue pendant la dérivation de la formule ou sa saisie dans l’ordinateur
- À l’époque, MACSYMA n’existait que depuis un an et n’était pas disponible dans un lycée ; il fallait donc faire les dérivations au papier et au crayon
- À cause de ce bug, le temps jusqu’au point le plus bas était systématiquement sous-estimé
- Le code compensait cela de deux manières
- Il ajoutait 0,05 seconde
- Il refaisait une estimation depuis une position nouvelle et plus proche
- Mais dans certains scénarios de suicide burn, cette correction faisait manquer le moment de l’atterrissage
- La première estimation correspond à un moment où le module est encore au-dessus de la surface et descend toujours
- La deuxième estimation correspond à un moment où le module a dépassé le point le plus bas et remonte
- L’écart entre les deux peut devenir inférieur à 0,05 seconde
Résultat après correction et limites restantes
- En ajoutant le facteur 2 manquant et en supprimant la correction de 0,05 seconde, le résultat du suicide burn s’améliore
- Après correction, le meilleur suicide burn donne une vitesse d’atterrissage de 1,66 MPH
- Il se rapproche d’environ trois quarts du chemin vers l’atterrissage parfait sous 1 MPH
- La raison pour laquelle ce n’est pas parfait est que seuls les deux premiers termes de la série de Taylor sont toujours utilisés
- Une fois que le point le plus bas est jugé sous la surface, il faut retrouver le premier moment où la surface est touchée
- Ce processus utilise une approximation similaire
- Des itérations supplémentaires pourraient aider
- Une fois le bug corrigé, le temps est surestimé, si bien qu’il peut être nécessaire de revenir en arrière dans le temps
- Dans ce cas, il pourrait aussi falloir choisir l’autre solution de l’équation du second degré
- Plus simplement, on pourrait n’utiliser qu’un seul terme de la série de Taylor et procéder d’une manière proche de la Newton’s method
- Une autre option serait de s’arrêter quand la norme de la vitesse passe sous un certain seuil, puis de décider de l’atterrissage à partir de l’altitude à cet instant
- Mais ces changements rendraient le code plus complexe, alors que le jeu original était déjà tout à fait amusant à jouer
Pourquoi le bug a pu rester si longtemps
- Les atterrissages en douceur restent possibles
- Terminer le 14e tour à basse altitude et faible vitesse
- Utiliser une faible poussée au 15e tour
- Atterrir quelque part après 150 secondes
- Le cas problématique est le suicide burn à poussée maximale théorique, qui se termine vers 148 secondes
- Dans l’ensemble, ce code est très impressionnant pour un travail réalisé sur PDP-8 en 1969 par un lycéen de 18 ans
- À l’époque, l’informatique n’était pas encore enseignée au lycée, et les notions de calcul numérique comme l’amélioration itérative d’une estimation par la méthode de Newton ou la prise en compte de la catastrophic cancellation n’étaient pas largement connues
- Le bug est probablement resté inaperçu près de 55 ans parce que, malgré lui, le jeu restait difficile et amusant, et les atterrissages en douceur étaient possibles
- Le fait de chercher non seulement à gagner, mais à trouver la stratégie optimale, a conduit à comprendre cette petite incohérence
1 commentaires
Avis sur Hacker News
Plus tard, il a même fourni le code source, ce qui était vraiment génial
https://technologizer.com/2009/07/19/lunar-lander/index.html
Mon passage préféré est celui où Storer dit : « Je n’avais plus repensé à ce jeu depuis la fin du lycée. Jusqu’à ce que quelqu’un m’envoie un e-mail à ce sujet il y a quelques mois, je ne savais même pas du tout qu’il existait d’autres jeux Lunar Lander que celui que j’avais créé au lycée. »
En 1989, quand j’ai postulé à un emploi lié à Lotus Notes, j’ai montré le jeu Lander à l’intervieweur, Tim Halvorsen, et il m’a dit : « C’est chouette, essayons de le faire tourner sous Windows 3 »
Au début, j’ai trouvé ça bien de pouvoir voir Windows 3 avant même sa sortie, mais il a vite ajouté : « Windows 3 exécute tout en mode protégé, donc si un pointeur sort de sa plage, ça plantera immédiatement », et il a proposé de tester
J’ai été sur des charbons ardents pendant toute l’exécution, mais heureusement Lander n’a pas planté, Tim a été satisfait, et j’ai finalement obtenu ce poste, ce qui a complètement changé ma carrière
Je ne trouve pas de photo, mais de mémoire cela ressemblait à ce genre de machine
https://content.invisioncic.com/r322239/monthly_10_2015/post...
Sauf qu’il y avait du relief et des cratères, et qu’il fallait se poser dans le cratère allumé. Quand le vaisseau appuyait sur le bouton au centre du cratère, la lumière s’éteignait et un autre cratère s’allumait ; si la visée était mauvaise, il heurtait le bord, basculait et c’était l’échec
En y repensant, les commandes étaient peut-être plutôt comme une machine à pince : on s’alignait par le dessus, puis on appuyait sur « land ». Il y en avait une autrefois à la Main Street Arcade de Disneyland
J’ai trouvé un peu étrange que l’article répète plusieurs fois que c’était « impressionnant pour un lycéen de terminale en 1969 ». Pour des personnes orientées technique qui ont grandi à l’ère spatiale, cela a dû avoir une influence énorme, et cela me rappelle aussi le vieux film October Sky
Dans l’interview originale, le créateur du jeu disait être bon en calcul différentiel et intégral ; donc s’il avait de l’intérêt et du talent pour l’espace ou les fusées, tenter de programmer un jeu d’alunissage paraît assez naturel
[1] : https://www.cs.brandeis.edu/~storer/LunarLander/LunarLander/...
L’ère spatiale a peut-être été une source d’inspiration, mais pour le grand public de l’époque, les ordinateurs n’existaient pour ainsi dire pas, et le développement logiciel n’était pas non plus un métier largement connu. Les cursus d’informatique aux États-Unis ne sont apparus qu’en 1962 ; le fait qu’il ait été en terminale en 1969 est donc assez remarquable
J’allais dans un grand lycée d’une ville assez importante dotée d’une grande école d’ingénieurs, mais le principal obstacle était l’accès aux ordinateurs
Le lycée avait un télétype connecté à un mainframe distant, et avec des amis nous avions trouvé quelques ordinateurs universitaires utilisables la nuit, mais la plupart n’avaient que des lecteurs de cartes et des imprimantes ligne, sans aucun terminal graphique
À l’époque, la combinaison compétences, intérêt et accès devait être assez rare
https://retro365.blog/2021/12/02/bits-from-my-personal-colle...
Wikipedia à propos de FOCAL :
https://en.wikipedia.org/wiki/FOCAL_(programming_language)
En physique de lycée, partir d’un diagramme des forces et traiter les deux forces que sont la gravité et la poussée, c’est à la portée d’un élève moyen qui obtient A en physique
Mais la gravité dépend de la distance au centre, donc d’une valeur qui change en permanence. Il faut savoir que, même si l’on commence à 120 miles d’altitude, la variation n’est pas très grande et qu’on peut donc l’approximer par une constante
La façon dont la poussée fonctionne en fonction du taux de combustion est aussi obscure. Si l’on double le débit de carburant, la vitesse des gaz d’échappement double-t-elle aussi ? Comment P et T changent-ils dans la loi des gaz parfaits PV=nRT ? Ce sont le genre de questions qui se posent
Donc s’il a demandé à son père physicien, puis trouvé les caractéristiques des moteurs-fusées et l’équation de Tsiolkovski, cela suffit déjà à être impressionnant pour un élève de terminale
Pour passer de la vitesse à la position, il faut intégrer, et je ne sais pas si un élève moyen ayant A en physique aurait l’idée de remplacer un appel FLOG() par une série de Taylor puis d’intégrer terme à terme
Les détails comme le nombre de termes de la série de Taylor à utiliser, ou la question de la convergence, sont eux aussi délicats. Si Jim a réfléchi à ces subtilités, c’est remarquable ; il est aussi possible qu’il ait simplement choisi 5 termes parce que cela lui semblait beaucoup
Même si la simulation au voisinage de la Lune fonctionnait, il restait aussi le problème de détecter la collision avec le sol. Plutôt que de résoudre directement l’instant où l’altitude devient 0, l’idée de regarder le point où la vitesse devient 0, qui apparaît exactement une fois pendant la rotation, est assez créative
Inverser l’équation de la fusée pour obtenir la quantité de carburant nécessaire à partir d’un delta-V donné dépasse aussi ce qu’on fait avec les maths de lycée et un peu de calcul différentiel. En pratique, il faut une nouvelle fonction comme la fonction W de Lambert
Au final, comme il faut résoudre un polynôme du 5e degré par série de Taylor, il fallait décider de jeter les termes de degrés 3, 4 et 5 pour en faire une équation du second degré. Le fait d’avoir jugé qu’on pouvait ici négliger des termes qu’on ne négligeait pas d’habitude dans les calculs de dynamique est impressionnant, car cela montre qu’il comprenait qu’on peut utiliser différents niveaux d’approximation selon les situations
De plus, le fait qu’il ait utilisé d’une manière ou d’une autre une forme alternative de l’équation du second degré suggère qu’il ne s’est peut-être pas contenté de la trouver et de la recopier
Il fallait arriver rapidement à l’horizontale, puis ralentir avec les boutons des propulseurs latéraux du LEM et du moteur principal pour se poser verticalement ; si l’on allait trop vite ou que le carburant venait à manquer, un cratère apparaissait, et selon la qualité de l’atterrissage, un ou plusieurs drapeaux américains étaient plantés
Il y a quelques années, pensant que le code source n’avait aucune valeur et ne serait jamais réutilisé, j’ai jeté l’unique copie ; je l’ai regretté plus tard en réalisant que c’était un jeu graphique historiquement assez précoce et qu’il aurait pu être ressuscité par une émulation simple
En la revoyant 25 ans plus tard, j’ai été stupéfait par le nombre absurde de bugs et par une logique embrouillée du genre « 440 IF GOTO 450 »
J’ai fini par la réécrire une fois adulte [1], mais l’enfant que j’étais n’avait aucune chance. Aujourd’hui encore, je me demande comment, au sein de cette maison d’édition espagnole oubliée, un code qui fonctionnait presque a pu se transformer en quelque chose ressemblant à la version finale
[1] https://7c0h.com/blog/new/moon_landing_in_basic.html
Ce type de code BASIC avait ses racines dans les années 1960-1970, et dans les magazines papier et recueils de code qui publiaient alors du code, les éditeurs avaient un pouvoir important
L’idée qu’il fallait reproduire le code source tel quel, sans en changer un seul caractère, était peu répandue ; les éditeurs « corrigeaient » donc souvent le code source avec prudence, en pensant traiter des fautes de frappe « évidentes » ou exercer un jugement éditorial
À partir des années 1980, l’industrie a commencé à s’améliorer dans son ensemble, et cette leçon — ne pas toucher au code source dans les publications imprimées — a été apprise lentement et douloureusement
Je me demande si cette évolution n’a pas favorisé l’essor des BBS et affaibli le pouvoir qu’avaient les médias imprimés sur la distribution du code source. Si les détenteurs du pouvoir dans la presse papier avaient été plus ouverts à l’idée que des personnes extérieures gardent un contrôle absolu sur une partie de « leur » contenu, l’histoire aurait peut-être été différente
Quand j’étais enfant, j’ai commencé à coder sans aide d’adulte, seulement avec quelques livres de programmation trouvés à l’école et à la bibliothèque locale ; avec le recul, il est presque étonnant que j’aie continué à coder alors que tant de programmes recopiés à la main étaient eux aussi truffés d’erreurs
Pour ajouter un mot sur la logique embrouillée du type « 440 IF GOTO 450 », une partie du code du livre avait clairement besoin d’être nettoyée, mais il est très probable que le BASIC courant des ordinateurs domestiques de l’époque ne gérait que les numéros de ligne et disposait d’instructions de branchement très limitées
Le BASIC utilisé semble prendre en charge la programmation structurée, ce qui était très rare sur les ordinateurs domestiques de l’époque. En 1984, un magazine C64 a publié une longue série, sur au moins trois numéros, pour présenter à ses lecteurs les merveilles de la programmation structurée
Les contraintes de l’instruction IF étaient telles que les branchements conditionnels façon assembleur avec GOTO étaient très courants, et en pratique nécessaires
L’imbrication de IF était impossible, et pour combiner plusieurs IF, il fallait sauter par-dessus les parties non sélectionnées. Le BASIC Commodore/C64, en pratique Microsoft BASIC, n’avait même pas de ELSE ; on imitait donc généralement une branche ELSE avec une condition négative et un saut
Le BASIC du C64 avait aussi ce comportement particulier où les autres instructions de la même ligne faisaient partie du THEN. Par exemple,
10 IF A=1 THEN PRINT “FOO” : PRINT “BAR”affiche FOO BAR si A=1, et n’affiche rien sinonBien sûr, cela ne marchait que si l’on pouvait faire tenir les instructions dans une seule ligne limitée. D’autres dialectes BASIC considéraient
PRINT “BAR”comme en dehors du ELSE, ce qui était plus propre syntaxiquement, mais pouvait être moins pratique selon les fonctionnalités offertes par le dialecteLes commodités et la rigueur que nous considérons aujourd’hui comme acquises n’existaient pas. Le BASIC du C64 avait beaucoup de bizarreries qui semblaient issues de son implémentation, ce qui le faisait paraître particulièrement « sale ». Par exemple, toutes les fonctions devaient prendre un argument même lorsqu’il était inutile ; pour afficher la mémoire restante, il fallait donc écrire quelque chose d’absurde comme
?FRE(123)Plus on « joue » tôt le 199.99999999, mieux c’est ; il suffit donc de faire une recherche exhaustive pour choisir l’entrée la plus précoce qui donne un atterrissage en douceur
Pour que le jeu reconnaisse l’atterrissage, l’altitude doit être inférieure à 0 pendant environ 0,05 seconde. Si, pendant ce laps de temps, la poussée vaut 200 ou 199, alors pour que l’altitude reste négative aussi longtemps, la vitesse au point d’altitude 0 doit dépasser 1 MPH
Même après correction du bug, le code ne fait toujours qu’approximer le point le plus bas. Après avoir détecté l’atterrissage, il doit encore calculer l’instant réel de l’atterrissage, c’est-à-dire le moment où l’altitude, et non la vitesse, vaut 0, et cela utilise aussi une approximation
Le temps peut donc être légèrement décalé. Si, au dernier pas de temps, on est en train de brûler à 200 ou 199, l’accélération est forte et une infime erreur de temps peut entraîner une grande erreur de vitesse
En revanche, si l’on brûle à environ 10 lbs/sec, même un décalage d’environ 0,08 seconde ne change pas beaucoup la vitesse
Je me demande si cela veut dire que plus le taux de rafraîchissement est faible, moins cette méthode est précise, ou si c’est juste pour le plaisir d’utiliser les vraies équations.
Je me demande aussi à quel point la différence entre les deux méthodes se faisait sentir avec le taux de rafraîchissement d’origine.
https://www.cs.brandeis.edu/~storer/LunarLander/LunarLander/...
Si l’on ne met à jour la masse et l’accélération que toutes les 10 secondes, cela devient extrêmement imprécis.
Du point de vue de la précision physique, surtout près de la surface, la masse varie de façon assez importante si le débit de combustion du carburant est élevé. Mais du point de vue de la difficulté ou du plaisir du jeu, et de la stratégie du joueur, je ne pense pas que cela change grand-chose.
En fait, l’une des autres simulations d’alunissage du livre BASIC computer games semble utiliser cette approche naïve.
Si 10 secondes, c’est trop long, on peut conserver un tour d’interface utilisateur de 10 secondes, tout en découpant en interne chaque tour plus finement, par exemple en 10 pas de temps d’une seconde.
Le jeu existant le fait déjà dans certains passages, si bien que la simulation physique ne prend pas toujours 10 secondes entières, mais une durée arbitraire S en entrée.
Mais il n’y avait pas de jeu d’atterrissage, et Storer était bien le premier. On trouve ici une histoire intéressante à ce sujet :
https://www.acriticalhit.com/moonlander-one-giant-leap-for-g...
Même sans calculer l’effet de l’allègement de l’engin à mesure qu’il brûle du carburant, c’est-à-dire même en retirant ce que fait ici l’équation de la fusée, le suicide burn reste optimal.
La vraie raison est que le suicide burn minimise les pertes gravitationnelles.
https://en.wikipedia.org/wiki/Gravity_loss
Mon intention était de dire que la dynamique comporte deux parties, l’équation de la fusée et la gravité, et que les deux s’additionnent linéairement. La vitesse supplémentaire créée par la gravité doit être annulée en augmentant le delta-V de l’équation de la fusée.
Le delta-V dû à la gravité étant l’accélération gravitationnelle multipliée par le temps, il faut minimiser le temps.
Étonnamment, dans l’équation de la fusée, le temps que cela prend, l’ordre des combustions, le fait de brûler en continu à vitesse constante ou par poussées brèves et puissantes n’ont pas d’importance.
Donc, pour atterrir à vitesse nulle avec un minimum de carburant, il faut atterrir dans le temps le plus court possible.
Je n’ai jamais réussi à trouver moi-même comment atterrir, mais je me souviens que quelqu’un m’avait montré la technique consistant à continuer sur l’inertie pendant les premiers tours, puis à appliquer la poussée maximale. À l’époque, je ne me souviens pas du terme « suicide burn ». C’est peut-être un terme apparu plus tard, après que Kerbal Space Program est devenu connu.
Je me souviens aussi qu’au milieu des années 1970, au Lawrence Hall of Science de Berkeley, ce jeu d’alunissage tournait sur quelques terminaux. Je ne sais pas sur quel ordinateur il s’exécutait.
Je n’ai jamais vu le code source de ce programme, et je ne savais pas du tout que les mathématiques étaient aussi sophistiquées. À l’époque j’étais trop jeune pour les comprendre, et honnêtement je ne suis même pas sûr de pouvoir les comprendre aujourd’hui.
Une « fonctionnalité » du mode kiosque destiné aux jeux était qu’un Ctrl-C bien synchronisé permettait d’en sortir et de jouer à d’autres jeux.
Était-ce un hasard, ou un appât lancé aux premiers hackers ?