Как понять, действительно ли игроки разбираются в вашей игровой механике?
Если вы придумали механику, потому что она кажется оригинальной, проверьте, могут ли игроки самостоятельно понять принцип её работы, спрогнозировать последствия и использовать её для осознанного выбора. Дайте игрокам небольшую задачу, решение которой зависит от механики, и наблюдайте за их действиями, прежде чем давать объяснения. Удачная анимация, правильная догадка после подсказки или слова игрока «я понял» сами по себе недостаточны: каждое из этих проявлений может отражать лишь часть того понимания, которое вы стремитесь проверить.
Определите, что значит «понимание» для данной механики
Прежде чем приглашать кого-либо на тест, сформулируйте задуманное правило механики простыми словами. Затем перечислите решения игрока, которые от него зависят. Например, в некоем платформере есть импульс, отталкивающий близлежащие предметы. Полезный тест может проверить, способен ли игрок обнаружить импульс, определить, на какие объекты он действует, предугадать направление толчка и вовремя применить его. Всё это — раздельные наблюдения: игрок может понять эффект, но не осознать радиус его действия, либо понять и то и другое, но решить, что импульс использовать не стоит.
Такая декомпозиция представляет собой практический план тестирования, а не стандартизированную универсальную шкалу. Она опирается на модель MDA, которая описывает игры через механики, возникающую в процессе динамику и впечатления (эстетику), порождаемые этой динамикой. Данная модель здесь полезна, так как реализация механики — это лишь часть проектной задачи: важно также видеть, что игроки с ней делают и какие ощущения рождает игровой процесс.
Сформулируйте короткий прогноз перед сессией: «Если игроки понимают X, я ожидаю увидеть Y без подсказки Z». Для импульса это может звучать так: «Увидев, как предмет сдвинулся, игрок попробует применить импульс рядом с другим подвижным объектом и встанет так, чтобы направить его в сторону препятствия». Это позволит сосредоточить тест на наблюдаемом поведении, а не на субъективном впечатлении, что участник выглядел вовлечённым.
Организуйте тест так, чтобы игроки проявили собственную ментальную модель
Предоставьте каждому участнику одинаковые начальные условия и задачу, которая делает механику актуальной, не раскрывая при этом готового решения. Избегайте прямых указаний вроде «Используйте импульс, чтобы передвинуть ящик» — это проверяет лишь способность следовать инструкциям. Вместо этого создайте ситуацию, где перемещение ящика — один из разумных путей вперед, и посмотрите, заметят ли игроки импульс и свяжут ли его с объектом.
Если вы хотите узнать, как именно они интерпретируют происходящее, попросите их рассуждать вслух во время игры. Nielsen Norman Group описывает этот метод так: репрезентативные участники выполняют репрезентативные задачи, проговаривая свои мысли, в то время как фасилитатор слушает и побуждает продолжать говорить, не направляя их выбор. Эти рекомендации относятся к тестированию юзабилити в целом, поэтому их применение к игровым механикам — это адаптация метода, а не специфическое для игровой индустрии исследование.
Если игрок замолкает, используйте нейтральные стимулы, например: «О чём вы сейчас думаете?». Избегайте вопросов, прямо намекающих на механику или её суть, таких как «Вы заметили кнопку импульса?». Подобный вопрос превращает проверку самостоятельного обнаружения в проверку узнавания. Если речь во время игры мешает реакции или концентрации, позвольте игроку сначала завершить короткую попытку, а затем попросите описать, чего он ожидал в ключевые моменты. Учитывайте, что ретроспективное объяснение может быть менее надёжным, чем наблюдение за решением непосредственно в процессе игры.
Наблюдайте за действиями, прогнозами и реакцией на ошибки
Фиксируйте факты в соответствии с заранее сформулированными критериями. Полезно отмечать: применил ли игрок механику самостоятельно, какую цель выбрал, какой исход ожидал, совпал ли результат с прогнозом и что игрок предпринял в случае неожиданного исхода. Если игрок случайно применил импульс с успехом, но не может предсказать результат при второй попытке, первый успех не свидетельствует об устойчивой ментальной модели.
Когда появится возможность сделать паузу без срыва игрового процесса, задайте вопрос на прогнозирование перед следующей попыткой: «Как вы думаете, что произойдет, если применить это здесь?». После этого дайте игроку возможность действовать. Это покажет, может ли игрок перенести правило на новую ситуацию, а не просто повторить показанное действие. Формулируйте вопросы открыто и кратко; объяснение правила перед вопросом исказит результаты проверки.
Отделяйте понимание механики от других возможных препятствий. Игрок может усвоить правило, но пропустить нужную кнопку управления, не заметить важный объект или столкнуться с ограничениями геометрии уровня. Фиксируйте это как разные наблюдения. Если управление интуитивно непонятно, сессия не даст ответа на вопрос, понятна ли сама механика. Вносите изменения по одному за раз в последующих сборках или сессиях, чтобы точно знать, какую именно проблему устранила правка.
Ведите компактный протокол наблюдений
После каждой сессии обобщайте наблюдения, избегая размытых оценок вроде «всё понял». Эта небольшая матрица служит наглядным ориентиром, а не формализованным тестовым инструментом:
Не смешивайте последний пункт с пониманием. Игрок может понимать механику, но избегать её использования; точно так же игрок может восхищаться визуальным эффектом, не осознавая стоящего за ним правила. Оба вывода важны, но требуют принципиально разных дизайнерских решений.
Анализируйте закономерности перед внесением изменений
Ищите повторяющиеся сбои и контекст, в котором они возникают. Если игроки не пытаются применять механику, проверьте доступность её обнаружения: индикаторы управления, визуальные акценты и даёт ли уровень повод для экспериментов. Если попытки есть, но результат трактуется неверно, обратите внимание на обратную связь и логичность правил. Если прогнозы точны, но механику игнорируют при наличии альтернатив, оцените, влияет ли она значимо на выбор или другое действие просто выгоднее. Это диагностические гипотезы, а не окончательные выводы; сопоставляйте их с тем, что реально происходило во время сессии.
Не проецируйте результаты нескольких сессий на всю аудиторию. Качественное наблюдение помогает выявить места, вызывающие замешательство, и наметить пути доработки, но само по себе не показывает, насколько эта проблема масштабна среди всех игроков. Протестируйте исправленную версию на той же задаче и проверьте поведение как в новых ситуациях, так и в той, где проблема возникла впервые. Если в дальнейшем потребуется сравнить показатели или предпочтения, используйте более широкую, репрезентативно подобранную выборку и метрики, предназначенные для количественного анализа.
Практическое правило завершения тестирования
Для раннего прототипа доработку объяснений можно прекратить, когда несколько представителей целевой аудитории могут обнаружить механику, предсказать её действие как минимум в одной ранее не встречавшейся ситуации и использовать её для достижения цели без наводящих подсказок — при условии, что оставшиеся ошибки связаны с конкретными, устранимыми деталями, а не с непониманием принципа её работы. Точное количество сессий зависит от проекта и цены принимаемых решений; универсального порога в упомянутых источниках не задано.
Цель теста — не доказать остроумие вашей идеи. Она в том, чтобы выяснить, доносит ли игра правила и создаёт ли возможности для задуманных решений. Если игроки понимают механику, но она всё равно кажется им скучной, это тоже ценный результат: возможно, концепции требуется иная роль, иная награда или другой контекст.