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

Методика опроса

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

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

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

Мой любимый вопрос, который я задаю после тестирования, звучит примерно так: «Расскажите историю о том, что только что произошло в игре». Этот вопрос на проверку памяти. С его помощью можно выяснить, какие особенности игры игрок понял, запомнил и посчитал достаточно важными, чтобы их упомянуть. Вещи, которые он не упоминает в своем рассказе, могут быть баластом дизайна. Часто я обнаруживал, что история, которую помнят игроки, очень отличается от того, что я написал, или от того, что произошло на самом деле.

Дизайнер также может адаптировать вопрос, чтобы определить, понял ли игрок конкретную вещь. Не стоит спрашивать: «Вы заметили дверь слева?», потому что сам вопрос дает игрокам подсказку и ответ может быть необъективным. Они чаще всего отвечают «да», просто чтобы не выглядеть глупо или понравиться интервьюеру. Лучше спросить: «Расскажите мне, почему вы выбрали этот путь». Тестировщик либо упомянет про дверь слева и объяснит, почему он не вошел в нее, либо промолчит. В первом случае это говорит о том, что ее заметили и проигнорировали, а во втором – что ее могут вообще никогда не заметить.

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

Тестирование методом «серого ящика»

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

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

Когда компания-разработчик BioWare создала Mass Effect 3, дизайнеры тестировали существ методом «серого ящика». На раннем этапе разработки гигантский боевой робот представлялся в виде большого куба с двумя длинными прямоугольниками внизу и двумя кубами, прикрепленными к бокам для оружия. Другой враг – высокий желтый блок – хватал героя с длинными желтыми блоками, прикрепленными к бокам. Это выглядит странно, но именно так и происходит. Эти «серые ящики» позволили дизайнерам BioWare тестировать и итерировать свои работы, не вкладывая средства в графику непроверенных проектов.

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

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

Что не нужно тестировать методом «серого ящика»

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

Поэтому чем более аудиовизуально насыщенным является игровой опыт, тем менее полезным становится тестирование методом «серого ящика». Такие игры, как LIMBO и Flower, сильно пострадают в «сером ящике», поскольку в основном они основаны на аудиовизуальных эмоциональных триггерах. Однако этот метод весьма хорошо подходит для Counter-Strike и StarCraft II, так как эти игры всегда были основаны на механике.

Преждевременный продакшн

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

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