Gamedev Anton Titov
2 258

Адаптивная музыка на примере FMOD

В закладки

Теория

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

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

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

Как нам снова подсказывает русская «Википедия» адаптивная музыка это:

В общем, мы лучше обратимся к английской википедии.

«Ноги» у адаптивной музыки растут аж из 1981 года — во Frogger музыка резко менялась, когда игрок достигал безопасной точки. Со временем, адаптивная музыка становилась всё сложнее и были сформированы основные методы: «горизонтальный» и «вертикальный».

«Горизонтальный» метод заключается в переключении между заранее подготовленными музыкальными сегментами в зависимости от игровой ситуации. Классический пример — пока игрок бродит по локации играет спокойная музыка, но как только он вступает в бой, включается боевой сегмент.

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

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

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

Планирование

Предположим у нас есть схема уровня: «катсцена — первая локация — вторая локация — третья локация». Здесь идеально подойдет «горизонтальный» метод — нам нужно создать три музыкальных сегмента и переключать их при смене локаций. Катсцену за сегмент не считаем, так как она проигрывается только один раз в начале.

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

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

Написание музыки

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

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

При написании адаптивной музыки нам нужно придерживаться нескольких простых правил.

Во-первых, по возможности избегать ходов, когда инструмент начинает играть «из-за такта», то есть вступать немного раньше своего сегмента. Иначе может получится ситуация, когда инструмент вступил в конце первого сегмента, а во втором его партии нет, и он просто обрывается «на полуслове».

Во-вторых, используя обработки следует помнить о «хвостах» инструментов, особенно длинных дилеях и реверберации — мы будем экспортировать лупы определенной длины и всё лишнее будет обрубаться.

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

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

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

Имплементация

Вот мы и добрались до FMOD. На данном этапе у нас есть хитрый план и целая гора аудиофайлов (в нашем случае 33).

Первым делом создаём (и соответствующее называем) аудиодорожки для каждого трека и закидываем туда наши аудиофайлы.

Первую лепту в интерактивность нашего трека внесет Его Величество Рандом.

В FMOD, помимо всего прочего, существует такая штука как Multi Instrument. Его отличие от обычного Single Instrument в том, что в него можно загрузить несколько аудиофайлов и каждый раз будет проигрываться случайно выбранный аудиофайл. Это хорошо подходит для создания разнообразия в рамках одного музыкального сегмента.

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

  1. Указываем музыкальный размер и темп — это нужно для корректной работы квантизации
  2. Создаём зацикленные области, каждая из которой будет отвечать за свой музыкальный сегмент
  3. Создаём маркеры перехода для каждого сегмента
  4. Создаём области перехода, которые привязаны к определённым маркерам

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

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

Настройка области перехода на вторую локацию

В настройках области перехода указываем, что срабатывать она должна, когда параметр Phase равен от 2 до 2,9 (такой широкий диапазон нужен для избежания ошибок). А заодно указываем интервал квантизации в четыре такта (1 квадрат) — теперь переход не будет внезапным. После того, как FMOD получит команду на смену сегмента, он сначала доиграет до конца текущий сегмент и только потом переключится. Собственно для этого квантизация и нужна.

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

Для включения или отключения инструментов мы воспользуемся банальной автоматизацией громкости. Для этого создаем ещё один параметр, у нас это будет Parameter 1, и устанавливаем диапазон значений от 1 до 10.

А потом рисуем нашу любимую автоматизацию для каждого инструмента.

По сути, в любой момент времени все инструменты играют, они активны, разница лишь в уровне громкости

На выходе мы получим нечто такое.

Снова извиняюсь за звук в моно, наши специалисты работают над этим

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

P. S. Для любопытных — проект со всеми звуками лежит здесь.

Если вы хотите поделиться своим опытом создания игры или рассказать какую-то историю, связанную с геймдевом, то смело нажимайте кнопку «Написать» и делитесь опытом. А мы, отредактировав текст (если это потребуется), перенесём его в раздел Gamedev.

#звук #опыт

Материал дополнен редакцией

Материал опубликован пользователем. Нажмите кнопку «Написать», чтобы поделиться мнением или рассказать о своём проекте.

Написать
{ "author_name": "Anton Titov", "author_type": "self", "tags": ["\u0437\u0432\u0443\u043a","\u043e\u043f\u044b\u0442"], "comments": 46, "likes": 84, "favorites": 66, "is_advertisement": false, "subsite_label": "gamedev", "id": 17197, "is_wide": false, "is_ugc": true, "date": "Thu, 15 Mar 2018 07:28:37 +0300" }
{ "id": 17197, "author_id": 3184, "diff_limit": 1000, "urls": {"diff":"\/comments\/17197\/get","add":"\/comments\/17197\/add","edit":"\/comments\/edit","remove":"\/admin\/comments\/remove","pin":"\/admin\/comments\/pin","get4edit":"\/comments\/get4edit","complain":"\/comments\/complain","load_more":"\/comments\/loading\/17197"}, "attach_limit": 2, "max_comment_text_length": 5000, "subsite_id": 64954 }

46 комментариев 46 комм.

Популярные

По порядку

Написать комментарий...
18

Девелоперам и композиторам порекомендую посмотреть Elias - музыкальный движок, заточенный под реализацию адаптивной музыки. Есть интеграция с Unity, и Unreal, возможно связать также с Wwise, Fmod и Fabric.

https://www.eliassoftware.com/

Ответить
5

Хорошая статья.

Только "затакт", а не "потому что такт"

И перфоманс от такого количества дорог точно будет не радужным.

Ответить
1

Только "затакт", а не "потому что такт"

Вот тут не понял, это про что?

И перфоманс от такого количества дорог точно будет не радужным.

3% загрузка CPU, только что проверил. И это при том, что аудио не пожатое, после экспорта в саундбанк еще меньше будет.

Ответить
1

3% - только стримовая музыка?

из-за такта - потому что такт
из затакта - начало чуть раньше такта

Ответить
1

Понял, с затактом ошибочка вышла. Хотел исправить, но уже поздно :(

3% только музыка, но там аудио непожатое 48/24, конечно его тяжело ворочать. После экспорта, когда FMOD его сконвертирует, там на всю музыку дай бог пол процента наберется.

Ответить
2

Game audio 101: декодирование "пожатого" звукового контента требует БОЛЬШЕ ресурсов CPU нежели проигрывание некомпрессированных wave-файлов. :)
Далее цитирую непосредственно Fireflight Technologies.

### Test Device: A
- **CPU:** Apple A7 @ 1.3 GHz (iPhone 5S)
- **OS:** 8.0

### Results: A
- **DSP with Vorbis:** 13.7% (+/- 1.3%)
- **DSP with FADPCM:** 3.3% (+/- 0.3%)
- **DSP with PCM:** 1.1% (+/- 0.2%)
- **Update at 60 FPS:** 0.9% (+/- 0.1%)

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

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

Ответить
0

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

Ответить
7

А чем собственно кодек занимается, как не декодированием закодированного материала в реальном времени?:) (прошу прощения, по-русски эта фраза звучит отвратительно) Даже само название codec - coder/decoder. В фмоде есть выбор Default encoding settings под все платформы. Ну вот как раз из-за того что "не технарь" и вылезают проблемы с оптимизацией. Я кстати несмотря на весь сухой тон общения не осуждаю, а просто указываю на те места, на которые стоит обратить внимание в том случае если мы делаем не технодемку для ютуба, а реальный проект. Плюс при такой "раскладке" мультитрека у тебя единовременно используется около 11 каналов(я попрофайлил проект, чтоб не быть голословным), а во время смены мультисаунда пиковое значение каналов(или голосов) доходит до 22, так как старый мультисаунд доигрывает и новый подгружается. И несмотря на то, что на ПК или консоли это может быть терпимо, так как там использование хардварных каналов уже obsolete(хотя зависит на самом деле от игрового движка и настроек в API middleware), то на мобильном проекте это ужас и кошмар, так как многие девайсы(особенно на андройде) могут поддерживать от 12 до 32(в лучшем случае) одновременно звучащих голосов. И это лимит на все звуки в сцене. Соответственно, если музыка с высоким приоритетом и при этом отжирает 11-22 канала, то остальные звуки начнут отрубаться. А если приоритет музыки низкий - то отдельные треки в таком "пироге" начнут отключаться. Собственно поэтому никто обычно настолько многослойную систему не делает даже в ААА-проектах, потому что это избыточно.

Ответить
1

Видимо я просто везуч, потому что до сих пор никаких проблем с производительностью не было, в том числе и на слабеньких андроидах. В любом случае спасибо за разъяснение, нужно будет изучить этот вопрос.

Ответить
2

Да, разумеется FMOD жмёт аудио самостоятельно. Проблема в том, что само по себе воспроизведение аудио в формате vorbis и любых других форматах сжатия подразумевает декодирование, которое осуществляется CPU. Чем больше файлов нужно воспроизводить одновременно, тем больше ресурсов CPU будет задействовано. Вдобавок к этому на надо забывать, что дополнительные слои занимают больше места в RAM и раздувают размер билда. Можно было бы ещё добавить про физические голоса и полифонию, но это всерьёз актуально только при работе с мобильными платформами.

Ответить
0

Быстрее тогда. 3 часа прошло, пост недоступен будет

Ответить
0

Опоздал уже.

Ответить
0

5 лет учился в музыкалке, такого не помню. Что-то очень специфическое.

Ответить
4

Годно. Хочу продолжения.

Ответить
2

Хорошая статья!

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

Технический директор на проекте совершенно не обрадуется такому подходу. Лучше всё же чётко обозначить слои на этапе планирования и не перегружать RAM и CPU без явных причин.

Ответить
2

В принципе, до оптимизации и экспорта банка в движок такой подход возможен. Я когда собираю в FMOD трек - иногда перкуссию рендерю "построчно". Потом после экспериментов с автоматизацией - отсекаю лишнее и рендерю по 2-3 дорожки в 1. Группирую в стемы всё, что можно сгруппировать, и решаю простым фильтром те вопросы, которые решала громкостью, например (иногда это звучит интереснее). Т.е. 11 дорожек удобны в прототипе ивента, но не рискую делать так в финальной сборке. RAM и CPU - это ладно. А что с загруженностью диска произойдёт, если стримингом 11 дорог гнать?

Ответить
0

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

Ответить
2

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

Ответить
0

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

Ответить
1

Божечки, это великолепнейший пост. Лично для меня — самое крутое что я когда-либо видел на DTF.
Мечта стать композитором в геймдеве стала чуточку ближе))

Ответить
3

Спасибо :3

Ответить
1

А ещё можно писать трекерную музыку и не ебать себе мозг. Поскольку музыка играет в реальном времени - трекеры дают значительно большую гибкость и возможности в адаптивности (привет Soul Reaver).

P.S.
И почему до сих пор никто не написал движок/формат, где в качестве инструментов используются не семплы, а подключаемые модульные синтезаторы? Компьютеры уже давным давно позволяют это по мощности, а демосцены уже давно используют самописные виртуальные синтезаторы с незапамятных времён. Ведь вы только представьте - крутить ручку синтезатора прямо в реальном времени в мелодии, сколько возможностей! Не, есть конечно всякие библиотеки от трекеров а ля Sunvox, но они все закрыты сами в себе, нет универсального формата с подключаемыми внутрь синтезаторами. =Р
P.P.S.
А статье как всегда плюс.

Ответить
1

Трекер стар и уныл, можно просто midi использовать, это много где применяется. А насчет модульных синтезаторов - очень специфичная тема с множеством "но". Во-первых, хорошие синтезаторы очень жручи до CPU. Во-вторых, что делать с живыми инструментами? Грузить туда сэмплер со стагиговыми библиотеками? В-третьих, многие приемы, вроде реверса, в риалтайме очень сложно сделать. В-четвертых, хорошая обработка жрет еще больше, чем сами синтезаторы.

Конечно когда-нибудь мы к этому придем, но пока очень рано.

Ответить
1

Трекер стар и уныл, можно просто midi использовать, это много где применяется.

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

Это вопрос исключительно оптимизации. Почти во всех случаях синтезаторы жрут лишь потому, что по большому счёту их программный код является одним большим куском неоптимизированного говна. Когда речь идёт о выпуске VST-версии полностью цифрового железного синтезатора от самого производителя (как это, например, сделал Roland с его D-50) - сразу всё "неожиданным образом" летает, поскольку код изначально оптимизировался, чтобы засунуть его как можно в более слабую железку. Можно также вспомнить просто хорошо сделанные синтезаторы, как какой нибудь FM8, который вообще ничего не жрёт, а обойтись можно лишь только им. И при этом не будем забывать, что часть ресурсов уходит именно на средства взаимодействия композитора с синтезатором (привет Arturia, я смотрю на тебя). А ещё лучше - эмуляторы аркадных автоматов и приставок, вроде MAME, который запускался на совсем уж древнючих компьютерах и спокойно воспроизводил музыку с эмуляцией синтезаторного чипа в реальном времени: начиная от совсем простеньких генераторов простых волн, вроде SID, AY-3-8910 и RP2A03; через обычные Ямаховские ФМ-синтезаторы, вроде OPM (полный аналог этих чипов стоял в ранних поколениях четырёхоператорных FM-синтезаторов, вроде DX100 и FB-01), OPNA, OPN2 (блин, да я запускал эмулятор Сеги на своём Nokia 3230 в далёком 2005ом!) и иже с ними; и заканчивая такими полновесными монстрами, а ля SCSP. Я же не говорю использовать VST для этого, я говорю именно писать отдельные синтезаторы под это дело с изначальной на то заточкой под это дело. Компьютеры уже давно до этого дозрели, демосцены с внутренними самописными синтезаторами были уже как минимум в самом начале нулевых (если не раньше) и звук был нисколько не хуже обычного потокового аудио.
Во-вторых, что делать с живыми инструментами? Грузить туда сэмплер со стагиговыми библиотеками?

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

Вопрос - а зачем? Я лично никогда не понимал толка от этих многоэтажных эффектов на один трек. Почему, например, какая нибудь музыка на Sega Saturn и первом PlayStation обходилась безо всякой этой гигантской обработки и звучала во многом даже лучше, чем многие вещи, которые создаются сейчас? Почему первый "Soul Reaver" в 1999ом с его эдаким встроенным аналогом трекера мог выдавать шикарный адаптивный звук, а современные игры как-то не шибко с этим спешат? Если нет особой разницы, тогда к чему всё это?
Нет, понятно конечно, что это быстрый способ достижения нужного результата, однако это всё находится в плоскости оптимизации процесса, где эти тысячи эффектов представляются лишь эдаким брутфорсом от мира музыки и вовсе не обязательными.

Ответить
1

Ну во всех ваших примеров как раз полно тех самых "но", которые я упоминал. Что если мне вообще не нужны синтезаторы, например? Я может фэнтези делаю. Что если мне нужно эмулировать звук муговских фильтров? Я художник я так вижу, вот нужны они мне, хоть усрись. Зачем городить огороды, если можно сделать все проще и результат будет лучше?

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

Ответить
0

Что если мне вообще не нужны синтезаторы, например? Я может фэнтези делаю.

Тогда это ваши проблемы.
Важно дать сам инструмент и есть гигантское количество применений (смею предположить, что их даже больше, чем случаев, где без "живых" не обойтись), где живые инструменты либо совсем не нужны, либо нужны до пренебрежительных значений важности и спокойно заменяются более простыми "эрзацами" без потери качества звучания.
И да, фентези не обязательно подразумевает живые инструменты. Я знаю много фентези-игр, где "живой музыкой" и не пахнет и их саундтрек я предпочту даже больше, чем обычному в сотый раз заезженному "дженерик оркестру", от которого уже тошнит просто.
Как пример, кстати, можно вспомнить саундтрек ко второму Soul Reaver'у (первый тоже, но у него саундтрек ещё более абстрактный, я бы его даже охарактеризовал как скорее... не знаю... "Neoclassical Dark Electro"? лол). Он пусть и не синтезаторный (о чём сейчас идёт разговор), но оркестровый саундтрек полностью на семплах и эффектах, воспроизводящейся в реальном времени (кроме заглавной мелодии) - внутри был собственный а ля трекерный движок, сделанный из-за того, что весь саундтрек в том чрезвычайно адаптивном варианте, который они хотели, тупо не влез бы на диск. Как раз, кстати, фэнтези, правда тёмное.
Что если мне нужно эмулировать звук муговских фильтров? Я художник я так вижу, вот нужны они мне, хоть усрись.

Вы музыку зачем пишите? Как саундтрек к игре или исключительно как средство самовыражения? Смысл в этих фильтрах, если кроме других композиторов их никто не заметит? XD
Зачем городить огороды, если можно сделать все проще и результат будет лучше?

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

Ой, а звуковые движки типа не разрабатывают и это не стоит денег? FMOD, Wwise и прочие - они так, мана небесная и отдаются даром, лол. FMOD, например, изначально разрабатывался как система поддержки трекерной музыки (у него даже название об этом говорит, где этот "MOD" - как раз трекерная музыка), это потом он уже разросся до современных возможностей.
Сколько в год выходит игр, куда подошла бы такая музыка?

Какая? Электронная/семплерная? Дофига и больше, лол. Постоянно слышу.
Я просто даже не могу придумать сценария, с которым бы не справилась обычная адаптивная музыка. Максимум MIDI в помощь и никаких проблем.

Да ладно. Представьте например, что у вас есть FM-синтезатор, где ручки огибающей операторов регулируются в реальном времени в зависимости от изменяющейся вокруг ситуации в игре. Ни один фильтр/эффект вам такого не даст! Какие просто безграничнейшие возможности изменения мелодий! ЭТО ЖЕ. ПРОСТО. ОХУЕННО. (простите)

Ответить
1

Круто, и хочется больше примеров. Вспомнил Ведьмака и Horizon как примеры «горизонтального» метода, и серию Mario — «вертикального».

При горизонтальном всегда бесит, когда куски трека обрываются резко. С этим как-то можно бороться?

Ответить
1

Нормально делать квантайз.

Ответить
0

Квантайз + экспорт вместе с хвостами + асинхронное воспроизведение и все будет хорошо

Ответить
0

Pure Data? Её используют и для написания музыки в играх? Всегда думал, что ей пользуются только композиторы-энтузиасты для фестивалей экспериментальной музыки)

Ответить
3

Скорее нет, чем да, Pd - это не самая стабильная среда на свете. Ограниченно используют для прототипирования, плюс могут иногда собирать отдельные процедурные плагины с помощью Heavy - но это чаще для саунд-дизайна.

Spore это такое исключение, у них был очень большой бюджет и много желания сделать генеративную систему на Pd. В итоге они потратили очень много ресурсов на переписывание исходного кода Pure Data, я бы никому не советовал такое повторять.

Ответить
1

Да, например в Spore использовали - http://uk.pc.gamespy.com/pc/spore/853810p1.html

Ответить
1

О, ништяк, спасибо

Ответить
1

Про русскую вики — проорал! Это как каждый раз, когда я вижу слово «функционал» (популярное у разработчиков), то вспоминаю вот это:
https://pavelf.ru/all/function/

Ответить
1

Ничерта не понял, но было очень интересно.
Спасибо)

Ответить

Комментарий удален

0

в статье скрины Ableton live?

Ответить
1

FMOD. Но не исключено, что при создании интерфейса вдохновлялись именно лайвом.

Ответить

Комментарий удален

Комментарий удален

0

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

Ответить
0

Я что на хабре оказался, что-то новенькое...

Ответить
0

Классная статья, спасибо, вот бы ее на лет 5 пораньше прочитать, а то выдумывал с ребятами костылями как мог в приложении одном (не игра)

Ответить
0

Спасибо за текст. Перетащили в Gamedev, отредактировав чуть-чуть.

Ответить

Комментарий удален

0

Прямой эфир

[ { "id": 1, "label": "100%×150_Branding_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox_method": "createAdaptive", "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "ezfl" } } }, { "id": 2, "label": "1200х400", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "ezfn" } } }, { "id": 3, "label": "240х200 _ТГБ_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fizc" } } }, { "id": 4, "label": "240х200_mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "flbq" } } }, { "id": 5, "label": "300x500_desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "ezfk" } } }, { "id": 6, "label": "1180х250_Interpool_баннер над комментариями_Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "clmf", "p2": "ffyh" } } }, { "id": 7, "label": "Article Footer 100%_desktop_mobile", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fjxb" } } }, { "id": 8, "label": "Fullscreen Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fjoh" } } }, { "id": 9, "label": "Fullscreen Mobile", "provider": "adfox", "adaptive": [ "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fjog" } } }, { "id": 10, "label": "Native Partner Desktop", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyb" } } }, { "id": 11, "label": "Native Partner Mobile", "provider": "adfox", "adaptive": [ "phone" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fmyc" } } }, { "id": 12, "label": "Кнопка в шапке", "provider": "adfox", "adaptive": [ "desktop", "tablet" ], "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fdhx" } } }, { "id": 13, "label": "DM InPage Video PartnerCode", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox_method": "createAdaptive", "adfox": { "ownerId": 228129, "params": { "pp": "h", "ps": "clmf", "p2": "flvn" } } }, { "id": 14, "label": "Yandex context video banner", "provider": "yandex", "yandex": { "block_id": "VI-250597-0", "render_to": "inpage_VI-250597-0-1134314964", "adfox_url": "//ads.adfox.ru/228129/getCode?pp=h&ps=clmf&p2=fpjw&puid1=&puid2=&puid3=&puid4=&puid8=&puid9=&puid10=&puid21=&puid22=&puid31=&puid32=&puid33=&fmt=1&dl={REFERER}&pr=" } }, { "id": 15, "label": "Плашка на главной", "provider": "adfox", "adaptive": [ "desktop", "tablet", "phone" ], "adfox": { "ownerId": 228129, "params": { "p1": "byudo", "p2": "ftjf" } } }, { "id": 17, "label": "Stratum Desktop", "provider": "adfox", "adaptive": [ "desktop" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fzvb" } } }, { "id": 18, "label": "Stratum Mobile", "provider": "adfox", "adaptive": [ "tablet", "phone" ], "auto_reload": true, "adfox": { "ownerId": 228129, "params": { "pp": "g", "ps": "clmf", "p2": "fzvc" } } } ]
Пять простых способов разогнать свой ПК
с помощью соли и чайной ложки
Подписаться на push-уведомления