Как одновременно работать над основной игрой и ремастером
Gamedev
Владимир Семыкин

«Двери — отстой»: как небольшой физический баг двери сломал Half-Life 2 Статьи редакции

Даже спустя десять лет после релиза игра может подкинуть неприятный сюрприз.

Разработчик из Valve Том Форсайт опубликовал в Твиттере тред, в котором рассказал о неожиданных проблемах, возникших при разработке VR-версии Half-Life 2 из-за дверей. Форсайт уточнил, что эти события происходили примерно в 2013-2014 году. Мы выбрали из треда главное.

Сцена, в которой внезапно появился баг

Мы привыкли к тому, что в реальной жизни двери чаще всего устроены достаточно просто. Но в играх — это сложный элемент дизайна, с которым связано множество потенциальных проблем. К примеру, недавно геймдиректор The Last of Us Part II Курт Маргено подробно описал в Твиттере трудности, которые вызвали двери, а мы пересказали его тред.

По словам Форсайта, когда разработчики решили добавить VR-режим в Half-Life 2, они поняли, что придётся менять код рендеринга. Но при этом они не вносили никаких изменений в код геймплея. Это значит, что по сути игра осталась всё той же, но с новым режимом.

Когда Форсайт выполнил всю работу и готовился отправить билд, он решил полностью перепройти игру. Разработчик посмотрел начальную сцену, сошёл с поезда, закинул банку в мусорку и так далее. Всё было нормально, пока Барни, который скрывался под маской охранника, не постучал в дверь — далее она открылась... и тут же закрылась, хотя этого не должно было произойти. На этом моменте всё замерло и больше ничего не происходило.

В скриптах NPC не было прописано, что он должен открывать дверь дважды — изначально одного раза было достаточно. В результате вся игра заглохла. При этом игрок тоже не мог открыть эту дверь — это должен был сделать только определённый персонаж. Форсайт попробовал перезагрузиться, но результат всегда был один и тот же. Для разработчика стало очевидно, что они что-то сломали. Он предположил, что всё дело в изменениях рендеринга — это основное, чем команда занималась.

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

Форсайт делал всё это на основе старого кода, но при этом использовал новую версию компилятора. Старый компилятор применял стандарт 8087 для всех математических вычислений. В новом компиляторе его нет — сейчас применяется SSE. У этих компиляторов немного различается точность вычислений. В результате получилось, что новая версия иначе просчитала значения, что повлияло на физику игры.

Какое-то крохотное изменение привело к тому, что именно эта сцена не работала, а со всей остальной игрой всё было в порядке. Но это не объясняет, почему скрипт не срабатывал как надо.

Вот что должно было происходить. Когда охранник толкает дверь, она должна распахнуться на максимум — тогда она фиксируется в таком положении, а сцена продолжается по сценарию. Оказалось, что главный недостаток заключается в физике — когда охранник толкает дверь, она начинает двигаться на основе физических законов, а не по скриптам. Скрипт включается в тот момент, когда она распахивается на максимум.

Всё это не срабатывало, потому что дверь не раскрывалась на максимум — ей мешал стоящий рядом охранник: она цеплялась самым краем. Со старым компилятором дверь оказывалась достаточно тяжёлой, чтобы оттолкнуть персонажа и достичь точки, в которой она фиксируется. А новая версия компилятора посчитала, что силы недостаточно, поэтому дверь отскакивала от охранника и закрывалась.

Двери — отстой. Даже старые надёжные двери, которые работают десятилетиями, — отстой.

Том Форсайт
разработчик из Valve
{ "author_name": "Владимир Семыкин", "author_type": "editor", "tags": ["\u043e\u043f\u044b\u0442","halflife"], "comments": 115, "likes": 498, "favorites": 218, "is_advertisement": false, "subsite_label": "gamedev", "id": 686938, "is_wide": true, "is_ugc": false, "date": "Sat, 10 Apr 2021 11:43:11 +0300", "is_special": false }
0
115 комментариев
Популярные
По порядку
Написать комментарий...
276

Мало кто знает, но именно двери из HL2 стали главной причиной вступления капитана Прайса в ряды SAS.

Ответить
61

Этой дверью был Альберт Энштейн

Ответить
13

амогус

Ответить
127

Разрабы в тот момент, когда столкнулись с багом

Ответить
0

Можно ориг?

Ответить

Конституционный динозавр

Павел
29

Вот и выросло поколение!

Ответить
2

( ͡° ͜ʖ ͡°)

Ответить
11

вр версия хл2? я слышал о пользовательских модах - но что валв само сделало вр версию ....

Ответить
53

Экспериментировали на второй части перед тем как к Alyx приступили.

Ответить
68

Видать после этой двери все и заглохло :D

Ответить
6

Так и не понял при чем здесь компилятор.

Ответить
39

По-разному физику считал, соответственно в одном случае дверь была тяжелой и могла оттолкнуть, а в другом случае нет и не открывалась до конца

Ответить
9

Компилятор физику не считает. Разрабы использовали SSE инструкции, что как-то сломало игру. Я не пойму, при чём тут компилятор.

Ответить
36

Не перевели полностью. Компилятор по-другому посчитал числа, и из-за этого изменилась физика

But x87 code uses a very subtly different precision to SSE code. I don't know if we ever tracked down the exact place the code differed - I don't think it was as obvious as 80-bit vs 64-bit. But anyway - why the hell would it even matter? The rest of the game worked fine! /10
Ответить
17

Ну вот теперь понятно. Точность чисел в новом стандарте другая была

Ответить
9

Просто новые компиляторы сейчас везде используют SSE инструкции, а старые использовали инструкции математического сопроцессора x87. И в данном случае виновата архитектура самого сопроцессора, который всегда оперировал 80 битными числами с плавающей запятой и это повышало точность расчетов (даже если на вход передавались только 32 и 64 битные вещественные числа, он просто конвертировал их). А вычислительный блок SSE инструкций оперирует 32 и 64 битными вещественными числами (в зависимости от инструкции).
P.S. В некоторых актуальных компиляторах до сих пор могут использоваться x87 инструкции, но только при сборке под i686, а при сборке под x64 уже используются SSE инструкции

Ответить
0

так а в чём вина х87, если это SSE - несовместимая китайская поделка?

Ответить
4

Не понял прикола с "китайской поделкой", потому что SSE/MMX тоже поделки Intel. У x87 было несколько проблем:
1) Низкая скорость вычисления из-за 80 битного формата
2) Несоответствие стандарту IEEE-754 (из-за того же 80 битного формата)
3) Стековая архитектура. Это усложняло добавление векторных операций в будущем, при этом целочисленный вычислительный блок был с более удобной регистровой архитектурой
4) Лютый оверинженеринг в виде тригонометрических и других операций. В сравнении с самописными алгоритмами преимущество в скорости было минимальное и память экономили считанные десятки байт на всю программу. А если точность тебе была не принципиальна, то самописные алгоритмы были заметно быстрее

Исходя из этого можно именно x87 называть "китайской поделкой", а не SSE

Ответить
0

тем не менее. Есть кривой, но стандарт.
И перекомпиляция без предупреждения - это немного хамство. Примерно как прийти на кухню и поменять продукты.

Ну или режим "принудительной совместимости", когда 87 инструкции эмулируются на SSE и пофигу на удорожание.

Ответить
3

Сэмулировать x87 на SSE будет проблемно, да и не надо (x87 никто не выпиливал из железа, а переключиться обратно можно одним флагом компилятора). И предупреждение было, потому что компиляторы - это не такая из вещей, где в описаниях обновлений можно упускать что-либо, так что оно гарантированно было (как и настойчивая рекомендация разработчиков различных ОС не использовать x87 инструкции в 64 битных программах, появившиеся ещё до выхода первых таковых ОС, т.е. им уже 15+ лет). Так что это проблема разработчиков игры, а не компиляторов

Ответить
1

Таки компиляторов, потому что на разрабах и так адская когнитивная нагрузка.

Проверить список файлов и по дате создания заметит, что какой-то файл создан достаточно давно, либо отсутствуют маркера более новых стандартов - прочекать код и накидать issues, где могут быть баги и нужно уделить внимание при тестировании... я такое у себя во многих скриптах делаю для тестирования - так что авторы компиляторов вполне могли бы уделить минутку для удобства разработчиков.

Иначе получается любопытная ситуация:
- Ты обязан следить за всеми патчноутами всего ПО
- Ты обязан адаптироваться ко всем проблемам всех участников процесса
- А тебе никто ничего не обязан. Жри что дают: пропустил сноску мелким шрифтом в новом тексте стандарта (нужно сравнивать постранично минимум 2 стандарта рядом) - виноват не автор компилятора, который "предупредил в списке обновлений", а программмист, над которым, между прочим, менеджмент, которому релизы давай.

Ответить
5

Если программист решил обносить компилятор на новую версию (и особенно мажорную, как в посте) и не прочитал чейнжлоги, то он сам себе злобный буратино. А в рамках минорных версий abi меняется только в очень крайних случаях. 

Ответить
2

Но это означает знание архитектуры процессора и микропроцессорных комманд, т.е. выходит за рамки компетенции обычного программиста и требует глубокого понимания всего стека технологий?

А при кросс-платформе - и вовсе нужно учить особенности разных платформ.

В итоге возникает один простой вопрос: а нахрена тогда вообще нужны языки высокого уровня, если программисту нужно ещё и за ассемблер переживать?

Если программист решил обносить компилятор

Техлид сказал, джуня приступил к работе.

Ответить
0

И ещё, насчет стандарта: разные процессоры для одного и того же набора операций с плавающими числами одинаковой точности могут выдавать слегка разные результаты и разработчики тоже должны это учитывать

Ответить
0

ну, тут борьба простая: округлять до 5-6 знака, чтобы эксплуатационная точность была чуть ниже точности процессора.

Ответить
3

Компилятор Апанасика тогда не придумали и всё было плохо.

Ответить
1

Ну это я увидел в статье, но при чем здесь компилятор я не понял.

Ответить
10

При любых вычислениях на компьютере присутствует очень маленькая погрешность
Другие стандарты вычислений - другие способы вычислений и другая конечная погрешность.
На старой версии компилятора физика с одной погрешностью давала один результат. На другой версии компилятора другая погрешность, другой результат физики.
Да, это крайне маловероятно, ну так и подобную ситуацию мы все тут видим в первый раз

Ответить
1

Да, это крайне маловероятно, ну так и подобную ситуацию мы все тут видим в первый раз

Куча случаев вообще то 
Так же это причина почему многие организации в мире сидят на железе 80х и даже не пытаются с него слезть

Ответить
8

Комментарий удален по просьбе пользователя

Ответить
1

Там уже ниже написали из-за чего ошибка была.

Ответить
1

Считать физику в компайл тайме эт мощно конечно 

Ответить
12

А мне сравнение дверей из разных частей попалось недавно, тоже есть о чем подумать.

Real-Life vs. HLA vs. HL2

Ответить

Осенний химик

Oleg
9

Лол, почему то никогда не замечал этого)
Но риал лайф дверь на скрине явно маловата)

Ответить
3

Человек лучше замечает вещи, которые больше чем он. А те что похожи - игнорирует, если их много. Но конкретно в сеттинге ХЛ люди стали уменьшаться от недоедания...

Ответить
2

Центральная больше всего похожа на реальность. Левая совсем крошечная какая-то, сейчас даже и не вспомню где такие видел ирл. В таком проеме типичная бабка-срака застрянет.

Ответить
6

Из этого вывод - не делайте критически важные моменты в скриптах зависимыми от физики. Но это, кажется, и ребенку должно было быть понятно. Странно, что в Вальв это не понимали (Работает? Ну и ладно).

Ответить
25

Ну видимо тогда идеей вентилей было все сделать по физону. В 21 году может и очевидно, что наверно это не лучший подход, но вторая халява была когда?

Ответить
4

Ну в современной более-менее комплексной игре очень много аспектов зависят от физики. Банально перемещение персонажей чаще всего ее как-то использует. Что же теперь полностью отказываться от физики?

Ответить
0

Ну, во-первых желательно отказаться (тем более, если есть мультиплеер), во-вторых я написал КРИТИЧЕСКИ ВАЖНЫЕ моменты. Например, как в данному случае, что если дверь не открывается из-за застрявшей из-за физики двери, ты застреваешь на уровне.

Ответить
9

Ну перемещение персонажа это таки критически важный момент. Например, изменился коэффициент скольжения и персонаж теперь не может забраться по склону. Утрированный и упрощенный пример, для иллюстрации, но тем не менее. Отказываться полностью от физики не вариант - она делает мир значительно более иммерсивным и реальным. Пилить на каждую систему дублирующую без использования физики это, во-первых, дорого, а во-вторых, баг в такой "двойной" системе возникнет с гораздо большей вероятностью из-за ее сложности.
Именно поэтому физику используют в том числе и в скриптовых сценах, а во-вторых игры (и физику в них) тестируют на работу в финальной конфигурации и она должна работать в релизной конфигурации.

Ответить
0

Ну перемещение персонажа это таки критически важный момент

Поэтому его желательно делать без физики. Кстати в Unity Character Controller, который рекомендуется использовать для движения персонажа как раз и написан без использования физики.

Ответить
0

"Без физики" у него если и реализовано только передвижение по земле. У него есть коллайдер и он использует физику для определения столкновений, для определения стоит ли он на земле. Ну и прыжки например также там необходимо реализовывать через физику (или извращаться с самостоятельной реализацией подобия свободного ускорения при падении, а для определения конечной точки все равно использовать физику).
Character Controller это наипростейший контроллер, который для нормальной игры все равно нужно будет плотно допиливать, в том числе используя физику.

Ответить
0

У него коллайдер только для просчета столкновений на него не действуют физические силы. Его перемещение полностью контролируется со скрипта. Так что такие объекты вполне предсказуемы для скриптовой логики.

Ответить
0

Но просчет столкновений это физика. Там тоже что-то может пойти не так при изменении вводных данных в готовом продукте. Достаточно обновить версию юнити и уже что-то может пойти не так. Кроме того там не реализованы, как я уже сказал, прыжки. И чтобы их добавить к этому контроллеру нужно будет у него либо включать гравитацию и применять физические силы, либо писать свою систему с блекджеком и костылями для симуляции свободного падения (то есть дублировать функции физики), только чтобы не использовать "бгмерзкую" физику. И так во всех взаимодействиях, которые сложнее контроллера 30 летнего дума: если мы хотим плавать, прыгать, скользить на поверхностях, карабкаться по лестницам, толкать других персонажей и предметы и прочее прочее... нам нужно либо использовать готовую реализацию физики, либо пилить свою систему, которая (спойлер) будет по факту самописной системой обработки физических взаимодействий. Только дорогой, неэффективной и скорей всего с багами.

Ответить
0

Но просчет столкновений это физика

Но это не та физика из-за которой что-то может пойти не так.
Вы вполне даже можете просчитать столкновения отдельно от физического движка (если вдруг такая необходимость возникнет). Это просто пересечение отдельных фигур между собой. Поскольку коллайдеры все выпуклые, там все простые формулы.
Кроме того там не реализованы, как я уже сказал, прыжки.

Там все есть в этом контроллере и прыжки, и скольжение, и подъем по ступенькам. Все базовые перемещения реализованы.

Ответить
0

Специально посмотрел в документацию юнити. Там реализованы ступеньки и максимальный угол подъема. Никакого скольжения там близко нет. Не говоря уже о том что у нас могут быть разные поверхности с разным возможным углом подъема, которые в физическом движке легко определяются через коэфицент трения физического материала.
Прыжки там "реализованы" так как я и сказал - через самописную "симуляцию" физического явление гравитации. То есть вручную каждый кадр обновлять позицию персонажа вниз на gravityValue * Time.deltaTime.
То есть для прыжков мы "пилим свою систему, которая (спойлер) будет по факту самописной системой обработки физических взаимодействий".
И это мы говорим о такой простой вещи как прыжки.

Ответить
0

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

Прыжки там "реализованы" так как я и сказал - через самописную "симуляцию" физического явление гравитации.

"Симуляция" прыжка аж в пару строчек кода :) Кстати, не слишком уж сильно отличается от AddForce.

И кстати, насколько легко и удобно через RigidBody узнавать, что ваш персонаж стоит на земле?

Ответить
0

"Симуляция" прыжка аж в пару строчек кода :)

Ну пока мы не начали добавлять отскоки от поверхностей как на батуте например. Я не спорю что можно все это реализовать, но зачем если есть решение "из коробки"?

И кстати, насколько легко и удобно через RigidBody узнавать, что ваш персонаж стоит на земле?

Никак, собственно как и в CharacterController нужно использовать физику. Я предпочитаю SphereCast вниз.

Ответить
0

Ну пока мы не начали добавлять отскоки от поверхностей как на батуте например. Я не спорю что можно все это реализовать, но зачем если есть решение "из коробки"?

Нет, ну конечно, если вашей игре нужны такие вещи для персонажа, как отскоки, скольжение на различных поверхностях, то без физики обойтись здесь будет ОЧЕНЬ сложно.
Но обычные бродилки, выживачи, те же шутеры, спокойно могут обойтись без физики для перемещения.

Ответить
0

Но это не та физика из-за которой что-то может пойти не так.

Легко можно сломать. Например открывать дверь по скрипту, у которой есть коллайдер, Встать рядом и персонажа вытолкнет в out of bounds. Можно посмотреть на многих спидранах.
Ах, можно же отключать коллайдер на двери во время скрипта открытия. Ну да, костылей нам мало.

Ответить
0

Его выстреливает из-за физики, а не из-за коллайдера. Мое предположение, что физика неверно рассчитывает силу удара.
Коллайдера просто рассчитывает пересечение фигур.

Ответить
1

Если ты такой умный, то почему такой бедный?

Ответить
0

А какое отношение перемещение персонажей имеет к скриптовым сценкам?

Ответить
0

Потому что в скриптовых сценках обычно нужно перемещать персонажей. И либо это делается через стандартные механики перемещения персонажей (которые обычно используют физику), либо для их перемещения пилится отдельная система специально для скриптовых сценок. В первом случае мы подвержены каким-либо выкрутасам физики, во втором нам нужно пилить отдельную систему, поддерживать ее, тестировать, контролировать что персонажи корректно переключаются между системами и прочее. Первый способ значительно более простой и дешевый.

Ответить
0

Так тебе в любом случае придётся пилить отдельную систему для скриптовых сценок. Если персонаж будет делать нестандартные анимации, например перелезание через забор, то стандартная физическая система просто сойдёт с ума и запульнет его в стратосферу.
Во-первых, а во вторых эээ... проигрывать анимацию и перемещать персонажа в пространстве это намного сложнее и дороже, чем использовать физическую систему расчета его перемещения и взаимодействия с окружающим миром?

Ответить
1

Ну перелезать через забор он и в геймплее может. Любые нестандартные взаимодействия конечно нужно будет как-то реализовывать в контроллере (каким бы он ни был) что для геймплея, что для сценок. Но ключевое здесь, что реализация должна быть одна. Если персонаж перелезает через забор в геймплее по одной системе, а в скриптах по другой, то это плохо и совершенно зря.
Оригинальный комментарий говорил, что как же они двери отрывают в скриптах по физике, то есть предполагается что в геймплее они должны открываться по физике, а в катсценах через другую систему (например анимацию). Я говорю о том что дублировать системы избыточно и подвержено багам в еще большей степени.
Перемещение персонажа чисто по анимации игнорируя физику в катсцене это конечно можно реализовать, но зачем? Нужно удостовериться что персонаж корректно переходит от физического контроллера в анимационный контроллер и обратно. А если игрок в это время загрузится или сохранится? А если еще 1000 но? А если мы поменяем немного сценку и персонаж будет идти не по плоскому полу а по склону? Менять полностью анимацию и перестраивать катсцену?
Дублирование систем это путь к двойной работе при разработке и при тестировании.

Ответить
1

Где в ХЛ2? Нет не может. Там перелезть через забор можно только запрыгнув на него целиком, т.е. ногами, а не как бы в реальной жизни люди бы перелезали через забор.
Использование одной системы имеет смысл если рассматривать проблему поверхностно. Но на практике, если у тебя есть выбор между тем чтобы построить одну сложную систему или две простых, то разумный человек выберет второе. Хотя бы тупо потому, что тогда вторую систему можно будет отдать в соседний отдел, который как раз и занимается этими сценками. И работать и отлавливать баги в двух простых системах будет намного проще.
В нашем конкретном случае вторую систему, которая просто проигрывает анимации, тяжело назвать системой на самом деле. Проигрышь анимаций и перемещение в пространстве это и так базовая функция всех объектов в трехмерных играх. Так что тут просто стоит выбор между тем чтобы делать сложную физическую систему и делать менее сложную физическую систему.
Касательно перечисленных проблем перехода между состояний, сохранений и прочего. Во-первых они уже лет двадцать как решены. Во-вторых, решение этих проблем это как раз более "правильный", более высокоуровневый подход, нежели чем локальное решение гнать всё через одну систему.
А если мы поменяем немного сценку и персонаж будет идти не по плоскому полу а по склону?

А что если что-то изменится в физическом движке и придётся переделывать абсолютно все сценки?

Ответить
0

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

Ответить
0

В мире программирования можно совершить бесконечно большое число "даже ребёнку очевидных" ошибок. Не зря до сих появляются вполне современные порты с консолей, в которых начинают ломаться скрипты при подъёме FPS выше 30 или 60.

Ответить
9

На самом деле очень познавательная и интересная статья, спасибо. Half-Life 2 — игра на века.

Ответить
0

Теперь понятно, почему в «Готиках» нет дверей! (на самом деле нет)

Ответить
16

Здравствуйте, мы тут из r6 siege. Хотим сказать, что мы, в нашей секте, ненавидим двери. Поэтому у нас сплошные арки)

Ответить
4

Настолько ненавидим двери, что наши двери нельзя открывать — только взрывать, пробивать и простреливать. И оконные проемы мы тоже дверным полотном закрываем!

Ответить
4

Штааааа? В первой и во второй двери есть.

Ответить
0

Пираньи до сих пор не могут до конца решить проблемы навигации НПЦ в дверях. Поэтому в Risen и Elex количество дверей тоже врятли превышает пяти экземпляров на всю игру.

Ответить
0

Сразу вспоминается статья про двери в TLOU II, где сказано, что разрабы ААА ненавидят двери.

Ответить
12

На которую прямо дана ссылка в тексте 

Ответить
4

Напомнило, как я однажды застрял в комнате кровавого барона в ведьмаке. Дверь из нее открылась... но наполовину. И оказалась в суперпозиции: одновременно открыта и закрыта. Как итог: она не открывалась, потому что открыта, и не закрывалась, потому что закрыта х)

Ответить
1

по-хорошему должен быть оверрайд в виде отскока по физике при ударе.
Как в Duke Nukem - одной ногой, если не помогает - то двумя.

Ответить
1

Getting very close to ready to ship, and I thought I'd do a full playthrough, rather than just cheating our way to specific levels to test them.

1) У них нет QA?
2) В итоге игру не ship? Баг пофиксили, почему отказались?

Ответить
10

"У них нет QA?"
Это вальв - откуда такие глупые вопросы - все в студии заняты тем чем сами хотят : фиксированных должностей там вообще нет 

Ответить
1

А Луна сделана из сыра. Все там есть, только вместо четких правил - нечёткие "понятия". Даже не знаю что хуже. Что, впрочем, не мешает им размещать на сайте список конкретных вакансий, вместо плашки "приходите и занимайтесь чем хотите".

Ответить

Престижный Мика

2

Так а проблему как решили? Отодвинули охранника?

Ответить
5

Невыпуском игры, судя по всему) 

Ответить

Любимый пёс_анон

splinefx
0

хнык, хочу нормальный хл2 вр... ну точнее вр порт аля дум3.

Ответить
3

Баг кстати ещё есть. Эта дверь (как и некоторые другие) в текущем билде не откроется, если в упор подойти и держать w

Ответить
2

Стоп, про это совсем недавно же уже было. С месяц назад

Ответить
1

Я всегда думал что компилятор собирает все что сделал программист. Как видос рендерится после монтажа. А тут оказывается что эта штука что то себе там придумывает ...

Ответить
3

Добро пожаловать в языки высокой абстракции
Хочешь что бы компилировало ровно так как ты записал - пиши код на ассемблере

Ответить
0

да-да, С++ это "близкий к железу язык".
да-да, "учите стандарты".

именно по этому я от плюсов хочу держаться подальше - слишком много "неожиданных подводных камней".

Ответить
1

Can't make through the door man CAN'T MAKE IT CAN'T MAKE IT

Ответить
1

Свою первую дверь я открыл в 16 лет

Ответить
1

HL2 может фору 100 дверей дать онлайн игре Сфера , там каждые 3 секунды кого-то дверью убивало, в чате спамились об этом сообщения и крики пострадавших, хотя там и других проблем было много.

Ответить
0

Вспоминается рассказик, где объясняли на примере Войны и Мира, как работает код и почему огромные объемы сложно писать

Ответить
–1

Сильно переоцененная игра

Ответить

Интимный теркин30см

0

Разработчик посмотрел начальную сцену, сошёл с поезда, закинул банку в мусорку и так далее. Всё было нормально, пока Барни, который скрывался под маской охранника, не постучал в дверь

Я давно играл, но разве банку кидаешь не после этой встречи с Барни?

Ответить
0

Нет, до. Почти сразу после выхода с поезда, при входе на вокзал

Ответить

Интимный теркин30см

Артемий
1

Я сходил перепроверил. Сначала Барни и потом банка. Соси.

Ответить
1

Ок, ты прав. Сосу

Ответить
0

Блин, у меня вроде баг был похожий, после уровня с муравьями, было какое то здание типа тюрьмы, там одна из решеток открылась и также закрылась, и я не смог дальше пройти.

Ответить
0

Коэльный мог бы пояснить за дверь

Ответить
0

С дверьми постоянно проблемы что в ГД, что в кино. 

Ответить
0

Да же спустя 10 лет... мол игра сама себя эволюцинируе

Ответить
0

Закончилось на самом интересном месте.

Ответить

Комментарий удален

0

Для меня погружение в игру полностью разрушается, когда я вижу как двери открываются в обе стороны "от себя" - как на вход, так и на выход. А такое встречается много где.

Ответить
0

а я помню, что в игре отключался ИИ  и npc не открывал нужную дверь

Ответить
0

Это так называемый перезалив статьи? Про это уже читал где то 3-4 месяца назад 

Ответить
0

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

Ответить
0

Нехер открывать скриптованные двери физикой

Ответить
0

В нашей команде это называется "****** рот этого казино" с характерным эмодзи в слаке 🙂

Ответить
0

Может не совсем такой случай, но помню как в c# писал рабочую программу, которая собирала данные в экселе и обрабатывала их. Все было нормально, задача не особо сложная, вроде сделал - запускаю, вижу две ячейки с чем-то вроде 10.04 и 10.02, суммируются и получается... 20.599999999999 (примерно). Я в ах-е, перечитываю код, перепроверяю чтобы в экселе не понижалась точность, по 10 кругу читаю вообще все в программе. В итоге выяснилось, что дело в том, что я не особо думая записывал данные в переменную double, как привык считать значения с запятой. А для записи естественных значений вроде финансовых расчетов больше подходит decimal. Хотя по сути они вроде примерно одно должны делать.

Ответить
0

Ну это примерно как с HL Source. Вроде впустили апдейт затрагивающий только графический движок, но поскольку они использовали новый компилятор, то вся старая логика в игре сломалась, сломались скрипты, сломались хитбоксы и половина мелких фишечек. А мультиплеер вообще неиграбельный поскольку все сравнится по 2 раза и не работает. Две двери, два стекла, два оружия и т.д.

Ответить
0

DOOR STUCK! OUT OF MY WAY SON
DOOR STUCK

Ответить
0

Эффект бабочки в действии.

Ответить
–1

В ВтМ:б застрять в дверях милое дело, именно потому их старались делать поменьше.

Ответить

Комментарии

null