Геймдизайн. Рецепты успеха лучших компьютерных игр от Super Mario и Doom до Assassin’s Creed и дальше - [124]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

«СЕРЫЙ ЯЩИК» – это черновой прототип игровой механики, системы или уровня.

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