Lost in Sky: (де)конструкция современного платформера

Всем привет! Мы — команда экшен-платформера Lost in Sky, релиз которого запланирован на вторую половину 2019-го. Платформеры — классика, но чтобы новая игра в жанре выглядела современно и круто, мы проходим длинный и сложный путь. Начали разработку в 2017-м в Кишинёве, в начале 2018-го к команде присоединился гейм-дизайнер из Киева.

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

Ещё в начале разработки мы решили предложить современному рынку платформеров нечто уникальное, что не так-то просто — платформеров выходит очень и очень много, и многие из них — очень качественны. Итак, Lost in Sky — это dark sci-fi slasher с возможностью переключения между персонажами и прицелом на кооп. Попробуем разобрать эту формулу.

Core: поиск референсов

Изначальными рефами для нас были старые добрые харкдорные платформеры 90-х: серия Contra и Lost Vikings, а также её наследник Trine (2009). На начальном этапе (2017 год) чёткого видения продукта не было, в ход шли любимые игры детства — от Battletoads до Another World. Постепенно, путём прототипирования и отсева стало формироваться видение проекта. От серии Contra игра взяла фокус на экшен: у нас практически нет секций чистого платформинга в духе Super Meat Boy. От Lost Vikings мы взяли переключение между персонажами с разными навыками.

Но это было только начало.

От Run’n’Gun — к современным souls-like платформерам

В какой-то момент стало ясно, что боевые механики персонажей — стрельба из лука и удары мечника — плохо сочетаются с механикой и темпом Run’n’Gun. В Run’n’Gun всё заточено под постоянную пальбу из огнестрельного оружия, поэтому игроку даётся максимум контроля в движении и стрельбе. В нашем же случае. постоянное и ничем не ограниченное движение не даёт пауз и нивелирует тайминги. Кроме того, анимации выглядели плохо — просто потому, что приходилось сочетать их с бегом, и персонаж не мог "вложиться" всем телом. В результате, игрок не получал удовольствия от ударов и выстрелов. Тогда мы приняли решение вооружиться рефами в виде современных souls-like платформеров типа Salt and Sanctuary, Dead Cells, Sundered и даже Hollow Knight.

Было:

Стало:

Были переработаны все анимации, заблокирован бег во время удара (для удобства мечник по-прежнему немного движется всем телом вперёд при ударе, планируем немного сгладить эффект скольжения при помощи VFX пыли), произведён ребаланс стамины (быстро кончается, но очень быстро восстанавливается). При этом мы старались сделать боёвку максимально отзывчивой и динамичной, поощряя игрока действовать агрессивно, как бы в последний момент.

Было:

Стало:

UI/UX

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

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

Но ещё одна проблема требовала решения. Игроки на плейтестах не могли понять — почему действия персонажа в какой-то момент просто блокируются? Они просто не замечали полоски стамины, ютящейся в левом верхнем углу. Если взглянуть на референсы, стамина в платформерах используется довольно редко, это, скорее, дань "классической" souls-like боевой системе (как в Salt and Sanctuary или Dark Devotion). 

Радикальные решения тоже были не вариантом: убирать стамину не имело смысла (тогда это пришлось бы комплексно компенсировать поведением и количеством мобов, которые к тому времени уже были реализованы), поставить её вниз экрана — тоже (локальный кооператив предполагает отзеркаливание GUI). Мы пришли к следующим решениям: на израсходовании дополнить стамину миганиями полоски, добавить эффект белой "виньетки" по краям экрана, а также поставить на полоске визуальный ограничитель, предупреждающий игрока о скором окончании ресурса (всё это видно на скриншоте ниже). Другими важными решениями были увеличение масштаба GUI и посвящение стамине отдельного раздела в туториале.

Режим ярости

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

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

Платформеры и нарратив

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

Но вскоре возник вечный вопрос — нужен ли платформерам нарратив? Ответ мы сформулировали так: нужен в той мере, в которой он не отбирает у игрока контроль. Редкие катсцены — ОК (если есть на то ресурс), диалоги на весь экран у нас ещё есть, но мы стремимся свести их к минимуму. Но лучшие нарративные средства платформеров — баблы, выдаваемые персонажами как в обусловленных сюжетом местах, так и процедурно, в определённых ситуациях кор геймплея.

Последнее довольно редко делают в платформерах. Классика жанра — молчаливый одинокий персонаж. Но мы решили, что наша игра — про кооперацию и боевое товарищество, так что крик победы, подначивание партнёра или боевой клич сделают геймплей только лучше и живей. 

Визуальный стиль и сеттинг

...тоже претерпел изменения по ходу разработки. Начинали мы с более классического (и довольно светлого) retro-future, а закончили, вступая на территорию dark sci-fi или даже space horror.

Среди основных визуальных рефов наш художник выделил следующие:

1. Metroid Fusion (2002) как основа атмосферы космического корабля.
2. Комиксовая стилистика рисовки Comix Zone (1995).
3. Графика художника-футуриста Syd Mead.

Хоррор буквально "просился" к происходящему на экране. Жуткие органические монстры — резкий визуальный контраст стерильным отсекам космического корабля-планеты — должны были вылупляться из коконов. А где коконы — там и огромные гнездилища в духе гигеровских ксеноморфов (Alien), или колоний некроморфов из Dead Space.

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

Дизайн уровней

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

(Не)Линейность

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

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

2. Подлокации и секреты, дающие ощущение глубины — в глубинах мира скрываются целые уровни.

3. Квесты и диалоговые ивенты по мере прохождения уровней (жители Города, а также сами герои могли рассказать что-то интересное о своём доме).

4. Классическое повествование через окружение ("Куда ведёт эта кровавая полоса на полу?")

Система чекпоинтов

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

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

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

Камера

Основной критерий хорошей камеры прост — не мешать. Она должна быть отзывчивой и мягкой, где нужно — сглаживать резкие движения персонажа, в других ситуациях — акцентированно трястись, усиляя впечатление от критического момента. Для дизайна уровней камера важна тем, что она помогает акцентировать масштаб происходящего. Крупный зум замыкает игрока в узком, давящем, душном тоннеле, малый — превращает персонажа в песчинку, а поражённые мутантами небоскрёбы Города — в развороченный муравейник.

Параллакс

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

Монстры: проблемы логики поведения

Формула идеального монстра

Постепенно мы выработали своего рода формулу идеального монстра.

1. Он должен быть визуально выразительным (красивым / гротескным / жутким).
2. У него должны быть ЧИТАЕМЫЕ подготовки атак. Лучше делать монстра чуть быстрей, но не жертвовать при этом скоростью и выразительностью анимации подготовки.
3. Он не должен быть слишком умным, потому что уместное применение в связке с другими типами монстров будет играть большую роль для игрока. Лучше потратьте человекочасы программиста на поведение нескольких простых, но хорошо сочетаемых монстров, чем делайте одного сложного универсала (если это не босс, конечно).
4. Он должен быть одиночным (об этом чуть позже).
5. Монстр должен быть интересен для нашего парного геймплея и сочетания способностей разных персонажей. К примеру, лучнице лучше удаётся убивать летунов или плюющихся пауков, а мечнику — прытких наземных скорпионов.

Не делайте бойды!

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

В чём же проблема бойдов?

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

В итоге нам всё-таки удалось победить эту проблему, создав что-то типа бойда-единого тела (скученный, цельный рой), поощряя при этом игрока к тому, чтобы убивать много врагов за один удар или выстрел.

Было:

Стало:

Персонажи и кооперация

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

Бот (ключевая проблема сингла)

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

Поэтому нашим программистам пришлось писать логику поведения для бота. 

Это включало:

1. Создание схемы навигаций на уровнях (должна быть возможность оставить и позвать бота, когда будет необходимо — и он должен уметь пройти через все лабиринты).
2. Логику поведения в бою. Бот должен уметь отбиваться от врагов, и даже помогать игроку, при этом используя большинство арсенала атак. Мы реализовали это максимально просто, сделав несколько зон-радиусов, в которых бот переключает свои состояния (атака, силовая атака, отступление и т.д.) 
3. Логику взаимодействия с окружением (лифты и прочие динамические объекты, меняющие состояние).
4. Логику взаимодействия врагов с ботом. Они не должны видеть друг друга из-за границы камеры, плюс — монстры всегда в приоритете выбирают как цель персонажа, а не бота (иначе мы накажем игрока за событие вне поля его прямого контроля).

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

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

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

Кооп и левел-дизайн

В плане левел-дизайна существует два основных типа решений в отношении коопа:

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

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

Боссы

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

Изначально при создании боссов мы обратились к референсам из наших любимых игр — например, Босс-Дерево имеет отдалённое сходство с Tree of Men из Salt and Sanctuary и Dark-Rotten Greatwood из Dark Souls 3. Многоуровневый босс отлично вписывается в геймплей нашего платформера, но чтобы по-настоящему встроить его в игровой мир мы завязали битву на кооперативе — крайне трудно будет успеть выбить глаз босса в одиночку. Босс постоянно меняет фазы, то открывает, то закрывает глаза, и параллельно атакует персонажа множеством различных атак.

Локальный кооператив и сеть

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

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

Будущее покажет, какие же челленджи ждут нас на пути к этой вершине!