Прототип и playtest дизайна

ОБЯЗАТЕЛЬНО ДЛЯ НОВИЧКОВ

Всем

Зачем прототип

Прототип отвечает на вопрос: "Работает ли замысел, когда им играют?" Это не демо для Steam и не vertical slice для издателя — дешёвый эксперимент с одной ясной гипотезой. Типичная ошибка — месяцами полировать арт, не проверив, интересен ли core loop.

Маршрут модели — Гейм-дизайн → Механики и пространство состояний–Макроструктура, нарратив и метагейм. Эта глава — как применить их на практике.

От концепта к pitch

Этап Результат
Game concept одна фраза + желаемый опыт
Понимание рынка 2–3 референса, чем вы отличаетесь
Pitch 1–3 минуты устно или One-Page для команды/преподавателя

Pitch не заменяет прототип: слушатель должен увидеть playable, если речь о геймплее.

Шаблон One-Page — в Гейм-дизайн. Общие этапы продакшена — Процесс разработки видеоигр.

Правила прототипа (Kelly Guidelines)

Kelly Guidelines — набор правил прототипирования (Tadhg Kelly, блог Games from Within). Суть — дисциплина эксперимента:

Принцип Практика
Один вопрос "Интересен ли stealth + сбор на одной арене?" — да/нет после playtest
Быстро и дёшево часы–дни, placeholder-арт, одна сцена
Не vertical slice не "кусок финальной игры", а лаборатория
Одноразовый готовность выбросить код после ответа
Самый рискованный кусок первым то, в чём вы не уверены, а не меню настроек
Типичная ошибка

"Прототип" на полгода с половиной систем и красивым UI — это уже pre-production, а не проверка гипотезы. Если нельзя назвать один вопрос прототипа — scope размыт.

Виды прототипов

Тип Когда Пример
Бумажный правила, экономика, ходы карточки боя на столе
Digital greybox feel, пространство, loop кубы в Unity, без арта
Clickable / wireframe UX, flow меню Figma, схема экранов
Vertical slice убедить издателя, не первая проверка поздний этап

Для курса "Unity + C#" обычно достаточно greybox по главе 3; быстрые скрипты движения, сбора монет и UI — Unity C# — скрипты в Lab.

Итеративный цикл

гипотеза → прототип → playtest → вывод → следующая гипотеза
  1. Гипотеза — связана с механикой, системой или loop.
  2. Сборка — минимум для ответа "да/нет" или "скучно/залип".
  3. Playtest — 2–5 человек, не из команды, 10–20 минут.
  4. Заметки — что делали, где застряли, что чувствовали.
  5. Решение — pivot, iterate или stop.

Documenting design — короткий log в wiki или design/log.md — дата, гипотеза, наблюдения, решение. GDD растёт после подтверждённого ядра.

Design playtest vs QA

Design playtest (эта глава) QA (Тестирование игр)
Когда ранняя и середина разработки pre-release, регрессии
Цель fun, clarity, balance, loop баги, краши, платформы, perf
Кто свежие игроки, мало контекста QA-чек-листы, повторяемость
Вопрос "Хочется ли играть дальше?" "Сломалось ли по спецификации?"

Оба нужны. Playtest без фиксации багов допустим на greybox; перед релизом — только QA недостаточно, если loop скучный.

Вопросы наблюдателя на design playtest

  • Понял ли игрок цель без объяснений?
  • Где застрял или бросил?
  • Какую стратегию выбрал первой?
  • Повторил бы ещё один раунд сразу?

Масштаб для учебного проекта

Совет Зачем
Короткий цикл 1–2 недели на playable, не семестр на меню
Один жанровый жест стелс, платформ, сбор — не "всё сразу"
Портфолио 2–3 законченных маленьких прототипа лучше одного недоделанного "MMO"
Рефлексия в README — core loop, что узнали из playtest

После "щёлкающего" прототипа расширяйте One-Page → GDD; TDD — когда растёт кодовая база (Гейм-дизайн).

Когда остановить итерации

Итерации заканчивают, когда:

  • core loop стабильно интересен разным playtester’ам;
  • главные риски (управление, камера, win condition) сняты;
  • команда готова инвестировать в контент и polish.

Дальше — production по Процесс разработки видеоигр, QA по Тестирование игр.

Дальше по маршруту