Хороший способ воспроизвести звук, когда что-то происходит? Как это звучит?

Так что я думал о том, как монолитно мои занятия занимают много времени. Например, в методе Characterкласса Jumpможно иметь ссылку на объект звукового эффекта и воспроизводить его. Само по себе это хорошо, но если принять во внимание физику, анимацию, столкновения и т. Д., Метод Jump становится огромным, и у Characterкласса много зависимостей от множества разных вещей. Тем не менее, это может быть хорошо. Однако что, если мы больше не хотим, чтобы звук воспроизводился, когда персонаж прыгает? Теперь мы должны найти эту конкретную строку кода в путанице Jumpкода и закомментировать ее или что-то еще.

Итак .. я думал ..

Что, если вместо этого был какой-то AudioSystemкласс, и все, что он делал, это подписывался на случайные события, которые его интересуют в других классах. Например, у Characterкласса может быть Jumpedсобытие (я полагаю, тоже статическое), которое вызывается внутри Characterкласса в методе. Тогда Characterкласс ничего не узнает о небольшом звуковом эффекте, который воспроизводится, когда персонаж прыгает. Это AudioSystemбыл бы огромный класс, к которому программист мог бы вернуться, чтобы связать звуковые эффекты с определенными событиями, происходящими в игре, с использованием статических событий. Тогда, если он получил слишком большой , он может быть отделен в подклассы , как EffectsAudioSystem, BackgroundAudioSystem, AmbientAudioSystemи так далее.

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

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

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

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

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

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

Тем не менее, хорошая идея отделить ваш код, но сообщения - это просто еще один способ глубоких связей. Некоторый код просто должен быть связан, используйте самый прямой способ связать их, не перегружайте.

Я не думаю, что система передачи сообщений закончена над разработкой вообще. Фактически, это может значительно облегчить выполнение задач в фазе полировки. Ты делаешь это правильно!

То, что вы описали, было именно тем, что я собрал для нашей игры Global Game Jam в прошлом году. Я отвечал за создание и редактирование SFX, а также за интеграцию музыки, написанной мной и другим композитором, в игру так, чтобы это не отстой.

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

пример

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

Если бы я написал его на C ++, то потребовалось бы немного больше времени, чтобы абстрагировать все возможные варианты поведения звуков. Требования к сообщению, уведомляющему систему о совершенном действии, не будут слишком сложными. Для этого просто понадобится тип сообщения, объект происхождения или объект, на который влияют, доступ к некоторому виду контекста игрового состояния и больше ничего. Протокол может расти по мере роста потребностей игры. Естественно, если вы делаете все это в реализации в коде (например, в нашем неаккуратном коде GGJ), у вас проблема с монолитным классом хуже. Но это легко смягчить, создав систему, управляемую данными.

В любом случае, вот как наша игровая аудиосистема реагировала на различные сообщения:

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

• Игрок удерживает пробел для ускорения: при получении этого звучал небольшой «свистящий» звук движителя, но одновременно с этим за 1,5 секунды усилился рев двигателя с низкой петлей. Система частиц также использовала это, чтобы запустить эмиттер IIRC

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

• Игрок сталкивается со злой космической шахтой: космические мины плохие, поэтому не только присутствует металлический ударный звук в сочетании со взрывом (который просто превращается в один звук), но также есть случайно выбранный звук ужаса динозавра, который играет. Более вероятно, что вы выберете больше «плачущих» звуков, так как здоровье игрока становится ниже.

Уже забавная игра становится приятной игрой, когда ее саундтрек активен и динамичен, даже с небольшим простым поведением, как я описал выше. Да, есть некоторая логистика, чтобы убедиться, что переданы правильные данные. Но эй, BFD. Это будет далеко не самая сложная вещь, которую вам придется написать в большем объеме кода игры.

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

[EDIT] Кроме того, я вижу, что вы пометили этот C #. Это XNA, и если да, то используете ли вы XACT? Если вы используете XNA, вы должны использовать XACT.

Я согласен с Майком Семдером в том, что система передачи сообщений может быть чрезмерно сложной (пока что в любом случае).

Насколько я понимаю, ваш класс в настоящее время выглядит как «монолитный класс» Bjorn , как можно видеть в «монолитном классе» здесь .

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