Аудиосистемы и оптимизация

Последнее обновление: 3 апреля 2026 г.

Система голосов

Недиалоговые вокализации людей, лошадей и животных (хрюканье, звуки боли, команды и т. д.) не прописаны жёстко в игровой логике. Вместо этого они управляются через внешний конфигурационный файл voice_definitions.xml. Это позволяет легко добавлять или изменять голоса без изменения кода. Все объявления и определения записываются в XML и напрямую связываются с путями событий FMOD.

Путь к файлу:

..\Modules\Native\ModuleData\voice_definitions.xml

Объявления типов голосов

Прежде чем голос можно будет использовать, его необходимо объявить в разделе <voice_type_declarations>. Это регистрирует тип голоса, чтобы на него можно было ссылаться позднее.

<voice_type_declarations>
  <voice_type name="Grunt" />
</voice_type_declarations>

Здесь объявляется тип голоса Grunt, который теперь можно использовать в одном или нескольких определениях.

Определения голосов

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

<voice_definition
  name="male_01"
  sound_and_collision_info_class="human"
  only_for_npcs="true"
  min_pitch_multiplier="0.9"
  max_pitch_multiplier="1.1">

  <voice
    type="Grunt"
    path="event:/voice/combat/male/01/grunt"
    face_anim="grunt" />

</voice_definition>

Атрибуты определения

Подробности узла voice

Внутри <voice_definition> можно добавить один или несколько элементов <voice>:

Краткое описание процесса

1. Добавьте новый <voice_type> в раздел <voice_type_declarations>
2. Создайте <voice_definition> с именем, классом, ограничениями и диапазоном высоты тона
3. Добавьте один или несколько элементов <voice>, связывающих определение с путями событий FMOD
4. Назначьте face_anim для синхронизации анимации

Физические материалы

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

Обработка взаимодействия материалов

Каждый тип материала определяется в физической системе вместе с правилами его взаимодействия при столкновении с другими материалами. Например:

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

Особый случай: взаимодействие с водой

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

Чтобы упростить реализацию, система использует одно общее событие воды, параметризованное физическими свойствами объекта, входящего в воду:

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

Преимущества такого подхода:

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

Система приоритетов

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

Основной механизм

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

Эти параметры хранятся в SEDF (Sound Event Data File) для каждого события, обеспечивая согласованную оценку.

Фильтрация по расстоянию

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

Исключения и зацикленные события

Зацикленные звуки требуют особой обработки:

• Фоновые звуки (ambient) полностью исключены из этой системы и помечены как постоянные в FMOD — они никогда не отсеиваются логикой предварительного приоритета.
• Зацикленные звуки создают проблему: если их остановить и запустить заново, они не могут возобновиться с предыдущей позиции воспроизведения, что вызывает проблемы синхронизации.

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

Переопределения через пользовательские свойства

Пользовательские свойства (User Properties) обеспечивают дополнительную гибкость (см. Пользовательские свойства):

• Флаги игнорирования — проверки расстояния или длины можно обойти для определённых событий, если они соответствующим образом помечены
• Пользовательские множители — множитель можно задать для каждого события через пользовательские свойства, изменяя его относительный приоритет по сравнению с другими

Преимущества:

• Эффективность процессора — снижает нагрузку на FMOD за счёт отсеивания неслышимых или ненужных звуков до того, как они достигнут движка
• Гибкая приоритизация — длина, расстояние и множители позволяют точно настраивать важность события
• Безопасность синхронизации — виртуализация обеспечивает согласованность зацикленных событий при их повторной активации
• Контроль со стороны дизайнера — пользовательские свойства позволяют задавать исключения и весовые коэффициенты без изменения кода

Система фонового звука боя

Система фонового звука боя — сокращённо BASS (Battle Ambient Sound System) — предназначена для оптимизации воспроизведения звуковых эффектов высокой плотности, таких как множественные удары мечей, происходящие в одной и той же области. Вместо того чтобы позволить каждому отдельному звуку воспроизводиться независимо (что может быстро перегрузить и микс, и процессор), BASS агрегирует эти события и заменяет их единым излучателем, представляющим всю группу.

Как это работает

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

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

Взаимодействие с системой приоритетов

BASS работает до системы приоритетов нашего собственного движка. Обычно система приоритетов решает, какие звуки отсеивать, когда за воспроизведение конкурирует множество голосов. В этом рабочем процессе BASS заранее снижает полифонию на уровне источника — активным остаётся только сгруппированный излучатель, а значит, системе приоритетов приходится управлять меньшим количеством голосов. Это предотвращает излишнее использование ЦП/DSP и обеспечивает стабильное качество звука во время массовых боёв.

Идентификаторы групп BASS

Используйте пользовательское свойство battle_ambient_group_id (см. Пользовательские свойства), чтобы назначить событие группе BASS.

Примеры: - Добавление нового события оружия → установите battle_ambient_group_id равным 2 - Добавление события шага для нового типа верхового животного → установите battle_ambient_group_id равным 1

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

Преимущества:

• Оптимизация производительности — предотвращает всплески нагрузки на ЦП и память из-за чрезмерного количества перекрывающихся звуков
• Чистота микса — заменяет загромождённые слои переходных звуков единым управляемым излучателем
• Масштабируемость — дизайн событий, управляемый параметрами, автоматически адаптируется к плотности боя

Производительность и оптимизация

В такой требовательной к ЦП и памяти игре, как Mount & Blade II: Bannerlord, FMOD должен рассматриваться как часть общего бюджета производительности. Плохо управляемые звуковые банки, кодеки или дизайн событий могут потреблять ресурсы, необходимые игровому движку для всего остального. Оптимизация — это не разовая задача, а постоянная дисциплина на протяжении всего процесса моддинга.

Стратегия кодеков и ассетов

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

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

Практичные для ПК форматы FMOD Studio:

Типы загрузки

Каждый ассет имеет настройку Load Type (тип загрузки), которая определяет, как он хранится в памяти:

Потоковая передача и управление банками

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

Банки — это контейнеры для событий, ассетов и метаданных — они определяют, что FMOD загружает в оперативную память во время выполнения. Плохо структурированные банки оставляют ненужные ассеты в памяти, увеличивают время загрузки и создают узкие места при потоковой передаче. Каждое событие должно находиться в одном банке; одно и то же событие никогда не должно присутствовать в нескольких банках, если только это не неизбежное требование дизайна.

Управление событиями, DSP и каналами

Каждое событие создаёт один или несколько голосов, каждый из которых потребляет ЦП и память. Стерео-, квадро- или 5.1-события умножают количество каналов, участвующих в микшировании. Добавьте к этому DSP на каждом тракте, и затраты растут быстро. Если вы активно не управляете экземплярами, каналами и цепочками DSP, ваш микс может задушить процессор задолго до того, как ассеты заполнят память.

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

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

Держите количество каналов реалистичным:

• Используйте моно для любого звука без пространственной ширины
• Используйте стерео только тогда, когда ширина действительно важна (музыка, фоновые звуки, UI)
• Приберегите квадро или 5.1+ для настоящих окружающих звуковых подложек, оправдывающих такие затраты

Каждый дополнительный канал означает дополнительное микширование, панорамирование и потенциальную обработку DSP. Не тратьте каналы на одноразовые звуки, которые в большинстве контекстов всё равно сводятся к моно.

Управление нагрузкой DSP

Обработка DSP — самая тяжёлая часть производительности аудио во время выполнения. Эффекты, такие как свёрточная реверберация (convolution reverb), FFT-фильтры и многополосная динамика, потребляют значительные ресурсы ЦП — часто больше, чем оправдывает их слышимая польза. Применяйте DSP только там, где это даёт очевидную ценность, например, при формировании общего микса таким образом, который нельзя предварительно «запечь» в файл. Для обычных одноразовых событий держите их чистыми или встраивайте обработку прямо в аудиофайл.

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

Шины и маршрутизация

Иерархии шин должны оставаться функциональными и минимальными. Группируйте основные категории под выделенными подшинами только там, где это служит ясной цели. Используйте сенды и сайдчейны осознанно — каждый дополнительный переход маршрутизации добавляет нагрузку на микширование каналов и DSP. Консолидируйте цепочки DSP на уровне шины вместо того, чтобы складывать их на множестве отдельных событий. Снапшоты (snapshots) затем могут изменять свойства одного эффекта DSP сразу в нескольких состояниях, значительно сокращая общее количество необходимых экземпляров DSP.

Использование запечённых эффектов

Если звуку всегда нужна окраска (эквализация, дисторшн, статичная реверберация), запеките её прямо в исходный файл. Оставьте DSP во время выполнения для действительно интерактивной обработки: фильтров, управляемых параметрами, дакинга, модуляции высоты тона или зон реверберации окружения, которые меняются динамически. Это предотвращает медленное накопление избыточных затрат на DSP.

Импорт ассетов

Держите ассеты компактными до того, как они попадут в FMOD:

• Обрезайте тишину из сэмплов
• Нормализуйте громкость до согласованной базовой линии LUFS
• Соответствуйте частоте дискретизации проекта (48 кГц), чтобы избежать скрытого ресэмплинга и потраченных впустую циклов процессора

Хотя FMOD кодирует ассеты в собственные форматы на этапе сборки, исходный формат, который вы импортируете, всё равно влияет на рабочий процесс. Использование .wav для всего раздувает проект, поскольку файлы .wav не сжаты. Переход на .flac для исходных ассетов может значительно сократить объём занимаемого места на диске при сохранении качества без потерь — это не влияет на итоговый закодированный формат (PCM, Vorbis, ADPCM и т. д.), но делает управление ассетами более лёгким и быстрым.

Тестирование граничных случаев

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