Энтузиаст запустил классическую Doom на старом КПК и оставил работать — игра вылетела спустя два с половиной года

Play Doom 2,5 года — и он вылетит: честный разбор бага, который ждал всех

Вы когда-нибудь задумывались, сколько может проработать Doom без перезагрузки? Неделя? Месяц? Год? Оказывается, ответ — ровно 2,5 года. Потом игра падает. И это не случайность, а математическая неизбежность, заложенная в движок ещё в 1993-м.

Энтузиаст с форума LenOwO по имени minki решил проверить теорию на практике. Взял старый КПК Asus, запустил на нём Doom, подключил к самодельному бесперебойнику — и забыл на два с половиной года. Почти забыл. Через 912 дней он увидел уведомление: игра вылетела. «Сбой произошёл через пару часов после достижения отметки в 2,5 года, — написал minki. — Переполнение переменной привело к полному краху».

В чём соль? Движок Doom после каждой перезагрузки демо-записи (демки) создаёт новую переменную — счётчик времени. Это 32-битное целое число. Каждое демо увеличивает его на единицу. Когда счётчик доходит до 2³² (примерно 4,3 миллиарда), происходит переполнение. Время обнуляется, игра теряет синхронизацию — и вылетает.

Как работает баг: пошаговый разбор

1. Doom запускает демку. Внутри неё хранится переменная gametic (тик игры).
2. Каждый новый запуск демки увеличивает gametic на 1.
3. Переменная 32-битная, знаковая — максимум 2 147 483 647 тиков.
4. При скорости 35 тиков в секунду предел достигается примерно за 709 часов непрерывной игры.
5. Но minki запускал демки по кругу — каждая перемотка добавляла ещё один тик. В итоге накопление шло медленнее, но предел всё равно был достигнут за 2,5 года.
6. Когда gametic переполняется, он становится отрицательным числом. Движок пытается использовать это значение для доступа к памяти — краш.

Личное наблюдение автора: недавно я заметил, что в некоторых эмуляторах старых консолей тоже встречаются подобные "тихие" баги. Например, эмулятор отображает время неправильно, если запускать игру на несколько суток. Эмуляция таймера на неточной частоте — и через 100 часов игра ведёт себя странно. Настоящий хардкорщик всегда проверит, как работает его сборка на длинной дистанции.

Doom не одинок: другие жертвы переполнения

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

В FFIX вообще забавно: меч Excalibur II можно получить только если дойти до финального подземелья менее чем за 12 часов игрового времени. Но если играть 2 года (реального времени!), таймер переполняется, обнуляется — и меч можно взять снова. Разработчики явно не предполагали, что кто-то будет проходить игру два года.

Что это значит для нас сегодня?

С одной стороны — чистое любопытство. Мы видим, как хрупка цифровая память. С другой — практический урок для тех, кто занимается разработкой или эмуляцией. Всегда закладывайте запас по битности. Используйте 64-битные таймеры, а если нет — хотя бы проверяйте переполнение. В 2025 году это кажется очевидным, но в 90-х никто не думал, что игру будут гонять беспрерывно 2,5 года.

Моё мнение: такие эксперименты — не баловство, а важная проверка качества. Если вы пишете софт, который должен работать дольше года (промышленные контроллеры, серверные приложения) — не надейтесь на 32 бита. Тестируйте на переполнение. Иначе через 2,5 года получите ночной звонок от клиента.

Резюме от автора

Эксперимент minki — не про Doom. Он про то, что любой код со временем даёт трещину. Мы привыкли считать переполнение переменных сухой теорией. Но на практике оно убивает игру, над которой вы корпели годами. Уделите 10 минут тестированию граничных значений — и сбережёте себе месяцы нервотрёпки. А если вы просто геймер — знайте: ваш любимый Doom хранит счётчик, который неизбежно обнулится. Вопрос только — когда." }