Как мы дошли от идеи «Конфетный кнут» до игры DJ Whip VR

Опыт разработки без дизайн-документа.

Всем привет! Мы GameTrek, небольшая почти инди-студия из Москвы. Мы разрабатываем игры на заказ и делаем бизнес-игры. Этим летом у нас было затишье с проектами, и мы решили попробовать сделать и выпустить игру. И начать мы решили ни много ни мало с VR-проекта.

Мы выпустили игру на Steam в ноябре и написали эту статью, чтобы поделиться своим алгоритмом и процессом, который мы использовали в процессе работы над игрой DJ Whip VR.

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

В этой статье мы рассказываем:

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

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

Ограничение 1: Технология и платформа

Мы знали только, что хотели сделать VR-игру. Обоснования тут было два:

Ограничение 2: Бюджет

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

В результате мы сделали проект за три месяца, при этом подключив на некоторое время и художника и 3D-моделлера.

Это в очередной раз доказывает формулу, которая была выведена нами ранее в предыдущих проектах. Если у тебя есть оценка проекта в деньгах и людях, то смело умножай её на Pi! Это и будут твои реальные затраты на проект. Удивительно, но магическое число Pi работает и тут.

Ограничение 3: Выбор жанра

Для того, чтобы выбрать направление, мы стали использовать SteamSpy и данные о продажах. Да, мы знаем, что сейчас SteamSpy работает неправильно, но в нём есть исторические данные. Кроме того, он одинаково неправильно работает по всем играм. Это значит, что если сравнить два неправильных результата можно увидеть похожую на правду сравнительную оценку объёмов продаж.

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

При этом игры симуляторы реальности (спортивных игр, профессии, например, лётчика) продавались хуже чем игры, в которых воссоздается опыт игрока невозможный в жизни. Другими словами, игрокам не интересно в VR пережить то, что можно пережить в жизни.

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

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

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

И ещё был класс аркады. У этих играх достаточно ровные продажи, нет супердорогих красивых миров, много движухи и упор на механиках.

С учётом нашего предыдущего ограничения по бюджету мы решили выбрать именно аркады.

Ограничение 4: референсы и механики

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

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

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

Техника: ключевые вопросы (название сами придумали)

На листах флипчарта мы написали вопросы:

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

Техника: комбинирование

Далее методом перебора мы брали два ответа из разных вопросов и говорили:

Получившиеся идеи весело обсуждали, фиксировали их и переходили к следующей комбинации.

Техника: отсеивание или улучшение

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

Мы решили делать игру, в которой главное это «оружие», при помощи которого игрок играет. Мы стали делать игру про кнут. Референсом в этот момент был Fruit Ninja. Нам казался интересным выбор кнута в качестве оружия, да и на первый взгляд игр с кнутом не было.

Вот, что у нас получилось в этот момент.

Правда, мало общего с игрой про диджея с кнутом в руках?

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

Технологический прототип и снятие рисков

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

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

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

Что такое кнут? Если просто — набор последовательно соединенных сегментов, и первый сегмент присоединен к контроллеру игрока.

Так мы и сделали. Соединили между собой 20 капсул одинаковой массы — и вот у нас уже есть связка сосисок.

После этого мы попробовали помахать таким «кнутом» и наткнулись на первую проблему: все сегменты хаотично перемещались относительно друг друга, и выглядело это скорее как ураган, а не кнут. При этом никакие изменения параметров Joint не помогали этого избежать.

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

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

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

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

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

Прототипируем геймплей

Поняв, что технологические риски сняты мы принялись за геймплей.

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

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

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

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

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

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

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

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

Такие плейтесты мы повторяли еще несколько раз.

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

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

Финализируем механики

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

Ещё с предыдущих этапов у нас был готов чеклист механик, которые мы хотели бы видеть в игре. Из них мы начали собирать игру.

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

Из игры Elven Assassin мы взяли идею tower defence. В качестве крепости выступает сам игрок. На него летят объекты и нападают волнами, нужно отбиться от волны. Волны идут с нарастанием сложности. При этом нужно продержаться дольше и набрать больше очков.

Далее мы смотрели на игру Space Pirate Trainer. Оттуда мы взяли идею, что может быть несколько игровых режимов, идею что объекты могут стрелять и перемещаться и что у игрока есть щит. Также там нравилась идея уклонения от выстрелов. Именно благодаря ей появилась механика лучей которые пробивают щит и единственный способ борьбы с ними это уклонение.

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

Уровни сложности

Игра, как нам казалось тогда, и сейчас попадает под определение «Easy to play, hard to mastery». То есть для того, чтобы начать играть, можно просто махать кнутом, однако чтобы научиться это делать точно и быстро нужно потратить некоторое время на оттачивание навыков.

Это же означало, что нужно награждать игрока за то, что он играет технически правильно. Мы стали давать больше очков за точное разрезание и за комбо из нескольких объектов.

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

Смена локаций

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

Идею туннеля и объектов, которые летят на игрока, мы позаимствовали в Beat Saber. Оттуда же позаимствовали бомбы и стены, от которых нужно отходить. В итоге мы сделали стены из бомб от которых можно увернуться, разрубить кнутом или ударить щитом.

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

Балансировка

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

Цель игры

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

Идею «конфетного геймплея» к этому моменту уже не вспоминали. Хотели сделать игру в космосе, но казалось, что придётся делать врагов живыми. Однако попробовали сделать космический концепт арт. Он же впоследствии лег в основу общего визуального стиля игры.

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

Мы начали размышлять как можно сделать ритм-игру и пришла идея. Если игрок не может играть в ритме, что если весь мир игры и все объекты живут в ритме музыки?

Генератор музыки

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

Мы написали движок, который рассылает сигналы соответствующие битам в музыке.

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

Следующая идея была следствием предыдущей. В цифровой музыке есть понятия семплов и лупов различных инструментов. И мы сказали: «А что, если мы будем комбинировать лупы барабанов, синтезатора и баса и пусть объекты двигаются, пульсируют и стреляют под музыку, которая звучит».

Далее нам показалось интересной идея, что если у нас будет много лупов разных инструментов, то музыка может комбинироваться на лету. В этот момент игра стала называться DJ Whip VR, в которой игрок — это DJ на танцполе, и он рубит музыкальные объекты и из этого сводит музыку.

Это было где-то за месяц до релиза и вот только в этот момент мы поняли, что за игру мы делаем.

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

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

Режимы игры

В итоге мы сделали четыре игровых режима.

В музыкальном режиме вокруг игрока летают объекты, обозначающие определённый инструмент. Это ударные, синты, бас, отдельная бочка, перкуссионные и вокал. Если объект разрубить, то он начнет звучать. Причем он включается в нужный такт, звучит определённую длительность и замолкает. Для того, чтобы продлить или повторно включить инструмент его нужно разрубить повторно.

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

В аркадном режиме есть летящие и стреляющие объекты, игрока пытаются убить и нужно стараться выжить.

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

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

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

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

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

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

Во-первых, мы выпустили туман. Рассматривали два возможных варианта: сделать его партиклами или использовать объёмный (Volumetric) туман.

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

Затем решили попробовать сделать объёмный туман. Использовали ассет AURA, он оказался очень удобным и простым в использовании. Сначала пустили туман равномерной плотности в надежде, что этого будет достаточно. Оказалось, что с таким туманом всё выглядит мутно и начинают болеть глаза. Затем использовали шум, чтобы сделать разную плотность в разных местах тумана, и добавили туману движения — так получилась гораздо более приятная картинка.

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

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

Все это сделало картинку поинтереснее.

Выводы, которые мы получили: