Анатомия наступания на грабли

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

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

Обычная очепятка

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

if (update_x) pos.x = new_pos.x;
if (update_y) pos.x = new_pos.y; // Дрогнула рука
if (update_z) pos.z = new_pos.z;

Самое коварное здесь — природа нашего собственного мозга, который функционирует по принципу встроенного автокорректора. Вы можете вчитываться в этот фрагмент десяток раз, но глаз попросту «проскользнет» мимо дефекта, поскольку вы подсознательно знаете, что там должно быть написано. В определенный момент мне это надоело, и мы внедрили в проект clang-tidy со спецификаторами bugprone-* и флагом -Wshadow для сборок на clang. Это оградило команду от колоссального пласта ошибок, вызванных затенением имен и человеческим фактором.

class Foo {
    int value;
public:
    Foo(int value) { // параметр затеняет поле class
        value = value; // ничего не делает, присваивает параметр самому себе
    }
};

Логический баг

Код, безусловно, исполняет ровно то, что вы в него заложили… дословно и без раздумий. Однако написать глупость проще простого — например, допустить ошибку на единицу (off-by-one) при обновлении циклического буфера событий или попытке извлечь элемент из контейнера:

memmove(events + i, events + i + 1, (num_events - i) * sizeof(*events));
--num_events;

Подобные изъяны хотя бы поддаются адекватному анализу: если у вас есть стабильный сценарий воспроизведения, они будут проявляться стопроцентно детерминированно. Вы просто запускаете отладчик и пошагово изучаете выполнение. Тем не менее, у программистов есть пагубная склонность порождать логические ошибки самостоятельно, занимаясь преждевременной оптимизацией. Все начинается с благих побуждений: «А давай я напишу специализированный быстрый путь для редкого сценария удаления самого последнего элемента». В результате образуется разветвление if/else, которое активируется раз в неделю при особом выравнивании планет, а потому практически не покрывается тестами. И разумеется, именно этот участок кода триггерится у реального игрока на релизе. Правило простое: чем линейнее ваша кодовая база и чем меньше в ней изолированных веток, тем меньше лазеек для подобных сюрпризов.

Запись за границу массива

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

#define MAX_PARTICLES 1024
Particle particles[MAX_PARTICLES];
uint32_t num_particles;
void spawn_particle(Particle p) {
particles[num_particles++] = p;
}

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

Утечки ресурсов

Сродни предыдущей проблеме: сколько времени ни прошло, а воз и ныне там. Внутри игрового движка утекать может абсолютно все: текстуры, полигональные сетки, файловые дескрипторы, захваченные мьютексы. Так, в ранних ревизиях Nintendo Switch рекурсивный мьютекс отказывался высвобождаться, если входил сам в себя более пяти раз, при этом их лимит на процесс составлял всего 1024 штуки.

Использование «сырых» malloc и free превращает охоту за утечками в рутинную повинность. Вычислить, какой именно из пяти сотен вызовов аллокации остался без парного free — задача со множеством неизвестных. И если вы рассчитываете, что современные сборщики мусора или умные указатели способны полностью закрыть этот вопрос, то глубоко заблуждаетесь. Они лишь трансформируют саму суть проблемы: вместо физической утечки памяти мы получаем утечку ссылок, когда забытый менеджер сцены продолжает удерживать невидимый объект, который по цепочке тянет за собой весь аудио- и визуальный контент.

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

Повреждение памяти

Если бы существовал своеобразный пьедестал почета для багов, повреждение памяти уверенно занимало бы на нем высшую ступень: use-after-free, выход за границы буферов, обращение по «диким» указателям, порча метаданных блоков аллокатора, повторное удаление уже очищенных областей — список можно продолжать долго.

Главный ужас подобных дефектов заключается в том, что первопричина и следствие разделены огромной пропастью во времени и пространстве. Функция A в каком-нибудь удаленном физическом модуле слегка задела край смежного массива, но физика продолжает работать дальше. Ошибка всплывает совершенно неожиданно при рендеринге UI во время попытки отобразить ник игрока, и хорошо, если дело ограничится артефактами шрифта, а не мгновенным Access Violation. В итоге вы сидите над дампом интерфейса и отчаянно пытаетесь понять, при чем здесь вообще графическая оболочка.

Единственное, что способно уберечь рассудок в таких ситуациях — это AddressSanitizer (ASan) и защитные охранные зоны («канарейки»). ASan окружает каждую аллокацию невидимыми барьерами и немедленно останавливает выполнение при первой же невалидной записи, не давая разрушить соседние структуры. А заполнение освобожденных участков памяти характерными паттернами вроде 0xDEADBEEF позволяет отладчику сразу подсказать, что вы пытаетесь прочитать «цифровой труп» объекта.

Состояние гонки

Архитектура современных игровых движков построена на максимальном параллелизме. Физические расчеты идут на одном ядре, подготовка кадров — на другом, стриминг данных и искусственный интеллект — на третьем. Но когда два независимых потока пытаются одновременно оперировать единым массивом данных без должной синхронизации, на сцену выходит классический Race Condition.

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

#### Пятничный фикс

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

// Пятница, 17:55. Фиксим редкий мигающий иконку здоровья
void UIHealthBar::Update(float DeltaTime)
{
// "Заодно почистим каст, а то валидатор ругался..."
PlayerCharacter* Player = Cast(GetOwningPawn());

// Раньше тут была проверка if (Player), но разработчик уверен, 
// что UI HealthBar существует ТОЛЬКО когда игрок жив и валиден.
HealthPercent = Player->GetHealth() / Player->GetMaxHealth();
}
Код успешно компилируется, улетает в репозиторий и передается тестировщикам. Однако в субботу выясняется, что в момент гибели протагониста, его респавна или загрузки локации через меню интерфейс успевает отрисоваться на один кадр раньше, чем создается сущность персонажа. В результате указатель Player оказывается нулевым. Подобные пятничные артефакты преспокойно живут годами, проходя любые код-ревью и тесты в ожидании своего звездного часа.

Гейзенбаги
Сам термин заимствован из квантовой механики и принципа неопределенности: сам акт наблюдения за системой трансформирует ее изначальное состояние. В экосистеме C++ это дефекты, которые существуют исключительно тогда, когда за ними никто не наблюдает. От отдела контроля качества приходит тикет о падении движка при попытке войти в определенную пещеру. Вы запускаете проект в отладчике, доходите до этого места… и ничего не происходит. Все функционирует штатно. Вы повторяете операцию десяток раз, закрываете отладчик, собираете релизный билд — и мгновенно получаете падение. Чаще всего корни этого кроются в неинициализированной памяти и агрессивных оптимизациях компилятора:
struct AttackParams
{
float Damage;
bool IsCritical; // Забыли инициализировать в конструкторе
};

void ApplyDamage()
{
AttackParams Params;
Params.Damage = 100.0f;
// Params.IsCritical содержит случайный мусор из стека
if (Params.IsCritical) {
    // В Debug-сборке здесь всегда false из-за зануления стека.
    // В Release-сборке здесь может оказаться true, и крит сработает неожиданно.
}
}
Сюда же относятся тонкости многопоточных таймингов и логов. Попытка зафиксировать состояние гонки с помощью диагностического вывода приводит к искусственному замедлению потоков, что смещает момент коллизии, заставляя баг временно исчезнуть. Стоит убрать лог — и проблема возвращается. Именно поэтому в кодовой базе иногда можно встретить суровые комментарии вроде «этот вывод в лог не удалять ни в коем случае»:
void MeshLoader::OnAsyncLoadComplete(Mesh* LoadedMesh)
{
log("Mesh loaded: %s\n", LoadedMesh->GetName()); // Этот лог не удалять!!!
RenderQueue::Enqueue(LoadedMesh);
}
Подключение отладчика или активация специальных диагностических флагов меняет размер структур данных и заголовков (например, за счет добавления отладочных итераторов в std::vector или служебных полей в аллокатор). В результате адреса в памяти сдвигаются, и повреждение, которое раньше разрушало критически важные данные, начинает перезаписывать безобидные защитные байты (guard bytes), успешно маскируя сбой.
Фичебаг («Это не баг, это фича»)
Бывают ситуации, когда сбой в математических расчетах или игровой логике порождает настолько увлекательный геймплейный опыт, что разработчики принимают волевое решение ничего не исправлять, а просто узаконить ошибку под видом новой механики.
Вспомните Street Fighter II: возможность отменять анимацию одного удара другим родилась из-за банального недочета в просчете таймингов. Продюсер Норитаки Фунамидзу, заметив эту особенность, счел тайминги слишком сложными для отлова и оставил все как есть, положив начало целому направлению современных файтингов.
Легендарная агрессия Ганди в Civilization. Согласно байке, из-за переполнения беззнакового 8-битного целого числа показатель миролюбия индийского лидера при переходе к демократии уходил ниже нуля и сбрасывался до максимального значения 255, превращая дипломата в безумного ядерного психопата. История оказалась выдумкой, однако миф приобрел такую популярность, что разработчики пятой части игры официально перенесли этот баг в реальную игровую логику.
Или распрыжка (Bunny Hopping) в Quake. Ошибка в формуле сложения векторов скорости при одновременном прыжке и повороте камеры позволяла игрокам развивать космическую скорость, открывая простор для акробатики на уровнях. Если баг делает игру веселее, его не исправляют — его полируют и презентуют маркетологам. На этой концепции построена целая серия игр Saints Row, где тестировщики даже получали премии за обнаружение эксплойтов, которые впоследствии превращались в элементы игровой механики.

Эффект Бабочки (Погрешность чисел с плавающей запятой)
Ошибки, обусловленные ограниченной точностью формата float при удалении игрока на большие расстояния от центра координат. Чем дальше перемещается персонаж, тем меньше разрядов остается на дробную часть. На удалении порядка ста километров точность позиционирования падает до нескольких миллиметров, из-за чего модели начинают непрерывно вибрировать и эпилептически дергаться, пока игровой мир окончательно не вытолкнет их за свои пределы.
Подобные эффекты вызывают масштабные артефакты процедурной генерации — вспомните знаменитые Далекие Земли (Far Lands) в Minecraft, где на расстоянии в 12.5 миллионов блоков от точки старта погрешность вычислений шума Перлина достигала таких масштабов, что ландшафт превращался в гигантские перфорированные монолиты.
#### Спагетти-зависимости
Забавные аномалии, при которых приложение падает исключительно в том случае, если игрок открывает дверь, удерживая определенный предмет под строго определенным углом в 45 градусов. В Team Fortress 2 существует устойчивая городская легенда о текстуре кокоса, без которой движок Valve Source категорически отказывается запускаться. В ресурсах действительно присутствует файл coconut.vtf с реалистичным изображением кокосового ореха, появившийся с обновлением Love & War 2014 года и оставшийся там в качестве неиспользуемого актива. Миф о том, что удаление этого файла приводит к краху игры, разросся стараниями шутливого комментария под оригинальным постом в духе «понятия не имею, зачем он тут, но стоило мне его стереть, как все перестало работать», который многие приняли за официальное слово разработчика.
Сюда же можно отнести инцидент из Lineage 2, когда пользователи не могли попасть на конкретную локацию из-за того, что в их инвентаре лежал квестовый предмет из 2009 года, чей внутренний идентификатор случайно совпал с новым типом анимации дракона.
Инверсия приоритетов
Характерный недуг многопоточных систем, при котором игра начинает страдать от микролагов из-за активности фоновых процессов с низким приоритетом. Поток с низким приоритетом (например, фоновый стриминг аудио) захватывает мьютекс, после чего высокоприоритетная задача пытается получить доступ к тому же ресурсу и блокируется, уступая процессорное время. Однако в этот момент промежуточный поток (скажем, просчет логики ИИ) полностью утилизирует процессор, не позволяя низкоприоритетной задаче завершить работу и освободить мьютекс. В итоге главный поток ожидает аудио, аудио ждет искусственный интеллект, а пользователь наблюдает за тем, как кадровая частота стремится к нулю.
#### Баги плавающего шага времени (Variable Delta Time)
Своеобразная плата за стремление к разблокированной частоте кадров, когда физическая симуляция или перемещение напрямую зависят от величины dt (времени, прошедшего с момента отрисовки предыдущего кадра).
// Если кадр просел с 60 FPS (16мс) до 2 FPS (500мс) из-за загрузки
position += velocity * dt; // dt стал гигантским
В результате за один затянувшийся кадр (например, во время внезапного лага) персонаж успевает насквозь пролететь трехметровую стену, поскольку физический коллайдер просто перешагивает преграду за один прыжок.
Что я упустил?
В конечном счете, качественный код игровой системы отличается от посредственного вовсе не отсутствием багов — ошибки совершают абсолютно все. Разница заключается в том, насколько легко этот код поддается отладке, насколько изолированы его модули и насколько прозрачно организована работа с памятью. Лгут все, и даже исходный код — особенно код. Никогда не верьте ему на слово.




 

Источник