Как игровые дизайнеры создают шаблоны вибрации?

13

Мне любопытно создать и реализовать шаблоны вибрации для консольных контроллеров (для контроллера PS4, если это имеет значение).

Есть задержка и параметр скорости двигателя, верно? Но также мы можем исчезнуть с левого мотора на право, или заставить их работать вместе ....

Есть ли стандартизированный способ создания этих шаблонов?

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

Как это делается в игровой индустрии?

Франкское
источник
Я видел грохочущие системы, проходящие через аудио-конвейер игры, так что вы можете быть там. Я не могу говорить из личного опыта о деталях - будь то конкретный трек гул или если гул был выведен из громкости звукового эффекта, или если соединение было чисто для запуска звуков и грохота через согласованный интерфейс, в то время как они использовали совершенно разные форматы исходных данных.
DMGregory
У вас нет такого точного контроля над грохотом. Кроме того, в DualShock левый гул тяжелый, а правый легкий, поэтому вы получаете низкую частоту от левого. (У меня может быть левый / правый назад, но вы поняли).
Almo
@Almo А как насчет HD-системы Nintendo? Вы наверняка имеете некоторую форму контроля над этим
Bálint
Что бы раскрыть вопрос, чтобы быть слишком широким. Я на самом деле не знаю об их системе.
Almo
1
@DMGregory Звуковые движки, о которых мне известно, что они работают с гулом / тактильным звуком, используют только те же триггеры, огибающие и т. Д., А не звуковые сигналы. Как говорит Almo, у вас нет такого уровня контроля на уровне API. Я не могу себе представить, что система Nintendo сильно отличается - вам не нужно обновлять любую систему грохота на такой высокой частоте, где реальные аудиоданные были хорошим выбором.
Ричард Байрон

Ответы:

8

Контроллер PS4 dualshock имеет значения в 1 байт для левого и правого грохочущих пакетов, так что это в основном работает как 8-битная музыка.

Большинство из них находятся за NDA, поэтому очень трудно получить какую-либо информацию об этом (даже информацию выше было трудно получить, я понял это только из стороннего SDK для node.js). Это информация, которую я собрал воедино:

Процесс буквально похож на создание 1-байтовой стереофонической музыки (и предположительно ее исполняет музыкальный исполнитель). Он включает в себя подключение контроллера PS4 к компьютеру и использование программы для создания шаблонов грохота. Они делают один на основе догадок, затем запускают его, затем настраивают и повторяют эти шаги, пока шаблон не будет чувствовать себя хорошо.

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

PS4 SDK также поставляется с некоторыми предопределенными шаблонами. Вот некоторые примеры: пилообразный паттерн (постоянно увеличивается, затем идет от 255 до 0), синусоида и треугольники (линейно увеличивается до 255, затем обратно до 0 линейно).

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

Источники:

Балинт
источник
Некоторое время назад я нашел эту статью, в которой изложена структура отчета для связи между контроллером и обратно , включая смещения байтов каналов грохота и флаг, управляющий ими. Это может быть наиболее полный доступ в Интернете без доступа к собственной документации и API Sony.
DMGregory
@DMGregory Не могли бы вы добавить это в раздел источников?
Балинт
Пожалуйста, сделай. :) Я поделился этим, надеясь быть полезным.
DMGregory
4

Там нет стандартизированного способа.

Разные устройства имеют разные возможности грохочения и ограничения.

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

Таким образом, большинство функций Force Feedback, упомянутых в MSDN / DirectX и других API, на практике никогда не реализовывались на пользовательском рынке и не имеют таких плохих и / или непереносимых реализаций «умных» элементов управления (конверт, повтор и т. Д.), Как быть настолько непригодным, что на практике разработчики часто вынуждены просто использовать элементы управления ВКЛ / ВЫКЛ непосредственно со своей собственной реализацией эффекта.

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

Добавление новых технологий, таких как VR-перчатки, делает эти универсальные API еще более недостающими.


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

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

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

Контроллеры часто обновляются один раз за кадр, обеспечивая частоту обновления примерно от 20 Гц до 100 Гц. Это ограничивает разрешение вашего ШИМ-управления, поскольку вы не хотите, чтобы двигатели глохли при самых низких настройках. И вы не знаете, насколько низкими могут быть двигатели контроллера конечного пользователя перед остановкой (остановкой), поэтому вам нужен хороший запас прочности.

Некоторые системные требования накладывают дополнительные ограничения на то, что вы можете с ними делать.

Мобильные устройства обычно имеют только 1 вибрационный двигатель, и ШИМ может быть невозможен из-за низкой инерции из-за размера веса и медленной скорости обновления. Система может фильтровать его дальше, чтобы предотвратить неправильное использование или даже повреждение (ограничения транзистора силового привода и пики индукции) или просто очень медленную подсистему GPIO.

На мобильном телефоне вы можете быть ограничены или хотите ограничить себя «вибрацией примерно X * 50 миллисекунд» без ШИМ.

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


Из - за все эти различия , которые вы можете захотеть абстрагировать вибрационную систему , чтобы играть ограниченное количество высокоуровневых макро-эффекты по имени в перестрелке и забыть моды: PlayVibration(player, "Got Loot");, PlayVibration(player, "Heavy Fall");, StopAllVibrationFor(player);, ...

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

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

Хотя устройства с реальным грохотом, управляемым соленоидом, могут рассматриваться как аудиоустройства и использовать аудио API из-за проблем с аккумулятором, это может противоречить правилам системы, если соленоид постоянно включен / активен . «Уровень мощности 0» может не совпадать с «Отключение соленоида», поэтому даже в этом случае требуется особая осторожность.

Стефан Хоккенхалл
источник
3

От Андре Ламота в «Уловках гуру программирования игр для Windows»:

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

Хотя этот текст довольно старый, быстрый поиск в MSDN для обратной связи показывает, что упомянутые концепции не сильно изменились; Вот краткое изложение тем, описанных в их Основных концепциях обратной связи по силе :

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

Что касается PS4, то единственное, что я обнаружил, - это документация по Unreal Engine 4 , в которой говорится:

Эти (идентификаторы) будут отображаться в соответствии с конкретной реализацией платформы. Например, PS4 только слушает каналы XXX_LARGE и игнорирует остальные, в то время как XBox One может отобразить XXX_LARGE на двигатели ручки и XXX_SMALL на двигатели триггера. И iOS может привязать LEFT_SMALL к своему единственному двигателю.

Как показывает ответ Стефана Хоккенхалла, каждая платформа отличается. И, как предлагается в чате GDSE , возможно, что подробности API обратной связи по PS4 ограничены NDA.

Pikalek
источник