Сначала формулируется риск, потом появляется прототип
Фраза «нам нужно сделать прототип игры» сама по себе почти ничего не говорит разработчику.
Как понять, что он закончен?
Можно добавить ещё одного противника. Потом сделать второй уровень. Улучшить управление. Добавить прогрессию. Сделать красивее интерфейс.
У такой задачи нет естественной точки остановки.
Гораздо полезнее начинать с того, что команда пока не знает.
Представим кооперативную игру, в которой четыре игрока должны вместе управлять одной машиной. Основная неопределённость может заключаться не в графике и даже не в сетевой технологии, а в самом взаимодействии: действительно ли необходимость договариваться создаёт интересный игровой процесс или через десять минут начинает раздражать?
Для ответа не нужны полноценное главное меню, сохранения, большой уровень и десяток персонажей.
Нужна минимальная версия ситуации, в которой четыре человека смогут несколько раз пройти основной цикл.
Тогда прототип становится экспериментом.
Если взаимодействие работает — появляется основание развивать идею дальше.
Если нет — команда узнаёт это до того, как построила вокруг механики несколько месяцев production.
В соседнем материале мы отдельно разбирали, что входит в объём игрового прототипа, а что лучше оставить за его пределами. Scope здесь напрямую следует из вопроса: всё, что не повышает качество ответа, можно пока не делать.
Хорошая гипотеза должна иметь возможность провалиться
Есть ещё одна проблема: иногда команда формулирует проверку так, что прототип практически невозможно признать неудачным.
Например:
«Хотим проверить, можно ли сделать интересную боевую систему».
После первых тестов игрокам скучно.
Команда добавляет ещё несколько атак.
Не помогло — появляется новый противник.
Затем меняется камера, добавляются эффекты, новая система комбо.
Через два месяца прототип всё ещё «проверяется».
По сути команда уже не исследует гипотезу, а пытается любой ценой сделать её истинной.
Поэтому ещё до теста полезно понимать, какой результат заставит изменить направление.
Если предполагается, что новая механика должна быть понятна без инструкции, а большая часть тестировщиков не может разобраться после нескольких попыток, это важный сигнал.
Не обязательно сразу выбрасывать идею. Возможно, проблема находится в подаче.
Но нельзя автоматически интерпретировать любой отрицательный результат как запрос на ещё две недели разработки.
Хорошая гипотеза допускает ответ «нет».
И в раннем production этот ответ часто не менее ценен, чем успешный тест.
Не спрашивайте игрока, понравилась ли ему идея
После тестирования возникает естественный вопрос:
«Ну как тебе?»
Он почти всегда даёт слабые данные.
Человек может не хотеть расстраивать разработчиков. Может обратить внимание на красивую анимацию и сказать, что всё понравилось, хотя в самой механике практически не разобрался. Или наоборот — пожаловаться на серые кубы, хотя игровой цикл уже работает отлично.
Гораздо полезнее смотреть на поведение.
Если механика должна вызывать желание повторить цикл, повторяет ли его человек без просьбы?
Если игрок должен сам обнаружить возможность, находит ли он её?
Если предполагается выбор между двумя стратегиями, действительно ли люди принимают разные решения или почти все используют один очевидный вариант?
Если после поражения пользователь хочет попробовать ещё раз, это часто говорит о механике больше, чем оценка по десятибалльной шкале.
Поэтому prototype validation лучше строить вокруг наблюдаемых действий.
Иногда достаточно пяти-десяти тестов, чтобы увидеть одну и ту же проблему несколько раз подряд. Не нужно ждать большой статистической выборки, если базовый пользовательский сценарий объективно непонятен почти каждому человеку.
Авторы механики — плохие первые тестировщики
Разработчик слишком хорошо знает собственный проект.
Он уже привык к скорости персонажа, знает комбинации клавиш, понимает значения всех иконок и заранее знает, куда смотреть.
Через несколько недель работы даже странное управление начинает ощущаться естественным.
Поэтому внутренний тест командой полезен для поиска технических ошибок, но плохо отвечает на вопрос, насколько понятен игровой опыт новому человеку.
Если прототип рассчитан на обычного игрока, в какой-то момент его должен увидеть человек без контекста.
Причём желательно не начинать с пятиминутного объяснения механики.
Если игра сама должна научить игрока базовому действию, объяснение перед тестом уничтожает значительную часть проверки.
Можно буквально наблюдать, где человек впервые останавливается, что пробует нажать, какие элементы игнорирует и в какой момент спрашивает, что делать дальше.
Такие наблюдения постепенно показывают не только «нравится или нет», но и где именно ломается понимание.
Не путайте проверку механики с проверкой качества production
Серые блоки способны отлично проверить одну гипотезу и совершенно не подходят для другой.
Если команда хочет понять, интересна ли схема перемещения персонажа, финальное окружение почти наверняка не требуется.
Если вопрос заключается в том, считывает ли игрок направление атаки противника, уже понадобится какой-то минимальный набор анимаций или VFX.
Если основная ценность продукта построена на атмосфере и визуальном восприятии пространства, слишком абстрактный prototype может вообще не содержать ключевой части опыта.
Поэтому правило «прототип должен быть максимально некрасивым» тоже слишком упрощает задачу.
Он должен содержать ровно тот уровень реализации, без которого нельзя честно проверить гипотезу.
Всё остальное пока лишнее.
Это особенно важно при переходе к vertical slice. Prototype отвечает на вопрос «работает ли основная идея?». Vertical slice уже должен показать, может ли команда производить эту игру на нужном уровне качества.
Именно поэтому результат раннего теста нельзя автоматически считать доказательством production-ready проекта.
Временный код допустим, но должен оставаться временным
Прототип существует в условиях неопределённости, поэтому писать для него идеальную масштабируемую архитектуру зачастую невыгодно.
Если через неделю механика будет отброшена, несколько дней работы над универсальным framework просто не принесут пользы.
Быстрые решения, заглушки и упрощения здесь вполне уместны.
Проблема возникает после успешного теста.
Команда видит, что механика работает, и решает:
«Раз уже всё написано, продолжим отсюда».
Через месяц вокруг прототипного кода появляется UI.
Через три — сохранения.
Через полгода временная система уже лежит в центре проекта, и никто не хочет её менять.
Поэтому после validation полезно отдельно принять техническое решение: какую часть результата переносим дальше, а какую реализуем заново уже с учётом production-требований.
Если экспериментальный Unity-проект уже вырос значительно дальше первоначального прототипа, иногда полезно сначала провести аудит Unity-проекта, чтобы понять, где находится просто техническая шероховатость, а где ранние решения уже ограничивают дальнейшую разработку.
Не проверяйте пять гипотез одним прототипом
Есть соблазн использовать одну сборку максимально эффективно.
Раз уж тестируем бой, заодно посмотрим экономику.
И onboarding.
И новый UI.
И progression.
Формально команда получает больше данных за одну сессию.
На практике становится сложнее интерпретировать результат.
Игроку не понравился бой. Но, возможно, он просто не понял управление.
Пользователь бросил прототип через десять минут. Это означает, что core loop слабый или tutorial был слишком длинным?
Игрок почти не использовал второе оружие. Оно неинтересно или UI плохо объяснил его наличие?
Чем больше неизвестных меняется одновременно, тем хуже эксперимент отвечает на каждый отдельный вопрос.
Это тот же принцип, который полезен и позже, например в LiveOps: если одновременно запустить пять изменений, сложно понять, какое именно повлияло на метрику.
Прототипирование работает лучше, когда одна сборка имеет один главный вопрос и несколько второстепенных наблюдений, а не пытается доказать весь дизайн игры одновременно.
Технические риски тоже можно проверять прототипом
Не каждый prototype существует ради gameplay.
Иногда основная неопределённость техническая.
Сможет ли проект держать нужное количество игроков?
Помещается ли целевой визуальный уровень в performance budget мобильного устройства?
Можно ли построить нужный объём процедурного мира без неприемлемых загрузок?
Как поведёт себя ключевая система на консоли?
В таком случае prototype может выглядеть совсем не как игра.
Это может быть одна тяжёлая сцена, network stress test или небольшой фрагмент технологии.
Важен тот же принцип: заранее определить, что считается доказательством.
Если команда выбирает технологический стек, такой тест полезнее сравнения презентаций движков. В статье «Unity или Unreal: выбирать нужно не по картинке» мы как раз разбирали необходимость проверять самые дорогие production-риски на достаточно реалистичном фрагменте, а не выбирать движок по одной красивой demo scene.
Не тестируйте на людях, которые не похожи на аудиторию
Пять разработчиков из соседнего отдела способны дать полезную обратную связь, но это не всегда ваша будущая аудитория.
Если проект рассчитан на людей, которые редко играют в сложные игры, тестирование только на hardcore-геймерах может показать совершенно ложную картину onboarding.
Если продукт ориентирован на поклонников конкретного жанра, случайный человек может не понимать conventions, которые для целевой аудитории очевидны.
Поэтому на раннем этапе не нужна идеальная исследовательская выборка, но полезно хотя бы помнить, для кого вообще делается продукт.
Особенно это важно при проверке сложности, интерфейса и первых минут игры.
Проблема, которая возникает только у человека вне целевой аудитории, может быть не так важна.
И наоборот, если основной target player сразу говорит «я уже видел эту механику десятки раз», это гораздо более значимый сигнал.
Первый положительный тест ещё ничего не доказывает
Иногда prototype быстро показывает хороший результат, и команда начинает расширять production.
Но один удачный тест легко переоценить.
Особенно если его проходили знакомые разработчиков или люди, которые заранее слышали концепцию.
Полезно повторить проверку на нескольких новых участниках и посмотреть, воспроизводится ли эффект.
Не нужно ждать огромной статистики. Задача prototype validation не в том, чтобы получить научную публикацию.
Но результат должен быть достаточно устойчивым, чтобы команда была готова потратить на него следующие месяцы работы.
Это важный порог.
До прототипа команда рискует несколькими днями или неделями.
После положительного решения она может инвестировать месяцы производства, арт и расширение состава.
Чем дороже следующий шаг, тем больше уверенности стоит собрать перед переходом.
Главный принцип остаётся прежним: сначала сделать риск видимым, затем принимать решение о сроке, scope и составе.
Не полируйте прототип только потому, что его нужно кому-то показать
Особенно быстро scope начинает расти, когда появляется внешний зритель.
Прототип нужно показать инвестору, издателю или руководству.
Сразу хочется улучшить интерфейс, добавить красивые модели, сделать стартовое меню и скрыть технические заглушки.
Часть такой работы может быть оправданной: человек должен иметь возможность нормально понять идею.
Но здесь важно не смешивать две задачи.
Есть validation build, который нужен для проверки гипотезы.
И может быть presentation build, который помогает представить уже полученный результат внешней стороне.
Они не обязаны быть одинаковыми.
Если команда начинает добавлять в prototype несколько недель presentation polish только ради одной встречи, стоит хотя бы отдельно видеть стоимость этого решения.
Иногда выгоднее перейти к vertical slice.
Иногда достаточно записать хороший ролик.
Например, в материале «Трейлер до vertical slice: когда это работает» мы разбирали ситуацию, когда проект ещё не готов к полноценному production-показу, но команде уже нужно сформулировать внешнее обещание. Главное — не позволить маркетинговому материалу подменить собой проверку самой игры.
Validation заканчивается решением
Самая важная часть прототипа происходит после тестирования.
Команда должна решить, что делать дальше.
Продолжаем эту механику.
Меняем конкретную часть и проверяем ещё раз.
Отказываемся от решения и пробуем другой подход.
Переходим к vertical slice.
Если после нескольких недель тестирования итог звучит как «ну, в целом вроде перспективно, давайте ещё что-нибудь добавим», процесс не завершён.
Не обязательно принимать бинарное решение после каждого маленького эксперимента. Но должен существовать понятный следующий вопрос.
Иначе прототип постепенно становится обычной разработкой без roadmap.
Это особенно опасно для небольших команд, где один неопределённый эксперимент способен забрать существенную часть бюджета проекта.
Не нужно доказывать прототипом всю игру
Хороший prototype не гарантирует коммерческий успех.
Он не доказывает, что игроки будут возвращаться через месяц.
Не доказывает, что экономика сработает.
Не подтверждает стоимость production и не решает вопрос маркетинга.
Он уменьшает конкретный риск, ради которого был создан.
И этого достаточно.
После подтверждения одной гипотезы проект переходит к следующей неопределённости.
Именно так постепенно появляется более уверенная картина продукта: сначала core mechanic, затем production quality, технические ограничения, контентный pipeline и остальные системы.
NoPanic Studio подключается к ранним стадиям разработки новых игр и прототипированию на Unity и других движках. Задача такого этапа — не построить уменьшенную версию всего продукта, а выделить самые дорогие неизвестные и проверить их до того, как команда начнёт масштабировать production.
Если у проекта уже есть идея или рабочий прототип, но непонятно, доказал ли он что-то кроме самого факта запуска — пришлите описание механики, текущую сборку и главные сомнения команды. Поможем сформулировать проверяемую гипотезу, отделить нужный scope от лишнего и определить, каких данных достаточно для перехода к следующему этапу.