Un ancien développeur de Valve a partagé une anecdote particulièrement intéressante sur le jeu du studio !
L’un des atouts les plus impressionnants de Half-Life 2, c’est son moteur physique, mais même la meilleure technologie n’est pas à l’abri de comportements bizarres. Le légendaire FPS narratif de Valve ne fait pas exception, comme l’a raconté l’ancien développeur de Valve Tom Forsyth sur Mastodon. Il y décrit un bug rencontré pendant le développement de la version VR de Half-Life 2 en 2013, à l’époque où Valve se demandait encore dans quelle direction pousser cette technologie. C’était l’un des jeux les plus faciles à porter en VR dans le vieux catalogue de Valve – il était relativement récent, et les astuces de perspective de Portal provoquaient naturellement des catastrophes nauséeuses. Cette nouvelle version VR parvenait même à softlocker les joueurs dès les premières minutes de jeu.
Dans la scène d’introduction, un policier du métro est censé escorter le joueur à travers une porte. Pour une raison inconnue, la porte ne s’ouvrait pas dans la version VR, ce qui bloquait le joueur, condamné à attendre un événement scénaristique indispensable qui ne survenait jamais. Forsyth a expliqué qu’ils ne pouvaient pas sortir le jeu dans cet état. Il a sollicité l’avis d’autres personnes, y compris de développeurs ayant travaillé à l’origine sur Half-Life 2, mais même en dehors de la VR, le problème persistait, et personne ne comprenait pourquoi. L’équipe a fini par découvrir que le garde posté derrière la porte se tenait un peu trop près – le coin de sa hitbox croisait la trajectoire de l’ouverture de la porte. Ainsi, lorsque la porte s’ouvrait, elle poussait légèrement l’orteil du garde, rebondissait, se refermait, puis se verrouillait automatiquement.
Ils ont déplacé le PNJ et corrigé le bug, mais il a fallu une enquête bien plus longue pour comprendre pourquoi le problème se produisait au départ. La version VR ne déplaçait pas le PNJ, et l’équipe a même recompilé la version originale pour vérifier si le bug « traversait le temps » et se manifestait également là. Le compilateur utilisé pour les tests s’appuyait par défaut sur le plus récent jeu d’instructions SSE plutôt que sur l’ancien x87, qui était la norme sur les CPU de l’époque et dont la précision est très variable. Même si l’on parlait d’un vieux code, ce nouveau compilateur faisait calculer la physique légèrement différemment au jeu, de manière extrêmement subtile.
Dans les deux versions, la porte reçoit juste assez de momentum pour faire pivoter très légèrement le garde. La friction entre ses pieds et le sol n’est pas suffisante pour empêcher ce mouvement, et il se tourne d’un infime angle. Dans la version x87, cette petite rotation dégage suffisamment son orteil pour qu’il ne bloque plus le passage ; la collision se résout, et la porte continue de s’ouvrir. Tout va bien. Dans la version SSE, en revanche, une multitude de détails minuscules diffèrent légèrement. La friction avec le sol et la masse combinée des objets font que le garde continue de pivoter un peu après la collision, mais cette fois un peu moins. Ainsi, dans la frame suivante de la simulation, son orteil se trouve toujours sur le chemin de la porte. Celle-ci ne peut pas traverser son pied, rebondit, et nous restons bloqués.
C’est un bug étrange et retors, et un excellent rappel que ce genre de problème est rarement aussi simple à résoudre qu’on pourrait l’espérer.
