Un jeu classique rencontre les nouvelles technologies
Half-Life 2 est célèbre pour son histoire, ses personnages et surtout sa physique. Lancer des objets avec le pistolet à gravité ou voir des choses s'effondrer de façon réaliste était époustouflant à la sortie du jeu. Mais même les jeux légendaires recèlent d'étranges bugs, parfois révélés seulement des années plus tard.
Tom Forsyth, ancien développeur chez Valve, a récemment partagé une anecdote amusante à propos d'un bug, en évoquant une ancienne expérience de réalité virtuelle. En 2013, Valve envisageait de porter Half-Life 2 en VR. Parmi ses anciens jeux, Half-Life 2 était en réalité l'un des plus faciles à adapter, du moins sur le papier. Il était suffisamment moderne et, contrairement à Portal, il ne reposait pas sur des effets de caméra complexes qui seraient désagréables avec un casque VR.
Mais dès le début du jeu, la version VR a complètement planté. Pas un plantage, pas un bug amusant, mais un arrêt brutal. Impossible de poursuivre l'histoire.
Dans la scène d'ouverture à la gare, un agent de la police métropolitaine est censé vous guider à travers une porte. Quiconque a joué à Half-Life 2 se souvient de cette introduction calme mais tendue. Dans la version VR, cependant, la porte refusait tout simplement de s'ouvrir. L'agent restait planté là, le script se bloquait et le joueur était immobilisé indéfiniment à attendre quelque chose qui ne se produisait jamais.
Le plus étrange, c'est que ce problème ne se limitait pas à la réalité virtuelle. Lorsque Forsyth et son équipe ont testé la même version sans VR, le jeu était toujours bugué. Le code source original de Half-Life 2 n'avait pourtant subi aucune modification significative. Et pourtant, l'un des premiers moments clés de l'histoire ne fonctionnait plus. Personne ne pouvait expliquer immédiatement pourquoi.
Quand le pied d'un garde fait basculer le match
Après quelques recherches, l'équipe a finalement trouvé la cause du problème. Derrière cette porte récalcitrante, un garde PNJ se tenait un peu trop près. Il ne s'agissait pas d'un problème de collision flagrant, mais le bord de sa zone de collision invisible gênait légèrement l'ouverture de la porte.
Voici ce que le moteur physique a interprété comme se produisant :
- La porte commence à s'ouvrir normalement.
- Elle effleure le pied du garde. Ce léger chevauchement est considéré comme une collision.
- La porte réagit au choc et rebondit.
- Lorsque le curseur rebondit, le script provoque le verrouillage automatique de la porte.
Résultat : l’événement narratif ne se déclenche jamais complètement. La porte ne s’ouvre jamais. Le joueur est piégé.
En théorie, le problème est facile à résoudre. L'équipe a déplacé le PNJ un peu plus loin et la porte s'est remise à fonctionner. L'affaire devrait donc être close, non ? Pas tout à fait.
Ils voulaient savoir pourquoi ce bug était apparu soudainement après toutes ces années. L'ancienne version de Half-Life 2 n'avait jamais présenté ce problème. Ils ont donc tenté de recompiler le code source du jeu original avec leurs outils actuels pour voir ce qui avait changé. Étrangement, le bug était également présent. C'était comme si le problème avait voyagé dans le temps et infecté cette version passée.
Rien n'avait changé dans la logique du jeu. Le script du niveau était identique. Les données de la porte et du garde étaient les mêmes. Alors pourquoi l'orteil du garde est-il soudainement devenu fatal au script ?
La puissance des petits nombres
La solution résidait dans un aspect souvent négligé par les joueurs : les calculs en virgule flottante. En coulisses, la physique du jeu repose sur une multitude d'équations résolues plusieurs fois par seconde. Ces calculs utilisent des nombres à virgule flottante, le format de stockage des valeurs décimales telles que 0,1 ou 3,14159.
C'est là que ça se complique. Les différentes générations de processeurs et de compilateurs gèrent les décimales de manières légèrement différentes. Lors de sa sortie initiale, Half-Life 2 utilisait le jeu d'instructions x87. Ce système possède des règles de précision particulières et parfois incohérentes. Des années plus tard, lorsque Forsyth a recompilé le jeu, le compilateur a opté pour un jeu d'instructions plus récent appelé SSE. Plus moderne et plus cohérent, le SSE gère néanmoins ces subtilités décimales différemment.
Normalement, ces différences microscopiques sont négligeables. Mais les moteurs physiques sont chaotiques. Une infime modification d'une valeur peut avoir un impact visible plusieurs images plus tard.
Forsyth l'a décomposé ainsi :
- Dans les deux versions, lorsque la porte heurte le garde, elle le repousse légèrement.
- Cette poussée imprime au garde une légère impulsion de rotation. Il amorce une rotation d'une fraction de degré.
- Le sol exerce une friction qui tend à freiner ce mouvement. Le gardien possède également une masse, ce qui influe sur sa façon de se déplacer.
Dans la version x87 originale, cette légère rotation suffit à peine à dégager l'orteil du garde de la trajectoire de la porte. La collision est résolue, la porte continue de s'ouvrir et le joueur la franchit normalement.
Dans la version SSE recompilée, les mêmes calculs donnent des résultats légèrement différents. La garde tourne toujours, mais un peu moins. Cela signifie qu'à l'image suivante de la simulation, son orteil touche encore la trajectoire de la porte. Le moteur physique ne permettant pas à la porte de traverser un objet solide, il choisit l'autre option possible : il fait rebondir la porte et la verrouille.
Il ne s'agissait pas d'une simple erreur de script. Le problème résultait de minuscules différences numériques au cœur des instructions mathématiques du processeur, entraînant une expérience de jeu totalement différente.
C'est un parfait exemple de la fragilité des systèmes de jeu en coulisses. Modifier le matériel, les compilateurs, ou même de petites optimisations peut réveiller des bugs qui étaient toujours présents, latents, mais jamais exploités.
Alors la prochaine fois que vous tenterez de résoudre un casse-tête à bascule, de vous débattre avec une plateforme mobile ou de rire en voyant un personnage en chiffon traverser la carte, souvenez-vous d'histoires comme celle-ci. Sous votre jeu, une multitude de nombres invisibles s'efforcent de déterminer l'emplacement de chaque orteil, de chaque porte et de chaque caisse. Parfois, il suffit d'un garde un peu trop près d'une porte pour faire dérailler un jeu classique.
Article et image originaux : https://www.pcgamer.com/games/fps/a-former-valve-dev-revealed-how-while-a-vr-version-of-half-life-2-was-being-made-a-single-metro-cops-toe-created-a-time-travelling-bug-that-softlocked-all-versions-of-the-game/
