Ознакомительная версия. Доступно 26 страниц из 130
их было легче понять. Информационный дизайн и визуализация данных – это перспективные области, достойные внимания гейм-дизайнеров. Книги Эдварда Р. Тафти Envisioning Information и Эллен Луптон «Драматургия дизайна» дают содержательные комментарии о методах, которые мы можем использовать для превращения чисел в нарратив, понятный людям.
Многие учатся представлять данные еще в школе, создавая линейные графики, гистограммы и круговые диаграммы, – и это отличные подходы к визуализации метрических данных. Каждая программа для работы с электронными таблицами включает в себя инструменты для создания графиков из таблиц данных. Их освоение может занять немного времени, но обычно они просты в использовании и эффективны. Не забудьте обозначить оси, включить легенду, чтобы четко описать представленные данные, и использовать выделение цветом. Таблицы с данными особенно эффективны, когда в них используется условное форматирование для выделения важных чисел, отчего те «выстреливают», как показано на рис. 26.1.
Другой популярный тип визуализации игровых метрик – тепловая карта, двух- или трехмерное представление мест на уровне, где в ходе игрового процесса произошло конкретное событие. Вы можете применить инструменты построения графиков в электронной таблице для создания этой карты или запрограммировать специальный инструмент внутри вашего игрового движка для точного отображения окружения игры. Поищите в интернете «тепловые карты игр», и найдете множество примеров из ваших любимых игр.
Старайтесь мыслить нестандартно и руководствоваться особенностями и возможностями дизайна выбранного типа игры. Как игровые метрики помогут вам стать более уверенными в том, что ваша игра развивается так, как вы намеревались? Что станет вашей «системой плохих прыжков» и как метрические данные помогут вам разрешить непростую проблему новаторским способом?
Чек-лист действий по внедрению систем данных
✓ Проведите мозговой штурм на предмет того, какие данные вам пригодятся для дальнейшего улучшения игры.
✓ Продумайте механизм записи этих данных (просто в текстовый файл или в базу данных).
✓ Получите согласие ваших плейтестеров на сбор метрических данных.
✓ Проверьте, работает ли система сбора данных, сыграв в игру в тех же условиях (или максимально приближенных к ним), в которых будет проходить формальный плейтест.
✓ Проверьте исправность систем сбора данных, просмотрев информацию, которая была выведена системой во время плейтеста.
✓ Используя тестовые данные, начните разрабатывать способы их визуализации для дальнейшей работы с ними.
✓ Протестируйте систему еще раз непосредственно перед формальным плейтестом.
✓ Используйте систему сбора данных в формальных плейтестах.
✓ Визуализируйте данные, которые получите во время плейтестов, и используйте то, что узнаете о поведении ваших плейтестеров, для улучшения дизайна игры.
Границы использования игровых метрик
Игровые метрики – это инструмент, и, как и любой инструмент, их можно использовать как во благо, так и во вред. Быть строгим в такой технической форме искусства, как наша, необходимо, и UX-исследователи ценят научный подход. Но я твердо верю, что вам не следует использовать эти техники больше, чем вам подсказывают инстинкты креативного дизайнера и художника.
Я использую метрики, чтобы убедиться, что моя игра дает игрокам тот опыт, который я хочу им дать. Я пытаюсь обнаружить наличие того, что может помешать моей игре достичь желаемого результата. Я сопротивляюсь искушению следовать за метрическими данными в том направлении, которое противоречит целям моего проекта или моим личностным ценностям. Вам придется решить для себя, в зависимости от того, кто вы, что вы цените и в каком контексте создаете игры – коммерческом, художественном или академическом, – в какой мере собираетесь использовать игровые метрики.
Мне нравится эта цитата, часто приписываемая Альберту Эйнштейну, но, скорее всего, принадлежащая социологу Уильяму Брюсу Кэмерону: «Не все, что можно сосчитать, считается, и не все, что считается, можно сосчитать»[162]. Вам решать, что считать, а что считается.
Глава 27
Альфа-фаза и отслеживание ошибок
В процессе создания игр на этапе продакшена есть два майлстоуна: альфа и бета (рис. 27.1). К альфе, в середине этапа продакшена, наша игра будет завершена с точки зрения фичей конкретных отрезков геймплея, так что мы сможем пройти ее полностью, пускай и с плейсхолдерами. К бете, в конце этапа продакшена, игра будет закончена в плане своего контента, а значит, все, что должно быть в игре, уже будет в ней, готовое к доработке.
Рис. 27.1. Этапы альфа- и бета-версий в процессе производства. Авторы изображения: Габриэла Пурри Р. Гомес, Мэтти Розен и Ричард Лемаршан
Но в этапе полного продакшена есть еще две фазы: разработка альфа-версии (альфа-фаза) и разработка бета-версии (бета-фаза). В главе 23 мы говорили об обеспечении качества: эксперты QA-отдела тщательно тестируют игру, выискивая возможные баги и помогая дизайнерам их устранить. В почти универсальном определении альфа-фазы значится, что этот этап начинается, когда проект попадает на QA-тестирование. Этап альфа-фазы заканчивается майлстоуном альфа-версии, а затем начинается бета-фаза, которая в итоге приведет нас к очередному майлстоуну. Даже если у вас нет специального QA-отдела, ваш проект все равно может надлежащим образом пройти этап альфа-фазы, если вы просто начнете отслеживать ошибки в игре. Сейчас мы рассмотрим методы отслеживания ошибок.
Когда какая-то часть программного обеспечения находится на стадии альфы, оно иногда глючит, нестабильно и по большей части неполно. Но в разработке игр глючное и нестабильное программное обеспечение крайне нежелательно. Нужно поддерживать нашу игру в играбельном состоянии на протяжении всего производства. Таким образом, каждый раз, когда мы добавляем новую механику или какой-то контент, мы должны проводить плейтест, чтобы оценить влияние нововведений на игру в целом. Вот почему мы разрабатываем концентрическим методом, который мы обсуждали в главе 13.
Ознакомительная версия. Доступно 26 страниц из 130
