Прототип нужен, чтобы получить ответ на один конкретный вопрос. Всё, что не помогает получить этот ответ, в него не входит.
На практике именно с этим у команд чаще всего возникают сложности. Прототип начинается как небольшая проверка механики, а через несколько недель в нём уже появляются меню, настройки, сохранения, несколько уровней, почти финальный интерфейс и арт, который жалко выбрасывать.
В какой-то момент команда перестаёт проверять гипотезу и незаметно начинает делать маленькую версию всей игры.
Проблема не только в лишних затратах. Чем больше систем появляется вокруг основной механики, тем сложнее понять, что именно показал эксперимент. Если прототип не понравился тестировщикам, причина может быть в самой идее, неудобном управлении, непонятном интерфейсе или просто в том, что половина времени ушла на вещи, которые вообще не требовались для проверки.
Поэтому объём прототипа лучше определять не через список функций, а через вопрос, на который команда хочет получить ответ.
Сформулируйте вопрос до начала работы
Фраза «сделаем прототип боя» звучит понятно, но почти ничего не ограничивает.
Что именно нужно узнать о бое? Интересно ли уклоняться от атак? Работает ли выбранная камера? Читается ли комбинация ближнего и дальнего оружия? Удобно ли управление на геймпаде? Может ли игрок разобраться в механике без обучения?
Это уже разные задачи, и для каждой потребуется разный прототип.
Хороший вопрос допускает достаточно определённый ответ. Например: «Удерживает ли базовый игровой цикл внимание в течение десяти минут?» или «Понимает ли новый игрок принцип перемещения без текстовой инструкции?».
Как только вопрос зафиксирован, scope начинает сокращаться сам.
Если команда проверяет управление персонажем, ей вряд ли нужен полноценный inventory. Если нужно проверить ощущение от боя, не требуется система достижений. Если вопрос касается взаимодействия четырёх игроков, имеет смысл вкладываться в сетевой сценарий, но не обязательно создавать финальное главное меню.
Это важный момент и с точки зрения управления проектом. Неопределённый прототип легко растягивается на месяцы, потому что для него невозможно сказать, когда работа действительно закончена. Такие размытые задачи быстро превращаются в один из ранних сигналов проблем проекта: команда постоянно занята, scope растёт, а момент принятия решения всё время отодвигается.
Главный принцип здесь простой: сначала сделать риск видимым, затем принимать решение о сроке, scope и составе.
Прототип не должен выглядеть как маленький релиз
Частая ошибка — пытаться сделать прототип достаточно красивым, чтобы его не стыдно было показать.
В результате появляется временная графика, затем её немного улучшают, потом возникает необходимость привести в порядок UI, после чего кто-то предлагает добавить меню, потому что без него демо выглядит незаконченным.
Все эти решения понятны эмоционально, но плохо соответствуют цели прототипирования.
Если задача — понять, работает ли механика, серые кубы могут быть лучше красивых моделей. Они не отвлекают людей, которые смотрят билд, и не провоцируют обсуждение качества материалов, света или анимаций вместо самой идеи.
Это не значит, что визуальная часть никогда не важна. Иногда гипотеза напрямую связана с восприятием картинки: например, читаются ли враги на фоне окружения или понимает ли игрок направление атаки по VFX. Тогда визуальные элементы действительно входят в scope — но только в той степени, которая необходима для проверки.
Хороший прототип выглядит незаконченным не потому, что команда плохо поработала, а потому, что она осознанно не делала то, что не требовалось для ответа.
Не пытайтесь заранее построить production-архитектуру
Ещё одна распространённая ловушка — писать код прототипа так, будто через неделю его передадут команде из двадцати разработчиков.
Начинаются обсуждения сервисного слоя, универсальной системы событий, будущего save format, dependency injection и архитектуры для механик, которых ещё даже нет.
Для production всё это может быть важно. Для прототипа — часто нет.
Если через три дня команда выяснит, что сама механика не работает, качество архитектуры этого кода не принесёт проекту никакой пользы.
Поэтому прототипный код может быть временным. Здесь допустимы быстрые решения, заглушки, упрощённые данные и жёстко заданные значения, если они помогают быстрее проверить гипотезу.
Но важно заранее признать этот код временным.
Самая неприятная ситуация возникает не тогда, когда прототип написан быстро, а когда через полгода он неожиданно превращается в фундамент production. Команда продолжает добавлять функции поверх системы, которая никогда не проектировалась для масштабирования, а переписать её становится всё дороже.
Если прототип подтвердил идею и проект переходит дальше, нужно отдельно решить, какие части можно сохранить, а какие лучше реализовать заново. Для Unity-проектов такой переход иногда полезно начинать с технической оценки текущего состояния, особенно если экспериментальный код уже начал обрастать реальными системами.
Смотреть прототип должны не только его авторы
Есть ещё одна проблема: разработчик слишком хорошо знает собственную механику.
Он знает, куда идти, какие кнопки нажимать, зачем существует каждый объект и какого поведения ожидать от системы. Даже очень неудобная механика через несколько дней разработки начинает казаться естественной.
Поэтому важную гипотезу стоит показывать людям, которые не участвовали в её реализации.
Если необходимо проверить понятность управления, не нужно сначала объяснять тестировщику управление. Если проверяется основной игровой цикл, лучше посмотреть, что человек делает сам, где останавливается и какие решения принимает.
Наблюдение здесь зачастую полезнее вопроса «тебе понравилось?».
Игрок может сказать, что всё было нормально, но при этом половину времени не понимать, куда двигаться. Или наоборот — визуально сырой прототип может вызывать желание пройти ещё одну попытку, хотя пользователь отдельно замечает десяток недоработанных деталей.
Поэтому при раннем тестировании важна не полировка, а возможность быстро увидеть поведение человека. Полноценный QA игрового проекта понадобится позже; на стадии прототипа ключевая задача — проверить саму гипотезу, прежде чем вокруг неё появится большой production.
Ответ «нет» — тоже успешный результат
Команде психологически проще воспринимать прототип как первый этап создания будущей игры.
Отсюда появляется желание сохранить код, довести картинку, добавить ещё одну механику и добиться того, чтобы эксперимент обязательно сработал.
Но у прототипа другая задача.
Если за неделю команда выяснила, что управление неудобно и выбранная идея не работает, прототип выполнил свою функцию.
Гораздо хуже потратить шесть месяцев на production и прийти к тому же выводу после создания персонажей, уровней, интерфейса и контента.
Поэтому перед началом работы полезно заранее договориться не только о том, какой результат подтверждает идею, но и о том, что будет считаться отрицательным ответом.
Например, если после нескольких тестов никто из новых игроков не понимает базовую механику без объяснения, команда не должна автоматически добавлять ещё месяц разработки. Сначала стоит решить, имеет ли смысл продолжать гипотезу вообще.
Прототип нужен именно для того, чтобы дешёво ошибаться.
Самая опасная фраза — «раз уж мы уже здесь»
Scope редко увеличивается сразу в два раза. Обычно это происходит постепенно.
Раз уж есть персонаж, давайте добавим нормальную анимацию. Раз уж сделали уровень, нужен красивый фон. Раз уж даём билд руководителю, неплохо бы сделать стартовый экран. Раз уж есть несколько сцен, давайте добавим сохранение.
Каждая отдельная задача кажется небольшой и логичной. Через две недели исходный вопрос уже занимает небольшую часть всей работы.
В такой ситуации полезно каждый раз возвращаться к одной проверке: поможет ли эта задача получить более надёжный ответ на исходный вопрос?
Если нет — её нужно либо убрать, либо честно признать, что команда уже делает не прототип, а следующий этап проекта.
Само по себе это не проблема. Иногда после первых результатов действительно становится понятно, что нужно собрать более цельный vertical slice или подготовить версию для инвестора. Плохо только тогда, когда смена цели происходит незаметно, а сроки и бюджет продолжают считаться как для небольшого эксперимента.
Прототип и vertical slice — это разные вещи
Их часто смешивают, хотя задачи у них разные.
Прототип отвечает: работает ли идея?
Vertical slice отвечает скорее: можем ли мы сделать эту игру на нужном уровне качества и как будет выглядеть небольшой законченный фрагмент production?
Во втором случае уже важны визуальное качество, pipeline арта, UI, звук, производительность и то, как различные команды работают вместе. Такой результат может использоваться для оценки стоимости production, демонстрации издателю или фиксации качества будущего контента.
Поэтому требования к коду и контенту у vertical slice значительно выше.
Если команда ждёт от простого prototype качества vertical slice, он становится слишком дорогим. Если пытается использовать сырой prototype как доказательство будущего production quality, результат, наоборот, может выглядеть слабее реального потенциала проекта.
Важно просто заранее договориться, что именно сейчас создаётся и какое решение должно быть принято после просмотра.
Когда прототип можно считать законченным
Прототип закончен не тогда, когда в нём больше нечего улучшать.
Его можно улучшать бесконечно.
Он закончен тогда, когда получено достаточно данных, чтобы принять следующее решение.
Если гипотеза подтверждена, команда может переходить к pre-production, vertical slice или полноценной разработке. Если ответ отрицательный — менять механику, проверять другой вариант или вообще отказываться от идеи.
И только после этого имеет смысл обсуждать production-код, финальный арт и масштабирование команды.
Если же после прототипа никто не может сказать, что именно было проверено и какой вывод из этого следует, значит проблема была не в качестве реализации. Скорее всего, изначально не был зафиксирован вопрос.
Чем меньше прототип, тем быстрее решение
Хороший scope — не тот, в котором достаточно много функций, чтобы билд выглядел убедительно.
Он должен быть минимальным объёмом работы, после которого команда сможет принять достаточно уверенное решение.
Иногда это одна сцена и один персонаж. Иногда — простой multiplayer-матч. Иногда — набор экранов без полноценного backend. Всё зависит от риска, который нужно проверить.
NoPanic Studio подключается как к уже существующим проектам, так и к ранним этапам разработки на Unity. На стадии прототипирования задача обычно не в том, чтобы сразу построить всю будущую архитектуру, а в том, чтобы быстро собрать проверяемую версию, получить данные и понять, стоит ли масштабировать решение.
А если прототип уже превратился в большой проект, в котором сложно отделить экспериментальный код от будущего production, имеет смысл сначала провести диагностику и решить, что действительно стоит переносить дальше, а что дешевле оставить позади.
Если есть идея механики или уже начатый прототип, но scope постоянно растёт и непонятно, когда можно переходить к следующему этапу — пришлите описание гипотезы и текущего билда. Поможем определить минимальный объём проверки и отделить то, что нужно для ответа сейчас, от задач будущего production.