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

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

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

Тестирование

Мы уже рассматривали плейтестинг. Это самый важный, но не единственный вид тестирования игр. Существуют различные виды тестирования, каждый из которых дает различные виды информации.

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

QA-тестирование выполняется специализированными тестировщиками и направлено на поиск технических ошибок. Оно важно в любом процессе разработки видеоигры.

Термин фокус-тестирование часто ошибочно используется как синоним плейтестинга. Это неверно. Фокус-тестирование – это форма исследования рынка, в которой участники совместно обсуждают различные идеи касательно продукта. Он не требует работающей игры.

Метрики

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

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

Кен Бердвелл пишет о своем опыте использования метрик для тонкой настройки Half-Life:

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

Когда в 1998 году был разработан Half-Life, занимаясь балансом, другие студии полагались на предположения и самостоятельное тестирование. Эти методы полезны на ранних стадиях разработки, но они не позволяют детализировать более подробные данные, необходимые для идеального баланса степени сложности. Благодаря метрикам качество дизайнерских решений принесло огромное преимущество разработчикам Valve. И им не нужно было быть умнее всех, чтобы создать лучшую игру, потому что они работали на свету, а все остальные работали в темноте.

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

Иногда мы можем использовать продуманные метрики для сбора данных, которые на первый взгляд получить невозможно. Например, работая над игрой Halo: Reach, разработчики компании Bungie хотели получить больше информации о влиянии медленной игры в сети на опыт. Игра уже могла записывать файл кинофрагмента, включая каждую игровую переменную в любой момент, включая лаги. Но этого было недостаточно – дизайнеры хотели знать, как игроки воспринимают лаги, которые сложно увидеть в данных. Решить эту проблему с помощью плейтестинга было невозможно, поскольку многие проблемы с лагами встречаются настолько редко, что дизайнерам потребовалось бы огромное количество времени на просмотр достаточного количества плейтестов. Более того, для реального сетевого тестирования требуется, чтобы игроки были рассредоточены, что делает практически невозможным следование традиционным протоколам плейтеста.

Разработчики решили проблему, добавив специальную кнопку: «Я только что увидел лаг». Они регистрировали количество нажатий, а также остальную игру. Как только данные поступали, дизайнеры просматривали изображение и переходили в те точки, где игроки нашли лаг, чтобы точно увидеть то же, что и на экране игрока. Благодаря данному нестандартному методу дизайнеры получили огромное количество достоверной информации о восприятии лагов при относительно небольших затраченных усилиях разработчиков. Таким образом, они решили многие проблемы с восприятием лагов, и Halo: Reach стала отличной сетевой игрой. Разработчики получили прекрасный чистый код, и вовсе не потому, что они были светилами программирования. Как и сотрудники Valve, они работали с большим количеством информации.

Изобретенные методы

На некоторые вопросы невозможно ответить установленными методами. В этих случаях мы должны вернуться к началу и придумать новый способ получения необходимой информации.