Как сделать хороший платформер

Не так давно, только начав изучать «платформеры», мои коллеги нашли прекрасные советы по работе с этим жанром от Скотта Роджерса (приложившего руку к появлению таких проектов, как God of War, Maximo series, Pac-man World, Dawn to Life series, Darksiders), а вскоре — и их перевод на русский язык. Оглядываясь на эти советы сквозь призму трех месяцев изучения самых разнообразных проектов этого жанра, мои коллеги сочли возможным дополнить эти советы. Буду рад, если и Вы, дорогой мой читатель, сможете добавить что-то свое. 

1.  Базовые механики

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

2. Персонаж и позиционирование

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

3. Управление

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

4. Прыжки

• Платформы, на которые игрок может встать и любые другие фоновые элементы, должны четко друг от друга отличаться — игрок должен ясно видеть и понимать, что вот сюда он может встать, а сюда нет.
• При проектировании нужно обдумать или предусмотреть возможность отпрыгивать от стен, прыгать с одной стены на другую. Это расширит возможности для дизайна уровней.
• Герой должен прыгать на максимальную высоту только при зажатии кнопки (длинный тап).
• Отличное решение для упрощения прыжков по микроскопическим платформам — автоматическое притягивание и прилипание персонажа к ним.

5. Подвижные платформы

• Использовать группы платформ, движущихся с разным ритмом, можно на уровнях класса “Эксперт”. При этом неожиданных изменений скорости каждой конкретной платформы стоит избегать на любом уровне сложности.
• В качестве дополнительного челленджа можно вводить особые типы платформ, которые реагируют на персонажа — продавливаются вниз под его весом, пружинят, наклоняются и т.д.

6. Организация препятствий

• Если перед игроком пропасть и не видно, что происходит за экраном, игрок должен четко понимать — умрет ли он при падении (потеряет жизнь) или внизу что-то есть и туда вполне можно спрыгнуть (это необходимо визуально показывать игроку).
• Следует делать границы уровня логически обоснованными: границей не должна быть дорожка, прегражденная невидимой стеной, зато вполне может быть препятствие в виде скалистого уступа, на который невозможно забраться.

7. Падение

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

8. Движение

• Лечение (распитие банки) может происходить не мгновенно. Это нормально, если подкрепляется другими базовыми механиками — отпрыгиванием, ускорением, щитом и другими, которые не имеют смысла в случае с мгновенным исцелением.
• Транспорт необязательно именно ускоряет персонажа — он может служить для усиления игрока (дополнительная броня, урон).
• Механика ходьбы — не нужна вовсе, если уровень не предполагает ее использование. Иначе это будет затрата человеко-часов программистов и аниматоров.

9. Экран

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

10. Секреты

• 2D мир вовсе не обязательно воспринимается менее реальным и более плоским. Если окружение (объекты) качественно выполенно в 3Д, с динамичной камерой, то плоский по движению мир вполне себе воспринимается как трехмерный..
• Сопоставление характеристик для 2D и 2,5D необоснованно и не может быть применимо в 100% случаев. Все зависит от конкретного проекта. Например, и в 2D проекте желательно отрисовать вид персонажа со спины (когда забирается по лестнице); также вовсе не обязательно в 2D игроку будет легче найти секретку, чем в 2,5D — все зависит от базовых механик и сложности дизайна уровня.
• Хороший вариант, когда активное использование базовых механик приводит к нахождению секреток. Например, если при обучении игрока лазить по стенам и потолкам, и там закладывать секреты и бонусы, то потом игрок будет пытается делать это чуть ли не везде (и с высокой вероятностью находит спрятанные сундуки).
• При размещении секретов, равно как и видимых труднодоступных объектов с лутом, необходимо соразмерять баланс между трудностью доступа и вознаграждением.

11. Темы уровней

• Выбор темы для уровней ограничивается лишь фантазией разработчиков и сеттингом самой игры.

12. История уровня

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

13. Сосиски

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

14. Чекпоинты

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

15. Атаки/бой

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

16. Наказание и штрафы

• В этом разделе нам оказалось нечего добавить к указанным пунктам.

17. Набор механик

• Подкаты/кувырки (для проникновения в “низкие” проходы, для сбивания противников).
• Отталкивание от стен.
• Смена персонажей с разными возможностями и их комбинирование в процессе геймплея для прохождения разного рода препятствий.
• Появление у персонажа различных устройств или предметов, которые помогают проходить ранее недоступные препятствия (открывается возможность использования одних и тех же уровней и доступ к новым участкам этих уровней с появлением у персонажа новых механик).
• Изменение гравитации (построение уровня на этом).
• Изменение камеры в уровне — переход в другое измерение или под другой угол.
• Перед началом проектирования уровней нужно определить полный (и по возможности конечный) набор доступных игроку механик (прыжки, стрельба, использование платформ, лестниц и веревок);

18. Тернистый путь игрока

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

19. Виды врагов

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

20. Сражения

• Постоянное прибывание/возвращение врагов где-то может быть оправданным, а где-то — неожиданным и раздражающим (где-то моб — это только опасность, и использовать его для решения каких-то задач не нужно, а повторные появления таких мобов просто усложняют процесс и лишают игрока ощущения “зачистки уровня”).
• Игрок не обязан сражаться с мобами, избегание боя — это тоже способ прохождения уровня. Заставлять игрока что-то делать силой не правильно.

21. Правило трех

• 3 новых врага на каждый новый уровень — СЛИШКОМ много. Во-первых, это огромные объемы разрабатываемого и внедряемого контента, а во-вторых, игрок не будет успевать привыкать к противникам и препятствиям. Разнообразие это хорошо, но в меру.

22. Виды движений

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

23. Скорость игры (дополнительный пункт)

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

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

24. Обучение игроков (дополнительный пункт)

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

25. Размер видимой области (дополнительный пункт)

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

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