Doom non euclidien : ce qui arrive à un jeu quand pi n’est pas 3,14159 (2022) [Vidéo]

 (media.ccc.de)
3 points par GN⁺ 2024-05-18 | 1 commentaires | Partager sur WhatsApp
  • En partant de la mauvaise valeur de pi présente dans le code source de Doom, cette présentation explore comment le rendu et la perception de l’espace dans un jeu de tir à la première personne changent lorsqu’on fausse volontairement davantage des constantes mathématiques
  • Les graphismes d’un jeu reposent non seulement sur pi, mais aussi sur la trigonométrie et diverses techniques mathématiques ; de petits changements mathématiques peuvent donc affecter la manière de voir le monde et de s’y déplacer
  • Doom, FPS classique dont le code source a été publié sous GPL en 1999, pouvait ainsi servir de terrain d’expérimentation pour modifier pi, les fonctions trigonométriques et d’autres constantes
  • L’expérience revient aussi sur les techniques d’optimisation qui permettaient à Doom de bien fonctionner sur le matériel de l’époque, et fournit des indications pour compiler soi-même une version avec des mathématiques erronées
  • Elle examine si la géométrie non euclidienne peut créer une nouvelle expérience spatiale dans le jeu, et renvoie également vers d’autres jeux utilisant une valeur incorrecte de pi ainsi que vers des dépôts de code source publics

Déformer volontairement les mathématiques de Doom

  • Pi est connu comme une constante à valeur fixe, mais le code source de Doom utilise une mauvaise valeur de pi
  • Le rendu graphique dépend non seulement de pi, mais aussi de la trigonométrie et de diverses techniques mathématiques
  • L’expérience montre comment le jeu change lorsqu’on remplace dans le code source de Doom la valeur de pi par une version encore plus inexacte
  • En modifiant aussi d’autres fonctions trigonométriques et constantes, elle observe comment notre manière de comprendre et de parcourir un monde virtuel familier peut vaciller

Code source de Doom et périmètre de l’expérience

  • Doom est un grand classique du jeu de tir à la première personne
  • Le code source de Doom a été publié sous GPL en 1999
  • Le champ de l’expérience comprend notamment :
    • remplacer pi par une valeur encore plus fausse
    • remplacer d’autres fonctions trigonométriques par des valeurs erronées
    • rendre inexactes des constantes mathématiques liées

Possibilités de jeux non euclidiens

  • Changer les mathématiques peut aussi transformer la structure de l’espace virtuel que le joueur croyait connaître, ainsi que sa sensation de déplacement
  • La présentation examine si ce type de transformation peut ouvrir la voie à des possibilités de jeu intéressantes fondées sur la géométrie non euclidienne

Optimisation des performances et exécution directe

  • Elle évoque brièvement les techniques d’optimisation qui permettaient à Doom de bien tourner sur le matériel de l’époque
  • À la fin, des indications sont fournies pour compiler soi-même une version de Doom avec des mathématiques erronées

Ressources associées

  • Des liens sont aussi fournis vers d’autres jeux utilisant une valeur incorrecte de pi ainsi que vers des dépôts de code source publics
  • La vidéo de la présentation est proposée dans les contenus MCH2022 de media.ccc.de

À lire aussi

1 commentaires

 
GN⁺ 2024-05-18
Commentaires Hacker News

  • Il y avait aussi un exemple de ce genre dans le classique Duke Nukem 3D. C’était le niveau « Lunatic Fringe » créé par Richard « Levelord » Gray
    https://dukenukem.fandom.com/wiki/Lunatic_Fringe
    Ce niveau comportait un couloir circulaire extérieur structuré de façon à faire complètement deux tours sans jamais se croiser, en exploitant la capacité de séparation de zones fondée sur la connexion entre pièces du moteur Build, révolutionnaire pour l’époque. Cette fonctionnalité servait aussi à la technique des « pièces au-dessus de pièces »
    C’était amusant en multijoueur, et l’illusion d’optique tenait plutôt bien. Si je me souviens bien, la salle centrale avait 4 entrées, mais à chaque tour complet à l’extérieur, on n’en croisait que 2
    En expérimentant avec le moteur, j’avais aussi créé un niveau-jouet qui utilisait cette technique pour résoudre l’énigme consistant à « relier 3 maisons et 3 services publics sans que les lignes se croisent »

    • Je ne vois pas très bien en quel sens le cas de Duke Nukem serait « un exemple de cela ». Du côté de Duke, le programme se comporte de manière cohérente en interne, alors qu’ici, on est plus proche d’un bug aléatoire causé par une modification arbitraire du code source
      Duke peut relever d’une sorte de géométrie non euclidienne, mais dans ce Doom, le changement de pi n’a pas grand-chose à voir avec la géométrie et ressemble davantage à « garbage in, garbage out »
    • Si par « technique révolutionnaire des “pièces au-dessus de pièces” à l’époque », on entend cela, Marathon de Bungie en 1994 le permettait déjà, et le montrait sur la carte de deathmatch 5-D Space[1]
      En pratique, il n’y avait guère que Doom qui se cassait sur les secteurs qui se chevauchent
      [1] https://www.lhowon.org/level/marathon/30
    • J’avais créé il y a longtemps un petit moteur avec ce genre de fonctionnalité. À l’époque, je ne connaissais pas le moteur Build, et au lieu de suivre un arbre BSP après avoir découpé le monde en secteurs convexes, j’autorisais des liens arbitraires, c’est-à-dire des portails. Le rendu se faisait de l’avant vers l’arrière, avec découpe aux frontières des portails
      Si l’on sait rasteriser l’intérieur d’une forme convexe, on peut aussi rasteriser un monde à secteurs et portails en marquant une face donnée comme portail, en utilisant la position visible de cette face comme zone de clipping ou tampon de stencil, puis en rendant le secteur derrière avec la transformation appropriée et l’ID du secteur opposé contenus dans les données du portail
      La gestion des collisions à travers les portails est bien plus difficile que le rendu au-delà du portail
    • Dans les jeux Build plus tardifs, la technique des pièces au-dessus de pièces n’exige généralement pas que les secteurs se chevauchent ainsi. C’est une extension de la manière dont l’eau navigable était implémentée, où le moteur rend un autre secteur au lieu du sol ou du plafond
      Lunatic Fringe est un exemple frontal de géométrie impossible dans Build, mais les cartes Duke3D contiennent bien plus de géométries qui se croisent. Dans Doom, il est impossible de construire un arbre BSP avec une telle structure, et comme le joueur et les monstres ne suivent que des coordonnées X/Y, c’est évidemment impossible
    • Il existe un jeu VR intéressant appelé Tea For God. À chaque fois que l’on tourne à un angle ou que l’on prend un ascenseur dans l’espace de jeu réel, il crée astucieusement de nouveaux couloirs et de nouvelles pièces, donnant l’illusion d’un lieu immense sans jamais quitter la même pièce. Le tout sans joystick ni téléportation

  • Je lisais justement le classique Operation Chaos de Poul Anderson
    https://en.wikipedia.org/wiki/Operation_Chaos_(novel)
    L’intrigue se déroule dans un monde parallèle où la magie est réelle et progresse rapidement aux côtés de la science. Par exemple, Edwin Land y invente un dispositif utilisant la polarisation pour transformer les loups-garous sans lumière de lune
    L’enfant des protagonistes est enlevé et emmené en enfer, et ils apprennent que l’armée avait tenté d’explorer l’enfer vingt ans plus tôt, mais que tous ceux qui y étaient allés étaient devenus fous. L’antagoniste laisse entendre que, comme la géométrie spatio-temporelle de l’enfer diffère de la nôtre, il serait possible de remonter jusqu’au moment de l’arrivée de l’enfant pour aller le chercher
    À partir de ce seul indice, les scientifiques déduisent que la géométrie de l’enfer relève de la géométrie non euclidienne, puis calculent des sorts permettant d’y entrer, d’y survivre et d’en revenir sans danger. Pour trouver leur chemin, ils font appel à deux géomètres du XIXe siècle, dont l’un prie pour obtenir l’aide d’un saint

    • La géométrie spatio-temporelle de notre monde non plus n’est pas euclidienne, et elle n’est même pas de la géométrie riemannienne. Operation Chaos paraît moins scientifique que simplement plus chaotique
      Dans les œuvres de Poul Anderson que j’ai lues, par exemple l’excellent High Crusade, il aime foncer sans trop se soucier du vernis scientifique
      Parmi les autres œuvres traitant de géométrie non euclidienne, je garde aussi un bon souvenir de Inverted World de Christopher Priest
    • Cela sonnera peut-être banal, et c’est peut-être le cas, mais je ne comprends pas pourquoi on voit si peu de romans créatifs de nos jours
    • Le formidable recueil de nouvelles de Jack Vance, Tales of the Dying Earth, vaut aussi le détour. On y trouve à la fois magie/science et dimensions démoniaques
    • J’avais aimé Operation Chaos, mais la suite publiée bien plus tard m’a déçu

  • John Carmack s’est peut-être trompé en se rappelant le 10e chiffre de pi, mais tout le monde devrait chercher 84,600 dans sa codebase pour vérifier si quelqu’un n’a pas fait une faute de frappe sur le nombre de secondes dans une journée
    C’est étonnamment courant, et ça rappelle qu’il vaut mieux se demander s’il faut saisir les constantes à la main dans un programme ou utiliser une valeur déjà présente dans la bibliothèque standard du langage

  • En pratique, le rendu graphique et les déplacements deviennent bizarres, puis le jeu finit par ne plus être jouable. Plutôt que d’appeler ça Doom non euclidien, il vaudrait mieux parler de « ce qui arrive quand on touche aux constantes de l’univers »
    Si c’était vraiment un Doom non euclidien, je m’attendrais plutôt à quelque chose comme ça : https://youtu.be/kEB11PQ9Eo8?si=0HNlpGFBii2AIK1n

    • Pour pinailler un peu, cette vidéo emploie aussi mal le terme non euclidien. Les gens de HyperRogue ont réalisé quelques vidéos montrant de la vraie géométrie non euclidienne
      https://youtu.be/yqUv2JO2BCs?si=AutaqS5unvT7cDjw
      Cela dit, quand on voit dans la vidéo de Doom ces effets géométriques étranges où les objets semblent glisser sur le côté quand on avance, l’appeler non euclidien reste défendable jusqu’à un certain point
    • Ça non plus ne correspond pas à ce que signifie non euclidien. C’est juste un monde 3D ordinaire avec des portails. À l’époque, les moteurs de FPS reliaient souvent les pièces par des embrasures de porte, autrement dit des portails, pour faire du culling des parties cachées
      Ils pouvaient représenter une géométrie normale, mais celle-ci n’avait pas besoin d’être cohérente d’une quelconque manière, et des connexions arbitraires entre pièces étaient autorisées. Je ne cherche pas à ergoter, mais c’est une confusion fréquente
      Pour de la vraie géométrie non euclidienne, je recommande le travail de ZenoRogue. Il y a par exemple un petit jeu utilisant la géométrie de Nil[1], un immense combat de boss dans un roguelike en monde non euclidien[2], ou plus généralement toutes sortes d’étrangetés géométriques[3]. En fait, n’importe laquelle de leurs créations vaut le détour
      [1] https://m.youtube.com/watch?v=gejRg_q70EA&pp=ygUJemVub3JvZ3V...
      [2] https://m.youtube.com/watch?v=jcnXI8IArRI&pp=ygUJemVub3JvZ3V...
      [3] https://m.youtube.com/watch?v=yqUv2JO2BCs&pp=ygUJemVub3JvZ3V...
    • Je suis surpris que Antichamber n’ait pas encore été mentionné. C’était un excellent jeu qui transformait une idée similaire en véritables énigmes
      Maintenant que j’y pense, assez de temps a passé pour que ce soit sans doute amusant d’y rejouer
    • Ça ressemble à des portails. À l’époque, les FPS reliaient fondamentalement les pièces par des embrasures de porte, donc des portails, afin d’éliminer les parties cachées au rendu
      Ça ne posait aucun problème pour représenter une géométrie normale, mais il n’y avait aucune obligation pour que cette géométrie ait un sens, et on pouvait relier arbitrairement les pièces entre elles
    • C’est exactement ce à quoi je m’attendais aussi. Voici une autre implémentation non euclidienne qui ajoute en plus quelques idées nouvelles
      https://www.youtube.com/watch?v=tl40xidKF-4

  • Doom n’est pas une simulation, donc changer une constante ne constitue pas un très bon exemple de quoi que ce soit
    Cela revient surtout à casser quelques routines, ce qui explique pourquoi la plupart des modifications rendent le jeu injouable

    • Je ne vois pas bien pourquoi c’est intéressant. Si on remplace une constante par une mauvaise valeur, il est normal d’obtenir un comportement étrange ou des erreurs. Qu’est-ce qui pourrait arriver d’autre ? Même le comportement bizarre ne me paraît pas particulièrement remarquable, donc j’ai peut-être raté quelque chose

  • Il suffit de prendre le code source de votre émulateur de console préféré et d’y introduire une erreur en virgule flottante aléatoire, ou d’inverser la signification de certaines instructions de branchement. Plus le jeu est ancien, plus il a de chances de continuer à tourner, et plus il a de chances de ressembler à un mauvais trip hallucinatoire

    • Il existait autrefois un outil qui faisait ce genre de chose pour les émulateurs N64. Je l’ai essayé et c’était amusant pendant un moment, mais comme on pouvait s’y attendre, ça plantait souvent
      Il y avait aussi des projets de glitch art qui consistaient à corrompre des sections précises d’images et de fichiers vidéo connus pour produire quelque chose de nouveau. J’aimerais bien retrouver les deux, mais je n’y arrive pas

  • Marathon 1 (1994) prenait en charge les espaces non euclidiens, mais ne les utilisait que rarement. On pouvait jouer à l’ensemble du jeu, composé de plusieurs niveaux avec carte, et ne rencontrer un espace impossible que dans un ou deux niveaux, sans que le jeu n’avertisse ni n’indique qu’une telle chose était possible
    C’était peut-être donc le meilleur emplacement d’easter egg jamais découvert dans un jeu
    J’ai aussi trouvé une vidéo de démonstration : https://www.reddit.com/r/Marathon/comments/vclu55/probably_n...

  • La dernière question est : « quelle est la valeur maximale de pi jouable sans provoquer de plantage ? ». Si un segfault se produit quand pi vaut 4, c’est probablement parce que certains accès à la table de consultation dépassent la fin de la table ; dans ce cas, la valeur maximale jouable est sans doute juste un tout petit peu supérieure à pi lui-même

  • J’aurais aimé que cette vidéo approfondisse davantage les mécaniques du jeu et explique pourquoi la modification de Pi provoquait ce type de problèmes

  • Je me demande si cette expérience serait plus intéressante avec le Doom en ray tracing mentionné en référence. Le résultat de ce piratage de constante dans une technique de rastérisation était à peu près celui qu’on pouvait attendre. Mais avec le ray tracing, on pourrait peut-être obtenir des résultats plus intéressants