Наконец, участники дебатов не должны бояться друг друга. Дискуссия легко может уйти не в то русло в случае дисбаланса власти. Человек, у которого меньше полномочий, не будет честно спорить из-за страха возмездия. Вот почему дебаты лучше всего проводить среди людей, которые вообще не имеют власти друг над другом. Чтобы начальник мог вступать в дебаты со своими подчиненными, он должен сначала доказать свою беспристрастность. Некоторые начальники этого не делают. Они наказывают людей за несогласие, иногда делая это невольно, злобно вздыхая или закатывая глаза. Такое поведение заставляет людей мягче относиться к плохим идеям начальника, что делает дебаты менее полезными.
Тестирование
Мы уже рассматривали плейтестинг. Это самый важный, но не единственный вид тестирования игр. Существуют различные виды тестирования, каждый из которых дает различные виды информации.
Термин
Метрики
В геймдизайне термин «метрики» относится к данным, которые автоматически собираются из игровых сессий. Игра может записывать информацию о разграбленных объектах, проваленных заданиях, времени завершения, побежденных врагах, исследуемых областях или сотне других событий. Метрики можно получить на основании результатов сотен внутренних тестировщиков или миллионов игроков, играющих в общедоступную бета-версию. Затем компьютеры обрабатывают все эти числа в статистических отчетах и графиках, а дизайнеры используют их для принятия проектных решений.
Метрики помогают дизайнерам увидеть паттерны и дисбалансы, которые можно пропустить в плейтестах. Например, в файтинге метрики покажут, что один персонаж выигрывает у другого в 55 % случаев, потому что он может выбирать тысячи матчей. Подобные точные данные нельзя получить на основании плейтестинга, поскольку размер выборки слишком мал. Вот почему метрики неоценимы при тонкой настройке. Не умея видеть маленькие достижения, вы будете замечать только большие изменения в результатах, и прогресс становится прерывистым и неритмичным. Показывая даже небольшие изменения в сложности или ритме, метрики позволяют нам подниматься вверх размеренными шагами и достигать успеха.
Кен Бердвелл пишет о своем опыте использования метрик для тонкой настройки Half-Life:
«К середине проекта, когда основные элементы были созданы и можно было пройти большую часть игры, дело в основном оставалось за тонкой настройкой. Для этого мы добавили в игру базовые инструменты, автоматически записывая положение игрока, его здоровье, оружие, время и любые другие важные действия, такие как сохранение игры, смерть, травмы, прохождение квеста, бой с монстром и так далее. Затем мы взяли результаты нескольких сессий и собрали их воедино, чтобы найти проблемные места. Они включали области, где игрок пробыл слишком долго без каких-либо стычек (скучно), слишком долго со слишком большим количеством здоровья (слишком легко), слишком долго со слишком небольшим количеством здоровья (слишком сложно), и все это дало нам хорошее представление о том, где персонажи игроков, скорее всего, умрут и какие позиции наиболее выгодны для добавления функциональных возможностей».
Когда в 1998 году был разработан Half-Life, занимаясь балансом, другие студии полагались на предположения и самостоятельное тестирование. Эти методы полезны на ранних стадиях разработки, но они не позволяют детализировать более подробные данные, необходимые для идеального баланса степени сложности. Благодаря метрикам качество дизайнерских решений принесло огромное преимущество разработчикам Valve. И им не нужно было быть умнее всех, чтобы создать лучшую игру, потому что они работали на свету, а все остальные работали в темноте.
В дополнение к корректировке метрики также позволяют дизайнерам находить редкие пиковые ситуации. Возможно, 20 привлеченных вами тестировщиков не найдут эту вырожденную стратегию, но если ее обнаружит один из миллиона игроков в общедоступной бета-версии, то это будет отображаться как пик данных.