Про особенность музыкальных игр.

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

В большинстве игр обязательно есть какое-либо движение - будь то носящийся по всей карте Meat Boy или падающий с потолка ящик в Portal. Любое перемещение становится плавным, когда мы добавляем один волшебный ингредиент - Delta Time, то есть время между фреймами. С помощью него, как известно, мы перестаем зависеть от выдаваемого фпс, что делает, к примеру, скорость персонажа всегда одинаковой.

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

У нас есть расстояние между началом и концом полета мяча S. Чтобы рассчитать время полёта T, требуется знать скорость песни - её BPM (beats per minute). Это количество ударов (долей) в минуту, как если бы вы отстукивали темп песни ладошкой по коленке и записали количество шлепков за 60 секунд. Количество чего-либо в единицу времени есть частота, значит, чтобы найти время одного удара (период), достаточно перевернуть её с ног на голову, не забыв перевести в секунды, умножив на 60 (T = 60 / BPM).

В школе вроде учили, что скорость V = S / T. Не забудем добавить в формулу наш любимый delta time, и готово!

Как только мяч долетает до нужной позиции, мы нажимаем кнопку, меняя end point и start point местам, и движение продолжается, но в обратную сторону. И всё идёт прекрасно, пока ты так не поиграешь 10, 30, 60 секунд. После этого начнётся сильнейший рассинхрон между играющей песней и скачущим мячом - каждый новый удар будет всё дальше удаляться от реального бита песни.

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

Тебе надо следить за позицией трека и считать, как много времени прошло с предыдущего бита. Время между битами - как расстояние между start point и end point. Delta between beats будет отображать позицию нашего мяча. Но это довольно странно ставить знак равно между временем (delta between beats) и координатой (позиция мяча). Понятнее будет перевести всё в доли- поделив delta between beats на time between beats мы получим процент между соседними битами. Этот процент будет таким же у мяча между начальной и конечной позицией.

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

Про проявление заиканий и решение.

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

Тут наступает ужасное - мяч летит отрывисто, заикается, как будто игра идёт в 15 фпс. Ты профайлишь игру, но все показатели в норме, да и остальные элементы игры, не зависящие от хода музыки, ведут себя адекватно. Может, мы рано решили избавиться от Delta time?

Ты начинаешь дебажить позицию песни каждый кадр - и что же ты видишь! Оказывается, позиция трека не обновляется покадрово, а скачет, как ей вздумается! Вместо того, чтобы в окне дебага видеть "0, 16, 33, 49, 65, 80..." (мс), показывается вот это "0, 0, 0, 48, 48, 65, 65, 65...". Аудиодвижок просто-напросто живёт своей жизнью и отказывается подчиняться обновлению каждый кадр (те кто работают в Гамаке знают, что если во время теста игры она у вас крашнется, то аудио продолжит работать в отрыве от картинки).

ПК, как известно, платформа помощнее, чем мобильные устройства, и эти фризы там не так заметны (хотя они есть, если знаешь, с чем сравнивать).

Что ж, значит нам придётся вручную "догонять" позицию трека, чтобы она плавно переходила от одного значения к следующему. Плавно... где-то я это слышал... delta time! Почему бы здесь нам не использовать нашего старого друга, ведь всё же мы будем увеличивать позицию искусственным путём.

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

Пример первый, неправильный. Давайте введём новую переменную для отслеживания позиции трека в предыдущем фрейма lastFrameTrackPosition. Тогда мы каждый кадр можем сравнивать нынешнюю позицию песни и её позицию на предыдущем кадре. Если они совпадают, значит положение песни "не прибавилось", и мы сделаем это сами. Если позиция трека так долго не обновлялась, что lastFrameTrackPositon убежала вперед, то мы сами её увеличим.

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

Можно вновь обвинить Delta time и сказать, что дело в нём, но это не так. Точнее, мы просто слегка неправильно его используем.

Давайте оставим переменную lastFrameTrackPosition и введём ещё одну - trackPositionContainer, которая поможет нам не изменять позицию трека напрямую через прибавку delta time, но с помощью постепенного приближения (известного как easing). Мы опять начнём со сравнения положения песни в текущий и предыдущий кадр. Делаем только одно сравнение - не равны ли они, и если они и правда отличаются, то мы приблизим значение trackPositionContainer к позиции трека с помощью среднего арифметического. И возвращать в качестве позиции песни для MoveBall() мы будем именно приблИженное значение контейнера, но не самой рваной позиции трека.

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

Теперь, наконец, гештальт закрыт. Я перерыл старый код, заново переписал игру, сделал порты на мобилки и сегодня выходит последний порт на Nintendo Switch. Надеюсь, было полезно и хоть немного интересно, ребятки. Оставлю ссылки на всевозможные сторы, если захотите посмотреть проект. Спасибо за прочтение!

Nintendo Switch: https://www.nintendo.ru/-/-Nintendo-Switch/Lofi-Ping-Pong-18...
App Store: https://apps.apple.com/app/id1539408060
Google Play: https://play.google.com/store/apps/details?id=com.Calvares.L...
Steam: https://store.steampowered.com/app/1028570/Lofi_Ping_Pong/

Год назад я писал статью про совою музыкальную игру, ее историю появления и принципы игры. Там, в конце статьи, я привел краткую статистику за 30 дней нахождения страницы игры в Steam и сделал вывод что люди не заинтересованы в игре с подобным геймплеем.
Сутью игры является упрощенная игра по нотам на пианино с помощью клавиатуры ПК. Игра использует упрощенную стандартную музыкальную нотацию, сгенерированную из MIDI-файлов. Ключевым словом здесь является слово "музыкальная нотация". Я думаю, что люди придя на страницу и увидев на скриншотах музыкальные ноты тут же спешат покинуть ее.

Где-то через месяц после публикации статьи игра вышла в Steam в раннем доступе. Как и ожидалось, чуда не случилось. За год игра была куплена всего 200 раз из них 30% были возвращены. После выхода игры, я продолжал работать над ней полтора месяца, добавляя новые функции и исправляя баги, найденные игроками. За это время я успел выпустить пару - тройку обновлений. Когда игра обрела какой-то полу промежуточный законченный вид я решил что ее нужно кардинально менять.

Режим игры с падающими нотами

Я решил добавить новый режим игры, отложив доработку старого. В нем, мне нужно было избавиться от музыкальных нот и сделать геймплей более интуитивно понятным. Единственное что пришло на ум из адекватного и реализуемого с моими навыками - это сделать нечто похожее на Synthesia. Изучив тему с падающими нотами, я нашел очень много игр с таким геймплеем (Vertical Scrolling Rhythm Games). Все они предоставляют ограниченный список песен и паттернов с нотами(сделанных вручную) к ним. Ноты двигаются вертикально и синхронизированы с песней. Нажатия нот совпадают с мелодией песни.

Новый режим должен был соответствовать смыслу всей игры - сделать возможным с помощью  клавиатуры ПК играть ЛЮБУЮ песню. Я, конечно же, не мог лицензировать все песни мира и сделать к ним паттерны. Выход был один - авто генерация паттернов из MIDI. Когда этот режим еще находился у меня в мыслях, я наивно полагал, что это будет совсем просто. Я планировал закончить его за пару месяцев. Как же я ошибался) Мне хотелось повторить в сгенерированных паттернах рисунок паттерна настоящего пианино. Повторить все движения рук, позиции нот друг относительно друга при том, что по сравнению с пианино у меня было ограниченное количество клавиш(4, 6, 8, 10) и там особо не разгуляешься.

Было очень трудно сделать генератор нот таким, каким я его хотел видеть. Можно было бы просто взять все ноты из МИДИ "напихать" в паттерн в случайном порядке как это делалось в прошлом режиме игры, но мой перфекционизм не давал мне покоя. Я перепробовал много алгоритмов, на одних видах песен ноты генерировались хорошо, а на других получалась каша из нот. Иногда мне казалось что это задача совсем не реализуема. И все таки, спустя 11 месяцев, мне кажется, что у меня что-то получилось: https://youtu.be/YOHOSLIO0Yc

В новом режиме можно сыграть любую(если учитывать как легко найти миди-файлы) песню с широкими возможностями настройки сложности:

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