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