Главные черты аудио в играх — адаптивность и интерактивность. Аудио может работать в нескольких пластах одновременно: давать игроку обратную связь и информацию, воздействовать на эмоции и помогать восприятию игрового пространства и времени. Часто все эти задачи сводятся к одной цели — созданию комплексных впечатлений и переживаний.
Звукорежиссёры, геймдизайнеры и программисты придумывают системы, в которых взаимодействие через аудио могло бы наиболее корректно дополнить идею игры, раскрыть художественный образ и геймплей.
В этой заметке я хочу затронуть типичные структурные ошибки в работе с такими системами. Тем, кто уже давно наступил на свои грабли и получил иммунитет, материал может показаться набором банальностей. Тем же, кто только начинает пробовать свои силы в игровом аудио, мой текст покажет эти грабли. Наступать на них или нет — личное дело каждого. Однако, возможность сэкономить время, нервы и (возможно) деньги — в паре следующих абзацев.
Грабли музыкальные
Отличная идея пришла мне при работе над Security Hole в 2015 году. Это был первый проект, в котором я взяла все задачи по аудио — и музыку, и звук, и логику этого всего. Было огромное желание сделать что-то нетривиальное.
Слева внизу — индикатор расхода времени 
Слева внизу — индикатор расхода вращений
Большинство уровней в этой игре имеет ограничения: лимит времени или лимит вращения фигуры. Почему бы не обыграть расход игрового ресурса изменениями в музыке? Придумала — сделала! С разработчиком договорилась, схему внедрили.
Систему выбрала простую — варианты трека сменяют друг друга:
лёгкий вариант темы (A) и вариант темы, изменённый добавлением пульса струнных и соло медных духовых (B).
Вариант микширования прост — горизонтальная стыковка через crossfade на общей временной отметке. Второй вариант темы должен был подчеркнуть, что время или движения на исходе, и появлялся через crossfade при пересечении определённого значения.
Это нормальный вариант, он обострил напряжение игрового процесса, но этого явно было недостаточно. Примерив быстрый crossfade на всей системе, мы решили взять схему плавного изменения. Два варианта запущены параллельно, и в то время как громкость варианта A движется от 100 к 0 %, громкость варианта B движется от 0 к 100 % — в привязке к любому лимитированному ресурсу. Так мы получили линейную взаимосвязь количества времени/лимита вращений и напряжённости музыки.
Плавное нарастание напряжения музыки отлично усилило обратную связь игры. Но что делать с файлами? Я понимала, что этот вариант рендера уже не обоснован структурой, и рано или поздно придётся его менять. Однако, я не могла и представить, что проблема синхронизации файлов может звучать настолько плохо.
Дефект не пришлось долго ловить — он проявился на первом же тесте. Запуск слоёв может быть рассинхронизирован на несколько миллисекунд, а на медленных устройствах — и на 20-30. При наличии одинаковых составляющих в спектре файлов смещение создаст неприятный эффект фейзинга, а при большем расстоянии — эффект задержки, похожий на chorus.
Структура варианта B содержит в себе весь материал варианта А. Используются А и B уже не как варианты, а как слои.
Для большей наглядности два примера: без расхождения (0 мс) и с расхождением в 1 мс. Во втором варианте дефект наиболее отчётливо слышен на перкуссии.
В этой тестовой примерке явления фейзинга и противофазы впервые обрели для меня конкретный прикладной к геймдеву смысл, и стало ясно, что рассинхронизация — явление не гипотетическое, а реальное и повседневное.
На то, что запуск произойдёт без сдвигов, надеяться не приходится, поэтому оставить всё “как есть” было нельзя. Тем более, микширование слоёв привязано к ресурсам времени и вращения, которые можно пополнять бустерами, а значит игрок будет слышать криво замикшированные дорожки сколь угодно долго.
Исправила просто — разделила трек на два слоя вместо двух вариантов. Теперь слой B полностью отличается от слоя A, они не содержат общих элементов и дорожек.
Слой A не меняет свою громкость, слой B с другим наполнением постепенно нарастает.
Теперь небольшие смещения в микшировании не страшны. Вся система работает без дефектов и отлично поддерживает геймплей. По такой же схеме были написаны и другие треки для этой игры.
Выводы сделаны, опыт получен.
Грабли глобальные
Казалось бы, пример с музыкой довольно наивный. Осознать ошибку на своём материале очень просто, особенно когда ты не первый день работаешь со звуком.
Однако наложение идентичных сигналов — популярная проблема аудио в играх. Это происходит по разным причинам, и чаще это не вопрос намеренного пренебрежения, а вопрос отсутствия проблемы в зоне внимания: ассеты переданы программисту, отдельно звучат отлично — что может пойти не так?
Без понимания ситуаций, в которых возникает дефект, можно принять ряд неверных структурных решений, которые в движке будут звучать хорошо, а на устройствах плохо. Такую разницу легко списать на капризы движка и забыть, сделав неверные выводы.
Но давайте всё же разберёмся с корнем проблемы. Где она может возникнуть? В озвучивании одинаковых событий идентичным звуком в один момент времени. Наиболее частые жертвы этого дефекта — игры с механикой 3-в-ряд.
Попробуйте представить, что будет, если на одном игровом поле одновременно взорвутся двадцать объектов, и один и тот же звук будет проигран для каждого из двадцати взрывов. Представили? Если не очень, то вот немного простой арифметики и примеров.
1 звук:
Две копии звука при полной синхронизации суммируются в один звук с громкостью на 6 дб выше относительно одной копии:
Три копии — на 9 дб выше:
Четыре копии — на 12 дб выше.
Восемь копий — на 18 дб выше.
Шестнадцать — на 24.
Арифметика такая, что каждое удвоение даёт прирост в 6 децибел. Для игрока эти N звуков звучат не как взрыв большого количества объектов, а как один очень-очень громкий звук. Если у звука резкая атака, это может привести даже к болевым ощущениям.
Теперь смоделируем ситуацию с несинхронным запуском. Каждая следующая копия файла запускается с задержкой в 2 миллисекунды:
Заметили, что со смещением микс звучит тише, чем в предыдущих примерах, где запуск был синхронизирован в 0? При смещении на 2 миллисекунды часть спектра второй копии файла стала в противофазу первой, и на выходе мы слышим то, что осталось в спектре после. На иллюстрациях заметны горизонтальные тёмные полосы — в этих частях спектра была утрачена часть сигнала. А при смещении на 20 мс и более мы услышим эффект, похожий на chorus/delay, и “размазанный” звук (как и само изображение спектра).
Посмотрим на искажения вблизи.
Давайте посчитаем все негативные эффекты такого решения:
- Кратковременное превышение целевого уровня громкости, и его следствия:
- усиленная акцентированность звуков, для которых предусмотрен другой уровень громкости, приводит к искажению общего баланса аудио. Игрок выключит или звук, или саму игру, если второстепенные звуки “торчат” и “бьют по ушам”.
- при некоторых условиях несёт риск травмирования слуха.
- Эффекты смещения фазы сигнала при запуске N копий одного звука:
- эффект фейзинга искажает исходный состав частот в спектре (волны, находящиеся в противофазе, “гасят” друг друга, тем самым устраняя значительную часть сигнала в миксе).
- chorus/delay — параллельное дублирование сигнала на расстоянии, которое уже не создаст фейзинг, зато создаст ощущение очень быстрого отражения звука.
- Неэкономное использование ресурсов. Например, одновременный запуск восьми и более копий файла там, где можно обойтись одной.
Пока ошибка есть — под угрозой адекватность оценки самих ассетов: в кривой системе любые звуки будут звучать криво. Исправление дефекта возможно только через корректировку системы.
Игры, ушедшие в релиз с такими дефектами, встречаются. И версии этого бага с 16+ звуками реально существуют. Звучит это, как минимум, неприятно.
Какие есть решения?
- привязка звука к другой сущности, например к глобальному событию, стоящему над N анимациями/событиями
- калибровка запуска анимаций: например, вместо одновременного запуска трёх анимаций взрыва сделать три последовательных запуска с задержкой около 0,5 с — это и визуально обогатит событие, и позволит звукам работать корректно в привязке к тем же сущностям.
- запрет на запуск более одной копии звука через N мс после предыдущего события.
- использование разных вариаций одного звука, если озвучивание каждого идентичного события обязательно
- настройка системы варьирования звука
- отладка микширования — адаптивная динамика отдельных звуковых событий и каналов микшера, лимитирование на мастер-шине
- авторские методы и костыли
Заключение
Эти знания не являются тайной, а среди звукорежиссёров вообще считаются чем-то настолько обыденным и базовым, что не требует отдельного упоминания в связи с разработкой игр. Надеюсь, мой обзор поможет начинающим звукорежиссёрам и имплементирующим программистам не совершить подобных ошибок с дублированием запуска. Теперь вы знаете, что такой дефект способен сильно испортить звучание игры.
Если вы хотите расширить свои знания о цифровом звуке — советую к изучению видео на этом канале. При всей лёгкости и шутливости подачи, автор объясняет те необходимые основы, без понимания которых работа с цифровым аудио будет представлять собой хождение по граблям разного калибра.
Надежда Гурская — композитор, дизайнер музыки. Работала над проектами Redeemer, Witching Tower VR, Egypt: Old Kingdom и другими.