Советы по работе над прототипом игры от Social Quantum

Доклад был прочитан в рамках White Nights St. Petersburg 2018 этим летом. Мы приводим краткую версию выступления.

Кирилл Шабордин

Когда возникает необходимость в прототипе

Основная задача игры состоит в том, чтобы она приносила фан и удовольствие. Эмоции и настроение – это трудноопределимые вещи, многокомпонентные. Не всегда ясно, какие именно механизмы для этого следует использовать.

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

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

Обращаю внимание, на этом этапе возникает необходимость не в детальном дизайн-документе, а именно в создании прототипа.

Почему?

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

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

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

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

Что такое прототип

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

Также не бывает быстрого прототипирования. Это тавтология. Не бывает медленного прототипирования. Любой прототип – это штука, которую мы делаем быстро.

Что такое «быстро»? Если реализация полноценного функционала займёт месяц, то его прототипирование должно занять не больше двух дней. Лучше — день. Если это не так, то вы занимаетесь не прототипированием, вы плохо реализуете фичу.

Прототипирование – это не делать плохо, прототипирование – это делать по-другому.

Так что такое прототип, чем он является?

Первое, любой прототип демонстрирует какой-нибудь один существенный аспект продукта, который вы делаете. Прототипы – это не комплексная штука, а та, которая демонстрирует один важный аспект.

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

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

Четвертое, прототип обязан использовать максимально понятный этой точке принятия решения язык.

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

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

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

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

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

Эволюционное прототипирование

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

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

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

Пруф-концепт

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

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

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

• Можем ли мы себе позволить вообще мультиплеерную игру сделать?
• Сколько народа сможет одновременно играть в игру на наших нынешних мощностях?
• Что такое lag compensation?

Вопросов, конечно, больше. И каждый потребует не только конкретного ответа, но и пруфа.

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

Советы по прототипированию

В качестве завершения списком выведу советы, которые могут вам помочь в создании прототипа:

1) Обязательно используйте то, что отлично подходит для прототипов. Например, вы работаете в Unity. Есть какая-то задача по 2D. Быстрее будет взять Defold или Game Maker, чтобы её проверить, чем залезть в 2D-функционал Unity.

2) Не делайте в прототипах ничего, что не демонстрирует идею.

3) Не называйте плохую реализацию прототипом.

4) Любой прототип лучше, чем слова.

5) Старайтесь использовать одну механику, один аспект того, что вы делаете в прототипе.

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

7) При работе над прототипом переиспользование контента всегда быстрее и правильнее, чем изобретение нового.

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