Проверка концепта игры минимальными средствами

Как изучать референсы и создавать прототипы из подручных средств — третья статья из цикла о геймдизайне.

Автор: Иван Звонарёв. Учился на программиста, но решил стать геймдизайнером. Пришел в Pixonic как специалист по балансу, также занимается другими задачами на проектах компании в качестве геймдизайнера.

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

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

Геймдизайнер Mortal Kombat 9 и God of War Майк Биркхед (Mike Birkhead) в одной из своих статей написал: «A game designer should have GRIP». Можно перевести как: «У геймдизайнера должна быть хватка», но на самом деле аббревиатура GRIP описывает процесс итеративной разработки: Goals, Research, Implement, Polish. То есть «Цель, Исследование, Реализация, Улучшение».

Как мы уже говорили в предыдущих материалах цикла, на самом раннем этапе идея игры описывается одним предложением. Но в разработке такой подход уже не сработает. Мало сказать: «Я делаю шутер про гигантских шагающих роботов», надо представить игру в деталях: насколько роботы технологичны, как они будут двигаться, как стрелять, как получать повреждения, кем управляет игрок — роботом или пилотом?

Возьмем Titanfall 2. Это шутер про высокотехнологичных роботов с высокой мобильностью, одним основным оружием (как в большинстве шутеров), классической механикой со здоровьем и аптечками. Каждый этот пункт отличает его от, скажем, MechWarrior, где роботы медленные, у них много оружия, а повреждения получает не вся машина, а её отдельные модули. Плюс, в Titanfall 2 пилот может выйти из робота — тогда в дело вступают совсем другие механики вроде бега по стенам и двойного прыжка.

Детальное понимание того, из каких элементов состоит игра, позволит четко сформулировать цели для разработки прототипов. Алгоритм тут следующий:

1. Разбейте свой концепт на отдельные независимые темы и механики.
2. Представьте, какие ощущения они должны вызывать («опасно», «трогательно», «драйвово»). Это будут ваши цели.
3. Каждой теме и механике назначьте приоритет — что является основой, а что вишенкой на торте.
4. Приступайте к исследованию в порядке приоритетов.

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

• Из каких элементов она состоит?
• Как игра реагирует на взаимодействие игрока и этих элементов?
• Почему были выбраны именно эти элементы и не были выбраны другие?

Для примера разберём Doom 2016 года. В этой игре нужно уничтожать демонов и постоянно двигаться, чтобы не умереть. В ней есть:

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

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

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

В первой статье мы упоминали This War of Mine как пример необычной комбинации жанров. Смешивать их можно, но не стоит нарушать внутренние правила жанра. This War of Mine — игра о войне и выживании. Она, например, «ломает» некоторые правила, рассказывая о военном конфликте с точки зрения мирных граждан, а не военных. Но при этом и война и выживание показаны в игре такими, какими их ожидает увидеть игрок.

В этой статье я буду называть прототипом всё, что помогает проверить идею. Например, тестовый арт поможет проверить визуальный стиль игры, а для того, чтобы разобраться с балансом, пригодится таблица в Microsoft Excel.

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

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

Термин не совсем корректный, но тем не менее. Для проверки идеи подойдут любые публичные инструменты. Раньше можно было использовать Kickstarter и Steam Greenlight. Но сейчас ведение Kickstarter-кампании — это отдельная тяжелая работа, а Greenlight закрылся.

На мобильном рынке есть сервис SplitMetrics, который в чем-то похож на Greenlight — в него можно загрузить фейковую страницу игры с описанием и артом и посмотреть, сколько интереса она привлекает, не имея ничего кроме текста и пары картинок. Без арта можно участвовать в концепт-джемах. Один из них проводится в рамках Kanobu Games Jam.

Самый очевидный способ: написать рассказ по игре. Если есть костяк истории, но не хочется писать все сцены и диалоги, можно сделать свою кампанию на основе одной из настольных ролевых систем — Dungeons & Dragons, GURPS, Savage Worlds. Это позволит без артов и игровых механик оценить, как будут вести себя игроки, не знакомые с миром и героями.

Для нелинейных историй, где выбор игрока влияет на развитие сюжета, можно сделать небольшую визуальную новеллу — для этого есть готовые конструкторы вроде Renpy и Tyrano Builder. Любители визуальных новелл обычно относятся к инди-проектам с энтузиазмом и не требуют арт высшего качества, так что найти читателей будет несложно. Например, на форуме Visual novel database или многочисленных имиджбордах.

Ещё можно использовать инструменты компьютерных ролевых игр. Например, в Neverwinter Nights и Divinity: Original Sin 2 есть встроенные редакторы, где можно создать свою историю с геймплеем из основной игры.

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

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

Если очень хочется делать сразу в цифре, то лучше всего пользоваться готовыми вещами — использовать встроенные редакторы игр (как в упомянутой Divinity). Ещё можно делать моды для похожих и не очень игр. Очень популярные DOTA 2 и PUBG выросли из модов. Если игра не слишком комплексная, стоит обратить внимание на простые движки вроде Defold или Game Maker. Более подробно мы разберём движки в отдельном цикле статей про разработку.

Для всего, что касается принятия решений игроком, можно делать бумажные прототипы. Имея достаточно опыта, на бумаге можно прототипировать почти что угодно. Даже файтинг: Yomi, Exceed, Brawl.

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

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

Поле ограничено шестью клетками — оторваться от соперников на большее расстояние нельзя. Это аналог похожей механики из компьютерных гонок: отстающие игроки часто получают бонус к скорости. Как и в Mario Kart, есть оружие и атаки, которые позволяют замедлить врага — то есть отобрать у него жетоны ускорения. Успех атаки определяется броском кубика с учетом дистанции до цели.

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

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

Например, файтинги часто используют механику энергии. Персонаж получает энергию, когда наносит или получает урон. Эту механику легко добавить в настольную Yomi: при нанесении/получении урона — получите очко энергии. Когда у вас 5 очков, найдите в колоде карту суперудара. За розыгрыш суперудара заплатите 5 энергии.

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

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

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

Детально о цифровом прототипировании мы еще поговорим в будущих статьях, но его принципы едины как для видеоигры, так и для игры настольной. Их будет нагляднее рассмотреть на примере уже упомянутой Titanfall 2.

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

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

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

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

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

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

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

• Забудьте о красоте. Делайте прототип настолько уродливым и дешёвым, насколько это возможно без ущерба для его пользы. Оформление стоит отложить до момента, когда игра или прототип будут достаточно отлажены, чтобы показывать их посторонним.
• Заимствуйте. Берите картинки для прототипов из поисковой выдачи Google, а бесплатные модели из Unity Asset Store. Для бумажных прототипов можно использовать компоненты других настольных игр. Вагоны вместо машинок, кубы вместо домов.
• Ленитесь. Не надо делать больше, чем нужно для проверки. Для теста базовой механики стрельбы не нужно добавлять в прототип глушители и прицелы. И стоит сделать пять предметов оружия вместо двадцати.
• Упрощайте. Прототип должно быть очень просто поменять — это сэкономит много времени во время тестов. Если в прототипе есть карточки, писать на них ручкой быстрее, чем печатать новые после каждой правки. В цифровые прототипы стоит заложить возможность настройки параметров прямо во время игры.

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

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

1. Разбить концепт игры на множество маленьких идей.
2. Посмотреть, как похожие идеи реализовали другие и понять, почему было сделано именно так.
3. Сделать бумажный прототип для одной из идей.
4. Если результат нравится и всё работает как надо — можно двигаться дальше.
5. В противном случае нужно изменить идею и снова проверить её на прототипе.
6. Сфотографировать бумажный прототип и в двух-трёх абзацах описать, как проходило тестирование. Выкладывать это пока никуда не нужно — сохраните для завершающего этапа нашего цикла статей.

Эта статья — часть нашего большого проекта с vc.ru. Если выполнять все задания, можно — ни много ни мало — научиться делать видеоигры. И выиграть PS4 Pro в конце каждого цикла статей.

Цикл «Геймдизайн»:

• Первая статья «Как найти идею для игры».
• Вторая статья «Как превратить идею для игры в концепт».