Прежде чем переходить к итерационному циклу, необходимо хорошо подготовиться, но углубляться в эти тонкости я не буду. Так, сначала общая задумка игры презентуется руководству студии (или, наоборот, сверху поступает задание на разработку), или небольшая группа разработчиков пробует несколько прототипов и выбирает лучший, или же берется идея из недавнего гейм-джема[52]. Затем на этапе концепции в общих чертах описывается кор-геймплей (основной геймплей), геймплейный цикл и ключевые элементы. По возможности, определяется целевая аудитория (т. е. игроки), а также дизайнерские и коммерческие намерения (т. е. опыт).

Только после этого начинается полноценный итерационный цикл. Первая его фаза – это препродакшен; именно в ней делается больше всего прототипов. Прототипирование должно продолжаться, пока игра не будет готова. Соответственно, если вы делаете игру с регулярными обновлениями, то итерационный цикл, по сути, не заканчивается никогда. Как пишут Хартсон и Пайла [2012], «большинство интерактивных дизайнов изначально плохи, и команда посвящает все время разработки их итеративному исправлению».

Итерационный цикл создания механики включает в себя дизайн, прототипирование или реализацию, тестирование, анализ и определение необходимых изменений с целью улучшения, после чего цикл стартует заново. Такой «метод осознанных проб и ошибок» [Kelley, 2001] крайне важен. В идеале начинать следует с бумажных (или сопоставимо примитивных) прототипов, затем переходить к интерактивным и только потом реализовывать механику в игре. Предварительное прототипирование выгодно в основном потому, что менять воплощенный в игровом движке дизайн гораздо затратнее, чем подправить дешевый прототип. К тому же человек склонен привязываться к сделанному. Трудно расстаться с механикой, к которой есть код и арт, даже если она не работает так, как планировалось.

Однако главная проблема, как иронично отметил Дон Норман [2013], в том, что «едва только разработка началась, она уже не укладывается ни в сроки, ни в бюджет». Это особенно верно в отношении игровой индустрии, где кранчи – обычное дело. Из-за этого довольно часто механики реализуют, даже толком не продумав, не говоря уже о прототипировании и тестировании… Нет времени! Из-за жестких дедлайнов и/или плохо налаженного техпроцесса разработчикам приходится как можно быстрее впихивать механики, чтобы выпустить игру в срок, надеясь при этом, что она не рассыплется.

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

Как только механика реализована, решиться на радикальные изменения крайне трудно, ведь они по цепной реакции могут затронуть все аспекты разработки. Соответственно, если бумажные прототипы и многочисленные итерации тестирования кажутся вам пустой тратой сил, помните: в конечном счете этот подход сэкономит вам кучу времени и денег. Воспринимайте итеративные циклы как вложение в будущее. Как в своем эссе объясняет Фредерик Маркус, президент Feerik Games (см. ниже), прототипирование «просто работает», особенно если в цикл включен UX-анализ.

UX-истов в итерационном цикле больше всего интересует именно этап тестирования. Он должен опираться на согласованные цели (т. е. как игрок должен воспринимать механику и взаимодействовать с ней), а также принципы и метрики UX. Крайне важен и тщательный анализ результатов тестов. Когнитивным искажениям и скоропалительным выводам подвержен любой разработчик (и даже UX-ист, но тот хотя бы об этом знает). Примеры методов изучения пользователей и советы по исследованиям приведены в главе 14. Помните, что в научных кругах протоколы экспериментов стандартизированы, и не случайно. У игровой студии может не быть роскоши проводить эксперименты по строгому протоколу, однако принципы научного метода необходимо хотя бы понимать и по возможности применять. Помните, что дизайнерское мышление – это поиск решения только для тех проблем, которые действительно в нем нуждаются.

На каком-то этапе разработки игры (лучше перед завершением пре-продакшена, но обычно в основной фазе) итерациям начинают подвергаться не просто отдельные элементы, а их совокупности или игра в целом. Мы от природы склонны добавлять новое, даже когда основной опыт еще не доведен до ума, а ключевые механики не сделаны. Отсюда возникает необходимость вырезать элементы, которые не вполне отвечают желаемому опыту. Дэн Ариэли [2008] замечает, что это трудно, поскольку людям невыносимо себя ограничивать. Однако нужно понять: дело не в количестве элементов и механик, а в глубине игрового опыта. Это положение хорошо иллюстрируется примером с BlackBerry и iPhone. Когда-то именно устройства BlackBerry были флагманами на рынке смартфонов и обладали бо́льшим числом функций, чем первая версия iPhone. Однако продукт Apple сумел быстро занять лидирующее положение.

Простоту часто называют высшим достижением дизайна. Вот только глубина опыта тоже важна, особенно в играх. Соответственно, вы должны определить, без каких элементов геймплей невозможен, а от каких стоит отказаться. Глубина – это хорошо, но при условии, что она не приводит к усложнению или того хуже – к запутанности. Запутанность раздражает, ущемляет чувство автономности игрока и, как следствие, вынуждает его бросить игру (впрочем, то же справедливо и для игр, которым недостает глубины: они слишком скучные).

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

Гейм-дизайн – это поиск компромиссов. Готовых решений нет. Все зависит от условий разработки (время, ресурсы, бюджет и т. д.) и приоритетов. Старайтесь помнить, кто ваш пользователь (порой разработчики добавляют механики из прихоти, а не в интересах аудитории) и какой опыт вы хотите ему дать. Так вам будет проще решить, оставаясь в рамках игроко-ориентированного подхода, чем поступиться или от чего отказаться (иметь все и сразу нельзя) и в каком порядке реализовывать важные с точки зрения UX элементы.

Фредерик Маркус, президент Feerik Games

Пользовательский опыт и прототипирование

Долгие годы я активно и с удовольствием работал над прототипами видеоигр. Медленно, но верно во мне крепло ощущение, что великая игра – это не просто сюжет и геймплей. Оказывается, все аспекты продукта: упаковка, установка на консоль или компьютер, главное меню, сама игра, концовка… Все от цветовой гаммы до звуков относится к пользовательскому опыту и, по сути, этим опытом и является.

Для меня стало открытием (жаль, запоздалым), что в эту область входит изучение поведения человека, работы его мозга, а также огромного количества других дисциплин. Мысль о том, что UX – это недостающее звено между всеми отраслями, существующими ради пользователей, перевернула для меня все. Получается, мы можем перенимать опыт других отраслей, можем подтверждать или опровергать то, что испытывали или наблюдали сами, и на этой основе можем выстраивать техпроцессы.

Кстати о последних: тот факт, что создание видеоигр – это совсем не только и не столько творчество, очень меня заинтересовал. И оказался логичным.

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

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

А знаете, что самое замечательное? Поскольку в UX переплетено столько разных областей, из которых мы многое почерпнули, теперь наша цель – создавать именно пользовательский опыт, а геймплей и сюжет переходят в разряд важных, но все же спутников этого опыта. Главное открытие нашего времени: игра строится вокруг UX, а не наоборот.