О подводных камнях разработки пошаговой тактики и двухмерного шутера: интервью о серии SMASH BASH

Одним из главных сторонних проектов на базе Defold сегодня остается изометрический кооперативный шутер SMASH BASH: Date with the Desert, разрабатывающийся инди-студией Rising Wave. Об истории проекта, движках и сложностях при разработке пошаговой тактики и экшенов мы поговорили с продюсером проекта Ярославом Кравцовым.

Привет. Начну немного издалека. Тебя хорошо знают как ведущего левел-дизайнера MMO-проектов Mail.ru Group. Ты работал над “Аллодами Онлайн”, Skyforge и Armored Warfare. Это масштабные игры, совершенно не похожие на те, которыми ты занимаешься сегодня. Насколько вообще сильно отличается подход к дизайну в больших играх от подхода к дизайну в инди-продуктах?

Ярослав Кравцов

Привет! Основное отличие: на больших проектах больше дизайнерских задач. Если на маленьком инди-проекте все может держаться в голове одного дизайнера, то на больших играх нужно уметь распределять задачи между командой гейм-дизайнеров, а затем сводить результат в единый продукт. Тут очень легко потерять вижн игры и обрасти ненужными фичами.

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

Это прямым образом отражается на работе дизайнеров. Становится необходимо смотреть на маркетинговые исследования, метрики аналитики, проводить А/Б-тесты и, скорее всего, работать с фритуплей-монетизацией. Тут не сложно дойти до мысли, что игра – это средство монетизации трафика. Обычно на этом моменте дизайнер подписывает контракт о продаже души и открывает бутылку дорогущего виски.

История со SMASH BASH началась в феврале 2016 года. Тогда речь шла о разработке пошаговой тактики на Unity в рамках Games Jam Kanobu. Игра задумывалась как Advance Wars в сеттинге Первой Мировой войны. Со стороны казалось все просто: взять механику, нарисовать свою графику. Где возникли подводные камни?

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

Первый прототип SMASH BASH

Но надо было двигаться дальше. Игра у нас выглядела очень дженерик и по скриншотам почти не отличалась от референсной игры. Мы решили сделать арт более сложным: увеличили разрешение, сделали реалистичные пропорции, добавили больше деталей, связанных с эпохой Первой мировой.

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

Пример, на котором выбирали арт-стиль SMASH BASH

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

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

Новая версия графики SMASH BASH

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

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

Почему вообще остановились именно на пиксель-арте?

С пиксель-артом все просто. Разработка игры началась с того, что я написал страницу текста и приложил скриншот из Advance Wars, как референс. Этого хватило, чтобы люди начали приходить и говорить, что хотят делать эту игру вместе со мной. В том числе пришел Евгений Юдин, известный в инди-кругах пиксель-артист. У него очень интересный подход к пиксель-арту, который делает картинку уникальной, отличающейся от тысяч других пиксель-арт игр. Так что это не я выбрал наш арт-стиль, а арт-стиль выбрал нашу игру.

И хотя основы стиля устаканились до перехода на SMASH BASH: Date with the Desert, но сама картинка значительно изменилась с того времени. Мы постоянно ищем пути как сделать ее более привлекательной. Чтобы было интересно смотреть на происходящее на экране в любой момент игры. Нам в этом помогает участие на шоукейсах на конференциях. Мы смотрим как люди реагируют на нашу игру и делаем выводы. Также используем социальные сети, где размещаем фрагменты геймплея, и смотрим на реакцию. Если что-то было встречено прохладно, то меняем и снова проверяем реакцию.

А еще у нас команда любит сложные вызовы. Однажды в чате разработки появилась ссылка на то, как сделан 3D-режим в Diablo 2. Оффтоп. Но спустя несколько дней программист, Виктор Смирнов, выложил в чат гифку, где показал как этот режим работает в нашей игре. И мы заорали!

SMASH BASH: Date with the Desert

Продолжая разговор об арте. Актуально ли сегодня, говоря об пиксель-арте, утверждать, что этот подход к графике в производстве менее трудозатратен (а значит и дешевле), чем, например, работа со спрайтами, выполненными в другом стиле, или работа с 3D? Иными словами, этот подход у инди до сих пор популярен из-за дешевизны или по каким-либо другим причинам?

Я бы тут предпочел сослаться на доклад нашего художника, когда он на конференции DevGAMM очень развернуто отвечал на этот вопрос. Но если кратко, то пиксель-арт бывает разный. Хороший пискель-арт аналогичен по сложности с работой в других стилях и 3D. Если разработчик хочет сделать что-то большее, чем тяп-ляп поделку, то ему стоит трижды подумать, прежде чем выбирать пиксель-арт. Он накладывает много ограничений, которых нет при работе с обычным 2D артом.

После завершения работы над Date with the Desert вы планируете заканчивать SMASH BASH в том же стиле?

Думаю, к тому времени, когда мы закончим Date with the Desert, мы много нового узнаем про наши возможности и это поможет принять нам правильные решения. В том числе о том, какой проект нам лучше делать следующим. Я уже говорил, что с тактикой есть ряд серьезных геймплейных проблем. С другой стороны, очень хочется показать ту самую мировую войну, ради которой возник весь этот сеттинг из стимпанка, дизельпанка, теслапанка и химпанка. И через альтернативную историю еще раз показать ужасы той войны, что была сто лет назад, но оказалась в тени Второй мировой. Такие события не должны забываться.

Как получилось, что в ходе работы над пошаговой тактикой вы взялись за создание экшена – SMASH BASH: Date with the Desert?

В какой-то момент наш художник, Евгений Юдин, посмотрел трейлер фильма про Чудо-женщину, действие которого также происходит в эпоху Первой мировой войны. Он сделал концепт персонажа и для примера вставил на локацию SMASH BASH. Как только мы увидели персонажа с мечом, то сразу в голове сложилась картинка динамичной игры, где мы управляем одним персонажем, бегаем по карте и косим врагов пачками. При этом используя те ассеты, что уже сделаны.

Как раз подошло время очередного Ludum Dare и мы решили в порядке эксперимента воплотить эту идею в виде небольшой игры, сделанной за три дня. Это не месяцы экспериментов, так что можно было рискнуть. Заодно повод попробовать движок Defold в боевых условиях. Мы вокруг него ходили кругами долго, но все никак не могли определиться со своим отношениям к нему. Туториалы делать, конечно, хорошая тема, но для однозначных выводов нужно решить на движке настоящие боевые задачи. В результате сделали вот эту игру.

SMASH BASH: Sukhov vs Zombies

Нам результат понравился и мы решили продолжить. К тому же эта игра снимала те проблемы, которые мы не знали как решить в тактике:

• Как сделать игру пригодной для стримеров-ютуберов (зрители умрут от скуки, наблюдая, как стример думает над очередным ходом, ведь в это время на экране ничего не происходит)?
• Как сделать короткие игровые сессии (в референсной Advance Wars на уровень можно было потратить 20-30 минут на прохождение, что совсем не вяжется с современными требованиями к длительности сессии на мобильных устройствах)?
• Как сделать игру пригодной для фритуплей-монетизации? Геймплей тактики подразумевает отсутствие рандома и влияния прогрессии. Это как шахматы, где ты можешь продумывать на несколько ходов вперед, потому что гарантировано пешка вынесет слона за одну атаку, а не за 2-4. Но мобильный рынок очень недружелюбен к платным играм, если они не всемирно известные хиты. Поэтому не хочется заранее связывать себе руки, делая игру, которая заведомо может не окупиться.

Но последней каплей, которая отложила тактику SMASH BASH на полку, стал выход других игр в жанре “ностальгия по Advance Wars”. Как минимум, это Warbits и Lost Frontier. Обе игры сделаны очень качественно, но, по оценкам, у них довольно скромные результаты продаж. Также можно отметить провал кикстартера Tiny Metal. Все это наводит на мысли, что идея сделать тактику не настолько хорошая, как казалось вначале.

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

Кстати, учитывая не самую хорошую историю с двумерной графикой для Unity, почему, когда начинали делать оригинальный SMASH BASH, остановились именно на нем, а не, к примеру, на заточенном под 2D GameMaker?

У меня был опыт работы с GameMaker, даже одна выпущенная игра под Android. Ссылку не дам – мне за нее стыдно. Опыт работы на GameMaker показал мне, что движок имеет очень низкий потолок, в который быстро упираешься, когда хочешь сделать что-то сложней прототипа платформера.

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

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

Хотя к Unity тоже были нарекания по поводу 2D-графики, но портфолио выпущенных игр на этом движке успокаивало. Если другие смогли, то и мы сможем. А если не сможем, то знаем, кого спросить.

SMASH BASH

SMASH BASH: Date with the Desert создается на Defold. Уверен, переход на новый движок прошел не безболезненно. На что злились и к чему привыкали первое время при работе с Defold? И к чему стоит готовиться тем разработчикам, которые переходят на него с того же Unity (и вообще им стоит переходить)?

Да, переход не был безболезненным. Особенно поначалу, еще до эксперимента на Ludum Dare, когда мы пробовали перенести на Defold геймплей тактики. Попытка сделать на движке сразу что-то сложное, когда по нему еще так мало информации, было проблемой. Создавать игру с нуля оказалось проще, так как мы ее усложняем маленькими шажками, каждый из которых понятно как сделать.

Не думаю, что разработчикам, у которых уже есть проект на Unity, стоит думать о смене движка. Смена движка во время разработки – это всегда очень-очень негативный шаг, на который стоит идти только в крайнем случае. Мы перешли на Defold, потому что начали новый проект. Если бы продолжили делать тактику, то, скорее всего, поэкспериментировали бы немного с Defold, чтобы оценить новинку на рынке, но продолжили бы разработку на Unity.

Между движками нет какой-то совсем уж принципиальной разницы, ради которой стоит мигрировать и рисковать проектом. Оба движка хорошо подходят для 2D-игр. У Unity большое комьюнити и много готовых решений, у Defold выше скорость и меньше размер приложений, что важно для мобильной разработки.

Если же разработчики решили начать новый проект на Defold, то я советовал бы первым делом приобщаться к комьюнити разработчиков на этом движке: заглянуть на форум движка, slack-чат и группу в ВК. На данном этапе развития движка проще спросить коллег, чем пытаться найти ответ самостоятельно.

Отличная возможность минимизировать риски – начать проект на новом курсе по созданию игр на Defold, который с января начинается в Scream School. Это не будет набор нудных лекций с экзаменом в конце, как это принято в классическом обучении. Вместо этого будет длительный воркшоп, на котором поэтапно будут разобраны основные элементы создания игр на Defold, а студенты будут делать не учебный стандартный проект, а воплощать свои собственные идеи. Вести курс буду я и Виктор Смирнов, наш программист. Для меня это уже не знаю какой по счету освоенный движок да и хватает опыта разработки игр любого калибра. А Витя настолько освоил недра Defold, что уже сделал VR поддержку для нашей игры. С тех пор мы перестали шутить, что в Defold чего-то нет.

SMASH BASH: Date with the Desert

С какими неожиданностями при разработке Date with the Desert столкнулись? И, в целом, можешь рассказать, к чему стоит готовиться команде, которая решила запилить свой первый проект именно как изометрический шутер?

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

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

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

И последний вопрос: когда ждать игры?

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

Успехов! Спасибо за интервью!