Валидация игры до производства: почему MVP плохо проверяет, хочется ли в это играть

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

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

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

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

Minimum Viable Product — минимально жизнеспособный продукт — появился не как разрешение выпускать что угодно с кнопкой. В формулировке Эрика Риса это версия продукта, позволяющая получить максимум подтверждённого знания о клиентах с минимальными усилиями. Ключевое слово здесь не minimum, а learning — знание, которое меняет решение.

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

С играми сложнее. Их ценность часто является не функцией, а переживанием. MDA-фреймворк разделяет игру на mechanics, dynamics и aesthetics: правила и действия создают поведение системы, а оно — опыт игрока. Разработчик проектирует цепочку от механик к эмоции. Игрок встречает её с другого конца: сначала чувствует скуку, напряжение, мастерство или хаос, а уже потом догадывается, какая система это породила.

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

Обычно словом MVP в геймдеве накрывают сразу четыре разных вопроса:

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

Проблема не в том, что команда мало тестирует. Проблема в том, что она получает ответ на один вопрос и защищает им решение по другому.

Постмортем мобильной игры HoloVista почти лабораторно показывает эту ошибку.

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

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

Авторы постмортема сформулировали пропущенный шаг: между коротким proof of concept — доказательством технической идеи — и дорогой версией нужен был более длинный прототип с дешёвыми материалами. Он показал бы, что первые пять минут измеряли новизну камеры, а не устойчивость игрового цикла.

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

Короткий тест не был бесполезным. Он честно доказал, что новая механика вызывает интерес первые пять минут. Ошибка началась в момент перевода: «людям любопытно» превратилось в «мы нашли основу полноценной игры».

Я бы начинал не со списка функций прототипа, а с обещания опыта. Это одно предложение, описывающее, что целевой игрок должен делать, чувствовать и хотеть после достаточно длинной сессии.

Например:

Здесь уже есть три уровня проверки.

Функциональный: игрок нашёл способности, понял правила и смог их комбинировать.

Поведенческий: он действительно экспериментировал, а не прошёл единственную очевидную комбинацию.

Эмоциональный: он почувствовал мастерство и захотел повторить цикл.

Фраза «у нас roguelike с глубокой синергией» не является обещанием опыта. Это жанровый ярлык с корпоративной надеждой внутри. Проверяемое обещание требует наблюдаемого поведения и момента, после которого можно принять решение.

Исследователи player experience тоже отделяют непосредственные свойства взаимодействия от последующих переживаний. Player Experience Inventory, разработанный с участием 64 специалистов и проверенный на 529 игроках, различает функциональные последствия — например, понятность управления и аудиовизуальную привлекательность — и психосоциальные: мастерство, погружение, любопытство и смысл.

Это полезное напоминание для продюсера: «управление понятно» и «игрок чувствует себя мастером» — не две формулировки одной метрики. Между ними находится вся игра.

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

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

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

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

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

Смотреть нужно не на красоту прохождения, а на поведение:

На этом этапе полезен подход RITE — Rapid Iterative Testing and Evaluation. В описанном исследователями Microsoft Games Studios методе проблему исправляют сразу после её уверенного обнаружения, а следующими участниками проверяют уже новую версию. Метод применяли, в частности, к обучению в Age of Empires II.

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

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

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

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

Теперь создаётся experience slice — минимальный фрагмент, в котором присутствуют все элементы, необходимые именно для целевого переживания. Это не обязательно красивый вертикальный срез всей игры.

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

После сессии полезно спрашивать не «понравилось ли», а:

Опросники могут сделать измерение последовательнее, но не превращают эмоцию в температуру тела. Исследование с 571 участником показало, что структура популярного Game Experience Questionnaire подтверждается лишь частично, а для PENS потребовалась корректировка отдельных шкал. Поэтому один суммарный «fun score» не должен решать судьбу проекта. Поведение, интервью, наблюдение и шкалы дополняют друг друга.

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

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

Steam Playtest подходит для контролируемого тестирования сборки с реальными пользователями: отдельный App ID позволяет включать и отключать доступ, не смешивая тест с отзывами и показателями основной игры. А публичное демо — уже часть решения о покупке. Документация Steamworks рекомендует показывать в нём качественный фрагмент ключевого опыта, который оставляет желание продолжить.

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

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

Рассмотрим условный проект с оставшимся бюджетом производства 24 млн рублей. Команда сомневается, сохраняет ли основной цикл интерес после первых десяти минут. Более длинный прототип с временным контентом стоит 600 тысяч.

Допустим, команда оценивает вероятность обнаружить фундаментальную проблему, которая остановит или радикально изменит проект, всего в 20%. При ранней остановке удастся избежать 12 млн будущих расходов: не всех 24 млн, потому что часть работы можно перенести, а часть бюджета всё равно понадобится на новый вариант.

Ожидаемая ценность информации равна:

Порог безубыточности теста ещё интереснее:

Если шанс предотвратить ошибочное продолжение проекта выше 5%, тест экономически оправдан при этих предпосылках. Это не универсальный прогноз и не попытка оценить творчество формулой. Это способ увидеть, что «дорогой прототип» может быть дешёвой страховкой относительно следующего решения.

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

Перед каждой сборкой я бы заполнял семь полей.

Порог нужно фиксировать до просмотра результатов. Иначе после теста команда обнаружит, что 18% добровольных повторов — это «неплохой фундамент», хотя вчера ожидала 40%. Метрика пережила встречу, потому что целью встречи было сохранить проект.

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

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

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

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

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

Средний балл «веселья». Он смешивает сегменты, моменты и причины. Одинаковые 7 из 10 могут означать «механика отличная, контента мало» и «всё аккуратно, но больше не запущу».

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

У метода есть ограничения.

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

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

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

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

Лестница не требует делать все игры одинаково. Она требует честно назвать, какую часть будущего опыта текущая сборка физически способна воспроизвести.

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

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

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

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

Когда фрагмент достаточно качественно представляет ключевой опыт и помогает принять решение о покупке. Для раннего сбора обратной связи безопаснее закрытые тесты или Steam Playtest: публичное демо уже работает как маркетинговый продукт.

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

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

Концепт проверяет обещание. Greybox — механику. Более длинный дешёвый прототип — устойчивость игрового цикла. Experience slice — целевое переживание. Steam Playtest — поведение внешней аудитории. Демо — способность опыта поддержать покупку. Вертикальный срез — возможность команды производить нужное качество в нужной экономике.

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

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