Дизайн мувсета на примере Celeste. Самое мясо

Является прямым продолжением этой статьи. Без её прочтения может быть тяжело)

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

Основатель студии, сделавшей Celeste, говорил, что студия была собрана из людей, которые всю карьеру до того делали сайд скроллеры. И что концепция Celeste родилась из уверенности в своих силах сделать офигенный прыжок. А Celeste на 99% состоит из разных прыжков.

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

Приведём очень реалистичный пример. Вы гейм дизайнер, который не только впервые реализует мувсет для сайд скроллера, но и код воспринимает как древнюю шумерскую клинопись. Что и как вам надо объяснить программисту, чтобы мувсет заработал корректно?

Итерации

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

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

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

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

...думаю, вам уже понятно, что в подходе выше не достаёт важной детали.

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

Публичные переменные

Начать надо с настройки окружения. Рассмотрим на примере движка Unity.

Любая переменная, объявленная как public, будет видна прям в свойствах объекта в редакторе движка.

Пример объявления публичной переменной в Unity

Пример: переменная int livesNumber обознает количество жизней у персонажа в сайд скроллере. Мы — гейм дизайнер, и {у нас лапки} мы не знаем, где эту переменную искать в коде, и как вообще она называется.

Мы просим программиста объявить её как public int livesNumber, и теперь эта переменная видна нам прям в свойствах нашего персонажа с полем для ввода, куда мы можем написать что вздумается.

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

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

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

Декомпозиция дизайна (и самая суть этой дилогии статей)

Итак, какие именно переменные должны создать и вынести в свойства программисты, чтобы мы могли успешно итерировать наш мувсет?

||   ~   Бег   ~   ||

В Celeste с бегом всё относительно просто. Его можно отрегулировать 3мя переменными. Это:

Но это уже итоговая концепция, попавшая в игру. Что бы нам ещё могло пригодиться при тестировании бега?

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

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

||   ~   Глобальная физика   ~   ||

Всё указывает на то, что в Celeste используется физика. Поэтому будем рассматривать только вариант с приложением силы к персонажу, а остальные отметём.

Мы уже описали бег и готовимся описать прыжок. И уже понятно, что не хватает какой-то общей базы.

Если мы используем внутриигровую физику, нам нужно её глобально отрегулировать.

Для этого нам понадобятся переменные для:

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

||   ~   Прыжок   ~   ||

С прыжком возможны многочисленные вариации, поэтому тут особенно высок шанс ошибиться в анализе. Заранее простим себя за это🙂

В отличие от экшенов от 3го лица, где движение может считываться со стика или мышки по очень большому количеству направлений (бежим прямо, но при этом чуть-чуть налево); в Celeste инпут считывается по 8 осям. Это вверх-вниз-вправо-влево и оси под 45°.

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

Поэтому для прыжка с земли нас интересуют только направления вверх, вправо и вверх+вправо. Левые направления будут работать аналогично. И да, для прыжка вертикально вверх саму клавишу W нажимать не обязательно.

В теории авторы могли бы сделать прям 3 разных прыжка для каждого из трёх направлений. Но в Celeste этот момент сделан прямолинейно; во всех трёх случаях к персонажу прикладывается одинаковая сила вверх.

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

Итого мы имеем набор переменных:

||   ~   Дэш в воздухе   ~   ||

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

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

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

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

||     ~    Зацеп за стену и ползание по ней   ~   ||

Тут всё ± просто:

И последнее!

||   ~   Прыжок от стены    ~   ||

БОльшую часть свойств мы наследуем от обычного прыжка. Кроме двух:

Ну вот и всё!

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

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

Если вы до сюда дочитали — вот вам приз за отвагу:

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