Бывший разработчик Valve рассказал о «путешествующем во времени» баге в Half-Life 2, вызванном носком метрополицейского

Одной из самых крутых особенностей Half-Life 2 является её физический движок, но, как знает любой, кто играл в игры с физикой, даже лучшие технологии подвержены странностям. Знаменитый шутер от Valve не был исключением, как рассказал в ветке Mastodon бывший разработчик компании Том Форсайт.

В своём посте Форсайт обсуждает баг, с которым столкнулся во время работы над VR-версией Half-Life 2 ещё в 2013 году, когда Valve определяла направление развития этой технологии. HL2 была одной из самых простых для перевода в VR среди игр Valve — это был относительно свежий релиз, а «трюки с перспективой» в Portal, конечно же, были «тошнотворной катастрофой». Проблема была в том, что эта новая VR-сборка блокировала игрока всего через несколько минут после начала игры.

В начальной сцене, где офицер метрополитена должен провести игрока через дверь, дверь в VR-сборке не открывалась по непонятным причинам, замораживая игрока в ожидании сюжетного события, которое никогда не наступало. «Ох, — вспоминает Том Форсайт. — Мы не можем это выпустить. Я позвал других ребят, включая тех, кто работал над HL2 изначально, и да — она сломана. И она сломана, даже когда вы не в VR — так что это не мы с Джо что-то испортили. Но никто не знал почему — ни один соответствующий код не менялся».

Вскоре команда обнаружила, что стражник за дверью стоял «слишком близко — самый угол его ограничивающей рамки пересекался с траекторией открывания двери. Так что происходило следующее: дверь начинала открываться, слегка задевала носок стража, отскакивала назад, закрывалась и затем автоматически запиралась». Они передвинули NPC и починили баг, но потребовалось гораздо более длительное расследование, чтобы выяснить, почему это произошло изначально; VR-сборка не перемещала NPC, и команда даже перекомпилировала оригинальную сборку, чтобы обнаружить, что баг «путешествовал во времени» и существовал и в ней тоже.

Ответ был следующим: «Старый добрый floating point». Компилятор, использовавшийся для этих тестов, по умолчанию использовал более новый набор инструкций SSE, а не тот, который использовался бы по умолчанию для процессоров той эпохи — x87, у которого был «странный набор точностей». Хотя код был старым, новый компилятор означал, что игра рассчитывала физику по-другому, хотя и в крайне незначительной степени.

Форсайт пояснил: «В обеих версиях у двери было достаточно импульса, чтобы слегка повернуть стража. Трения стража о пол было недостаточно, чтобы противостоять этому, и он поворачивался на крошечную долю градуса. В версии x87 этого крошечного поворота было достаточно, чтобы убрать его носок с пути, столкновение разрешалось, и дверь продолжала открываться. Всё было хорошо.

Но в версии SSE множество мелких точностей были совсем немного другими, и комбинация трения о пол и массы объектов означала, что страж всё ещё поворачивался от столкновения, но теперь он поворачивался чуть меньше. Так что на следующем кадре симуляции его носок всё ещё был на пути двери. Дверь не могла просто пройти сквозь его носок, поэтому она делала единственное другое — отскакивала назад... и вы застревали».

Это причудливый баг, который служит отличным напоминанием, что такие вещи редко решаются так просто, как можно было бы ожидать. В следующий раз, когда вы будете жаловаться на головоломку с качелями, просто подумайте обо всём, что могло пойти не так, чтобы заставить её работать.

Этот случай демонстрирует, насколько хрупким может быть баланс в сложных физических симуляциях. Интересно, что проблема с плавающей запятой — классическая в компьютерных науках, и она до сих пор периодически всплывает в современных играх, несмотря на возросшую вычислительную мощность.