🚀Prototype: как проверить игру до того, как вы потратили на неё два года
Даров. Сегодня будем говорить про прототипы: что это такое, зачем они нужны и, традиционно, с чем их едят. Да, снова немного кондитерских изделий, как в прошлых постах. Нет, единорогов всё ещё не будет.
Получается прекрасная последовательность:
Vertical Slice → MVP → Prototype
То есть мы уверенно изучаем этапы разработки игры в обратном порядке. Очень эффективный образовательный процесс.
Но ведь про прототипы уже написали
И даже неплохо. Например, вот вам статья на DTF:
Там хорошо разобрана сама идея прототипирования, поэтому пересказывать её своими словами и делать вид, что я самостоятельно открыл прототип где-то между электричеством и пенициллином, особого смысла нет.
Я лучше немного иначе расставлю акценты, попробую вписать Prototype в предыдущие статьи про MVP и Vertical Slice и, главное, покажу всё это на собственном примере, ну почти...
Так что такое Prototype?
Если посмотреть статьи, джемы, дневники разработчиков и вообще разговоры вокруг геймдева, довольно быстро обнаруживается забавная вещь:
Прототипом люди называют довольно разные вещи.
Если сильно упростить, я бы свёл их примерно к трём вариантам.
- Prototype as experiment - штука, сделанная для проверки конкретной идеи или гипотезы. Может быть бумажной, страшной, одноразовой и вообще почти не напоминать будущую игру.
- Prototype as early playable build - первая версия игры, в которую уже физически можно поиграть. Именно в таком смысле слово «прототип» часто используется на геймджемах и в дневниках инди-разработчиков.
- Prototype as early production milestone - уже относительно цельная версия проекта, из которой команда собирается дальше выращивать полноценную игру.
Эти определения не обязательно противоречат друг другу. Один и тот же билд вполне может одновременно быть первым playable build, этапом производства и экспериментом. Может, но не обязан, да и смотрим мы на него с разных сторон.
А поскольку я менеджер, но всё-таки с инженерным образованием, сейчас произойдёт страшное.
ФОРМАЛЬНОЕ ОПРЕДЕЛЕНИЕ
Я люблю формальные определения.
Прототипирование — быстрая черновая реализация базовой функциональности будущего продукта или изделия для анализа работы системы. На этапе прототипирования малыми усилиями создаётся работающая система, возможно неэффективная, с ошибками и реализованная не полностью.
И вот здесь появляется гораздо более интересный вопрос:
- а что является «базовой функциональностью» игры?
- Ну... играть в неё?
Спасибо, статья окончена.
Если чуть серьёзнее, то базовой функциональностью игры является то, что игрок в ней делает. То есть gameplay. А если эти действия образуют повторяющуюся структуру вида
«сделал что-то → получил результат → оценил ситуацию → сделал следующий выбор»
то мы довольно быстро приходим к gameplay loop.
Отсюда возникает первая полезная мысль:
Если мы ещё не уверены, что основной gameplay работает, возможно, именно его и надо прототипировать.
А если gameplay уже кто-то проверил?
Допустим, я делаю очередной Vampire Survivors-like. Бегаем, стреляем, выбираем улучшения, на экране происходит геноцид геометрических фигур.
Работает ли такой gameplay?
Очевидно, да. Миллионы проданных копий уже провели этот плейтест за вас.
Но тогда возникает гораздо более интересный вопрос:
А зачем существует именно ваша игра?
Что в ней отличается?
Управление? Прогрессия? Комбинация жанров? Какая-нибудь механика? Multiplayer? Или ещё одна прекрасная идея, которая в голове звучит гениально, а после двух часов разработки вызывает желание заняться разведением картофеля?
Вот это уже и может стать предметом прототипирования.
Не обязательно спрашивать: «Работает ли такой жанр?»
Но тогда возникает следующий вопрос:
«Работает ли конкретно вот эта штука, ради которой вообще существует мой проект?»
Какой вопрос, такой и прототип
Допустим, у меня есть идея: «если сделать X, игроку будет интересно делать Y». Это пока не факт, а гипотеза.
Я могу потратить два года, нарисовать 148 персонажей, заказать музыку, написать лор нескольких государств, сделать трейлер, а потом выяснить, что X скучный. А могу сделать маленькую страшную штуку, которая содержит достаточно X, чтобы проверить эту гипотезу.
Поэтому лично для себя я бы сформулировал назначение прототипа так:
ПРОТОТИП ДОЛЖЕН ПОМОГАТЬ НАЙТИ ОТВЕТ НА ВОПРОС
Не доказать, что ваша идея гениальна, не убедить команду продолжать разработку и не выглядеть красиво на фестивале. Его задача — дать вам информацию, которой у вас раньше не было.
И здесь появляется довольно неприятное, но важное следствие: если прототип показал, что идея не работает - прототип сработал.
Поздравляю. Ваша игра умерла, зато дёшево.
И именно поэтому не существует универсального списка вещей, которые обязательно должны быть в игровом прототипе. Его состав определяется вопросом.
- Хотите понять, приятно ли перемещаться? Сделайте персонажа, серые кубы и движение.
- Проверяете экономику стратегии? Возможно, вам хватит ресурсов, нескольких правил и Excel.
- Проверяете настольную боевую систему? Бумага, карточки, кубики, человеки. Добро пожаловать в высокотехнологичный XXI век.
Прототип вообще не обязан быть цифровым. Средство проверки стоит выбирать под вопрос, а не наоборот.
А теперь допустим, что вопрос другой:
«Сможем ли мы сделать gameplay, графику, анимации и интерфейс примерно того качества, которое хотим видеть в финальной игре, причём в рамках наших ресурсов?»
И вот наша проверка уже начинает подозрительно напоминать Vertical Slice, а про него у меня, совершенно случайно, уже есть целая статья.
Именно поэтому Prototype, MVP и Vertical Slice я бы не воспринимал как строгую линейку.
- Prototype: работает ли идея и что мы вообще можем из неё узнать?
- MVP: можно ли из необходимого минимума собрать жизнеспособный продукт?
- Vertical Slice: можем ли мы сделать небольшой кусок игры примерно так, как должна выглядеть и ощущаться финальная игра?
Иногда один билд способен частично отвечать сразу на несколько этих вопросов. Потому что реальная разработка почему-то отказывается помещаться в красивые схемы из презентаций.
А теперь почему эта статья вообще появилась
Когда-то у меня появилась прекрасная идея.
🎆ИГРА МЕЧТЫ™
Историческая игра про развитие ракетной и космической программы: исследования, конструирование, испытания, инфраструктура, персонал, политика, экономика, переговоры, куча исторического контента, две кампании за СССР и США и несколько десятилетий истории.
В общем, очень разумный проект для одного человека, который до этого не выпустил ни одной игры.
В одном геймдизайнерском чате я как-то показал вот эту картинку сверху, на что получил прекрасный комментарий:
ohmosh. я не уверен что в чате вообще есть люди, даже если собраться, чтоб такое вывозилось)
И тут произошло редкое событие:
Я ПОДУМАЛ
Я понял, что не очень хочу потратить следующие десять лет жизни на разработку первой половины обучающего сценария.
Поэтому большую игру отложил и начал искать кусок, который можно было бы превратить в самостоятельную небольшую игру.
Одним из таких кусков были переговоры. И тут мне стало интересно:
а могут ли переговоры быть не диалоговым окном между настоящим gameplay, а gameplay сами по себе?
Не:
«выберите синюю реплику, получите +5 к дипломатии»
A:
понять человека → выбрать, что ему предъявить → решить, как это подать → увидеть реакцию → сделать вывод → изменить следующий ход.
Из этого появилась идея маленькой отдельной игра Road to Space: The Administrator.
Но здесь я снова оказался перед той же проблемой. Можно было сразу начать делать полноценную игру: добавить много чиновников, десятки документов, кампанию, прогрессию, события, красивый интерфейс, анимации и звук. Можно было даже нарисовать фон, страшно подумать.
Только зачем всё это, если сама механика переговоров окажется скучной?
Поэтому вместо вопроса «как мне сделать эту игру?» я задал гораздо более узкий:
«Интересна ли механика переговоров с чиновником и чтение его предпочтений само по себе?»
И вот теперь у меня наконец появился нормальный вопрос для прототипа.
Но об этом потом. Надеюсь, не через год...
🚩Красные флаги
Ну и раз уж мы добрались сюда, несколько признаков того, что с прототипом, возможно, происходит какая-то фигня.
- Вы не можете сформулировать, что именно проверяете. Если единственный ответ — «ну, игру», определить момент, когда эксперимент закончен, будет довольно сложно.
- Вы не знаете, какой результат заставит вас изменить решение. Если любой результат тестирования интерпретируется как подтверждение идеи, поздравляю, вы не проверяете гипотезу, а ищете моральную поддержку.
- Прототип постоянно обрастает контентом. Ещё один персонаж, ещё пять уровней, ещё одна система. Иногда они действительно нужны для проверки. Иногда вам просто страшно показать людям то, что уже есть.
- Вы полируете то, что не влияет на ответ. Красивый интерфейс может быть нужен для UX-прототипа. Финальная анимация перезарядки в прототипе экономики, вероятно, нет.
- Прототип уже жалко выбрасывать. Это особенно коварная стадия. Чем больше времени и денег вложено в эксперимент, тем сложнее спокойно принять результат «идея не работает».
Последний пункт мне особенно нравится, потому что человеческий мозг придумал sunk cost задолго до появления Unity.
TL;DR
Если попытаться утрамбовать всю эту стену текста в несколько строк, получится примерно так:
Прототип — это инструмент для получения ответа на конкретный вопрос о будущей игре.
Сначала появляется вопрос или гипотеза. Затем мы строим минимальную штуку, которая позволяет её проверить, проводим эксперимент и смотрим на результат.
Поэтому прототип может быть бумажным или цифровым, выглядеть ужасно или довольно прилично, стать основой будущей игры или отправиться в мусорную корзину. Всё это нормально, если в конце мы знаем о своей игре что-то важное, чего не знали в начале.
В моём случае вопрос сейчас довольно простой:
Интересны ли переговоры RTSA сами по себе?
И вот это я сейчас и пытаюсь выяснить.
Всё таки прочесть всё: 👉ТЫК
З.Ы.
Когда-то я обещал написать следующую статью про Demo. Прошёл примерно год, поэтому до истечения установленного народом трёхлетнего SLA у меня ещё чуть меньше двух лет.
Следующая статья поэтому может быть про Demo, а может быть про результаты этого прототипа, а может быть про саму игру.
Планирование контента, как видите, поставлено примерно так же профессионально, как и вся остальная инди-разработка.