---
id: scope-and-prototype
lang: ru
title: Скоуп и проверяемый прототип
description: >-
  Выбираем один вопрос, ограничиваем объём работы и решаем, что делать после
  проверки прототипа.
category: design
level: beginner
minutes: 6
updatedAt: '2026-10-20'
tags:
  - scope
  - prototyping
  - playtesting
sources:
  - title: 'Unity Learn: Prototyping'
    url: 'https://learn.unity.com/pathway/creative-core/unit/prototyping'
url: 'https://gamemechanics.pro/ru/lessons/scope-and-prototype/'
markdownUrl: 'https://gamemechanics.pro/content/ru/scope-and-prototype.md'
license: CC-BY-4.0
codeLicense: MIT
attribution: gamemechanics.pro contributors
---

## Что нужно знать

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

## Принцип

Прототип полезен, когда уменьшает конкретную неопределённость. «Сделать рогалик» не говорит, что проверять. «Понимает ли игрок разницу между двумя атаками по предупреждению?» задаёт наблюдаемую задачу. [Unity Learn: Prototyping](https://learn.unity.com/pathway/creative-core/unit/prototyping) предлагает выбирать подход к прототипу под вопрос проекта.

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

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

<span id="пример-читается-ли-атака"></span>

## Практический пример

### Читается ли атака

Составьте карточку эксперимента до разработки:

```text
Вопрос: различимы ли два предупреждения перед атакой?
Материал: одна арена, один враг, две атаки, быстрый рестарт.
Бюджет: один вечер на сборку, затем короткая проверка.
Наблюдение: какую атаку ожидает человек до её начала?
Критерий продолжения: 8 верных ответов из 10 после обучения.
Если не проходит: изменить один сигнал и повторить проверку.
Стоп: после двух вариантов пересмотреть сами атаки.
```

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

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

## Частые ошибки

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

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

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

## Проверка результата

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

## Задание для ИИ-агента

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