Под дизайнерским мышлением понимают набор стратегий дизайна, ориентированных на пользователя, его возможности и ограничения. Эти стратегии используются для решения проблем, поэтому прежде всего необходимо понять, какие проблемы самые серьезные. Данный подход отражает суть человеко-ориентированного дизайна (ЧОД) и, по словам Дона Нормана [2013], «гарантирует удовлетворение потребностей пользователя, ясность и удобство конечного продукта, выполнение им необходимых задач, а также позитивный и приятный опыт использования». Игры же, помимо этого, должны быть интересными и вовлекательными.
В игровой индустрии ЧОД иногда называют игроко-ориентированным подходом [Fullerton, 2014], то есть в процессе разработки учитывается пользовательский опыт. Этот подход строится на итерационном цикле, который повторяют, пока дизайн не достигнет удовлетворительного состояния. Данный цикл включает в себя, среди прочего, прототипирование идей, тестирование с участием репрезентативной выборки из аудитории и итеративный поиск.
Согласно Норману [2013], итерационный цикл состоит из наблюдения, порождения идей, прототипирования и тестирования, а также предусматривает принятие неудач. Терпеть неудачи необходимо как можно раньше и чаще, чтобы каждая итерация была плодотворной и в итоге вела к желаемому дизайну. Однако многие разработчики (включая руководителей) этого утверждения не понимают. «Почему хорошие дизайнеры не делают все как надо с первого раза? За что им платят? – часто слышу я от не-дизайнеров, которые потом добавляют: – Даже я сделал бы лучше. Это ведь очевидно. Я уже знаю, как нужно все поправить».
Да, конечно, опытный гейм-дизайнер может подготовить хорошую почву, применяя принципы дизайна, юзабилити и ЧМИ, однако создать классный опыт с первого раза невозможно, поскольку пользовательский опыт рождается у пользователя, а не является неотъемлемой частью дизайна [см. Hartson, Pyla, 2012]. Я сама не гейм-дизайнер, но занимаюсь главным образом тем, что помогаю гейм-дизайнерам понять, какой пользовательский опыт они создают. И, уверяю вас, критиковать дизайн постфактум всегда легче (ретроспективное искажение в действии). Как говорится, не ошибается только тот, кто ничего не делает.
И, конечно, идеи бывают у всех, в том числе у игроков. Но идея – это даже не 15 % работы и тем более не половина. Значение имеет только реализация. Как говорит предприниматель Гай Кавасаки, «Придумать легко, воплотить трудно». Классная идея, воплощенная так себе, в итоге хуже, чем простенькая, но тщательно проработанная. В конечном счете значение имеет не то, о чем думали создатели, а то, какой опыт получит пользователь. Именно поэтому все, кто говорит об «очевидности», заблуждаются (см. главу 10 про заблуждения о UX).
Далее, как подчеркивает Дон Норман, дизайнерское мышление нацелено на поиск не решений, а объективных проблем, мешающих реализовать задуманный опыт. Необходимо учитывать все возможные варианты и выбирать из них те, которые подходят проекту больше всего. Часто выбранное решение неидеально, но главное, чтобы оно отвечало вашим дизайнерским намерениям. Разработчики из Supercell в интервью для VentureBeat рассказали, что отменили 14 проектов, прежде чем добились успеха со своей четвертой игрой – Clash Royale [см. Takahashi, 2016]. Дизайнерское мышление – это поиск нужных компромиссов в процессе цикла разработки, а иногда даже в рамках всей студии.
В следующем эссе ведущий игровой технолог Oculus Story Studio Джон Баллантайн делится интересными трудностями UX-дизайна в виртуальной реальности, а я далее приведу еще ряд примеров того, как UX-процессы могут повлиять на дизайн. Углубляться в дебри гейм-дизайна, интерактивного дизайна и дизайна интерфейса я, впрочем, не стану (повторюсь, это не моя зона компетентности). Поэтому вся глава скорее посвящена процессу дизайна в широком смысле с точки зрения UX.
Джон Баллантайн, ведущий игровой технолог в Oculus Story Studio
Трудности UX-дизайна в виртуальной реальности
Виртуальная реальность (VR – virtual reality) предъявляет много неожиданных требований к контенту – не в последнюю очередь потому, что, в отличие от большинства других сред, в VR пользователь присутствует «лично». Именно это заставило нас в Story Studio вывести UX-дизайн на первый план.
Возьмем для примера следующую ситуацию: разработчики всегда исходят из того, что рост персонажа игрока неизменен (например, в Мастере Чифе, главном герое игр серии Halo, два с лишним метра). Однако в VR играют люди разного роста, и поскольку система считывает их положение, данная разница отражается в самой игре. Таким образом, игрок может либо «парить» над полом, либо «тонуть» в нем, что вызывает замешательство. И чтобы верно расположить пользователя относительно поверхности, приходится регулировать высоту камеры, подстраиваясь под его реальный рост.
Однако оказывается, что такие изменения фактического роста персонажа иногда приводят к неожиданным последствиям. Например, у слишком высокого игрока могут сломаться скрипты, но такое происходит редко. Гораздо чаще бывает так, что пользователь не чувствует себя «героем», поскольку, будучи невысоким по жизни, остается таким же в игре. И правда, как ощущать себя Мастер Чифом, когда ты на голову ниже всех NPC?[51]
В итоге мы пришли к тому, что к тестированию механик и уровней нужно привлекать максимально широкую выборку пользователей. Помимо типичных сегментов, необходимо принимать в расчет различные физические особенности, что открывает путь новым непростым задачам в области UX. Как подстроиться под игроков, которые не могут или не хотят ходить? Как обеспечить достоверное нарративное погружение для людей разного роста? Как сделать убедительного аватара, в котором было бы комфортно и мужчинам, и женщинам?
Эти и другие вопросы создают особенные трудности для нашего процесса разработки. К счастью, практики UX-дизайна предлагают пути выхода. Как и всякая наука, готовых ответов данная дисциплина не дает, но дает алгоритмы, помогающие эти ответы найти.
13.1. Итерационный цикл
Прежде чем переходить к итерационному циклу, необходимо хорошо подготовиться, но углубляться в эти тонкости я не буду. Так, сначала общая задумка игры презентуется руководству студии (или, наоборот, сверху поступает задание на разработку), или небольшая группа разработчиков пробует несколько прототипов и выбирает лучший, или же берется идея из недавнего гейм-джема[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, а не наоборот.
13.2. Аффордансы
Как объяснялось ранее (см. главы 3 и 11), аффорданс подсказывает человеку, какими функциями обладает предмет [Norman, 2013]. Например, за ручку на чашке можно взяться. Аффорданс – это важное понятие для игрового дизайна и UX в целом: он интуитивен, а значит, его не нужно заучивать (и, соответственно, вспоминать), и на его обработку не требуется много ресурсов внимания. Чем больше в вашей игре явных аффордансов, тем меньше нужно объяснять. Это способствует потоку и повышает уровень юзабилити. Поэтому следует довести до ума видимую часть аффорданса (т. е. форму), чтобы он воспринимался и понимался однозначно.
Хартсон [2003] выделяет четыре вида аффордансов.
• Физические аффордансы
Физические аффордансы упрощают манипуляции с объектом. Например, какие-то пивные крышки не нужно открывать открывашкой – их можно просто свинтить. Это физический аффорданс. В видеоиграх проще попасть по кнопке, если она большая. В дизайне мобильных интерфейсов удобно располагать наиболее часто используемые команды рядом с большим пальцем – и так далее. Для создания качественных физических аффордансов полезно применять закон Фиттса (см. главу 10).
• Когнитивные аффордансы
Когнитивные аффордансы помогают пользователям разобраться и понять, что перед ними и как с этим взаимодействовать. Надписи на кнопках, формы иконок, функциональные метафоры и тому подобное – это все когнитивные аффордансы. Принцип «функция определяет форму» касается их в первую очередь.
• Сенсорные аффордансы
Сенсорные аффордансы связаны с восприятием; с их помощью пользователь что-то видит, слышит и чувствует. Например, крупный шрифт для удобства чтения – это сенсорный аффорданс. Знаки и обратная связь должны быть заметными, видимыми, читаемыми и слышимыми. Принцип ясности (см. главу 11) касается как раз сенсорных аффордансов.
• Функциональные аффордансы
Функциональные аффордансы – это элементы дизайна, помогающие пользователям выполнять определенные задачи. К функциональным аффордансам относятся сортировка и сравнение предметов в инвентаре, фильтры и закрепление.
Я уже не раз об этом говорила, но повторю снова: проработка аффордансов – один из ключевых аспектов дизайна. Аффордансы помогают игроку понять, как пользоваться интерфейсом. Соблюдайте принцип «функция определяет форму» в отношении знаков и обратной связи. Избегайте ложных когнитивных аффордансов (см. главу 11), которые будут сбивать с толку и раздражать игроков. Например, если область карты недоступна, она не должна выглядеть так, будто туда можно попасть.
По возможности как можно раньше подключайте к работе с аффордансами UX-аналитиков. Легко ли нажимать на кнопки? Насколько видны и понятны знаки и обратная связь? Понимают ли игроки функцию предмета, просто взглянув на него? Могут ли спрогнозировать поведение противника исходя из его внешнего вида? Могут ли догадаться из окружения, какая у них следующая цель, не читая простыни текста? И можно ли упростить выполнение тех или иных задач, дав игрокам дополнительные возможности?
Вам будет легче определить, как максимально интуитивно объяснить игровые функции, если рассматривать элементы геймплея и системы через призму аффордансов. Также во время фазы тестирования аффордансы помогают задавать тестировщикам более конкретные вопросы (например, покажите им снимок экрана и спросите, что делает каждый элемент интерфейса) и быстрее выявлять серьезные проблемы.
13.3. Введение в игру
Вовлечь аудиторию в игру с первых же минут – тонкое искусство, которое стало особенно важным в эпоху free-to-play. Если не захватить внимание игроков быстро, то на их удержание можно даже не рассчитывать. Проанализировав среднее суммарное время, проведенное во free-to-play играх, которые считаются успешными (например, по статистике SteamSpy.com), можно увидеть, что около 20 % аудитории «отваливается» спустя всего час игры. Значит, этот отрезок крайне важен для первого пользовательского впечатления, ведь именно тогда и происходит основное введение в игру.
Не поймите меня неправильно: даже гениальное введение еще не гарантирует успеха. Как было сказано в главе 12, долгосрочное удержание игроков тоже чрезвычайно важно. К тому же введение может продолжиться даже спустя много часов игры при появлении новых механик или систем, которым нужно обучать. Однако в этом разделе мы в основном коснемся только начального обучения.
Как было сказано в главе 12, один из важнейших аспектов потока в играх – это кривая обучения. Необходимо подобрать эффективный способ преподнесения информации. Необходимо пробудить в игроках любопытство. Необходимо дать им почувствовать себя компетентными и автономными, позволяя спланировать свое краткосрочное и долгосрочное развитие. При этом нельзя упускать из виду когнитивную нагрузку, чтобы игроки не переутомились. Кроме того, все должно происходить максимально быстро, ведь люди, не заплатившие за игру заранее, едва ли станут в ней задерживаться. На мобильных устройствах это «окно» может быть весьма коротким – всего несколько минут.
Именно поэтому разработать грамотное, то есть осмысленное (увлекательное) и эффективное, введение и обучение особенно трудно. Один из способов, который мне не раз помогал в достижении этой цели, – составить план введения в игру. Суть в следующем: гейм-дизайнеры перечисляют все элементы и механики, которые должен освоить игрок, затем распределяют их по системным категориям и наконец выделяют самые важные, чтобы уделить им наибольшее внимание. Перечень в итоге получается внушительный, но процесс можно упростить, сосредоточившись только на обязательных механиках и системах, которые игрок должен освоить в первые часы игры. Удобнее всего представить план в виде таблицы: выпишите все элементы в колонку, по одному на строку, а потом заполните остальные колонки.
• Категория (игровая система).
• Приоритет (чтобы выделить наиболее важные аспекты игры).
• Когда (когда нужно обучить этому аспекту; можно использовать нумерацию: «1» – этому нужно обучить в первой миссии или в первые 15 минут игры; «2» – во второй миссии и так далее; совпадающие значения можно будет отсортировать по следующей колонке – порядку обучения).
• Порядок обучения (у каждого элемента должен быть уникальный номер, по которому можно отсортировать таблицу, например: 1.1, 1.2, 1.3, 2.1, 2.2 и т. д.).
• Сложность (насколько сложно, по вашим ощущениям, освоить этот аспект игры).
• Зачем (какой смысл игрокам осваивать этот элемент, как он сделает их более компетентными и поможет достичь целей – так будет проще придумать осмысленный контекст для обучения, например: «Если игрок не научится крафтить оружие, то погибнет от рук монстров»).
• Как (какой метод обучения будет использован: через интерфейс, практическое применение, динамический туториал и т. п.).
• Нарративное обоснование (расположив обучение элементам и механикам в хронологическом порядке, вы сможете прописать сюжетную часть введения).
• Оценка UX-истов (в эту колонку специалисты по UX, если они задействованы, смогут вписать результат первых UX-тестов или ожидаемые трудности, с которыми, предположительно, столкнутся игроки).
Пример готового плана введения в игру вы можете увидеть на рис. 13.1, где в качестве иллюстрации приведены механики из Fortnite. Начните с перечисления игровых элементов, присваивая каждому системную категорию и степень важности (например, 0 = крайне важная информация, 1 = просто важная, 2 = полезная, 3 = если игрок ее упустит, ничего страшного). Далее определите, насколько каждая механика трудна в освоении. Для этого весьма полезно знать свою аудиторию и уровень ее подготовки. Помощь UX-иста тоже будет нелишней. Как правило, если механика распространена во многих играх и в вашей работает так же, то ее, скорее всего, легко освоить (например, стрельба). И наоборот, уникальная либо просто менее стандартизированная игровая механика может оказаться сложной в освоении (например, укрытия).
Составить хороший план действительно непросто, зато он поможет вам лучше понять, какой когнитивной нагрузке подвергаются ваши игроки и не слишком ли много механик изучается одновременно (а по отсортированной таблице это видно сразу). Помните, что обучение, распределенное по времени, эффективнее, чем когда все дается скопом. Наличие плана позволит вам грамотнее распределить учебную нагрузку в зависимости от сложности каждого отдельного элемента (чем она выше, тем меньше других элементов следует вводить параллельно). По возможности избегайте необходимости обучать двум сложным механикам сразу друг за другом. Пронумеровав все элементы, отсортируйте таблицу по этой колонке в порядке возрастания – и вуаля, план введения готов!
Заполнять все колонки по каждому элементу не обязательно, однако пропускать колонку «зачем», особенно для непростых в изучении механик, я настоятельно не рекомендую (используя маркеры типа «легко», «средне», «трудно», вы можете затем быстро отсортировать их по алфавиту). Всем более или менее сложным механикам следует уделять больше внимания. Игрок обязательно должен изучать их в осмысленном контексте и, возможно, периодически освежать. Заполнение колонки «зачем» поможет вам определить, в чем, с точки зрения игрока, смысл освоения этих механик, и как можно раньше внедрить обучение в геймплей.
Рис. 13.1. Примерный план введения в игру
План введения также поможет вам грамотно распределить ресурсы между изучаемыми элементами. Как правило, «простые» механики можно объяснить через текстовые туториалы и даже динамический текст, который выводится, когда игрок не выполняет нужного действия сам (например, подсказка по управлению появляется, только если игрок в течение первых секунд стоит неподвижно). С началом пользовательских тестов план введения, возможно, придется пересмотреть. Иногда оказывается, что те элементы, которые вам казались простыми, игрокам даются с трудом.
Также таблица с планом поможет определить, какие обучающие подсказки выводить и когда. Поскольку вам так или иначе придется напоминать игрокам ранее изученный материал, для этого можно использовать загрузочные экраны. Главное – не выводите слишком много текста и не объясняйте более трех простых вещей за раз, а если на загрузочном экране выводится информация о миссии, ограничьтесь только основными целями. Пути их достижения и предметы, с которыми необходимо взаимодействовать, пусть останутся в соответствующих меню.
Загрузочные экраны для обучения малоэффективны, однако помогают занять игроков, скрашивая томительное ожидание. Впрочем, это дело восприятия.
Ожидание будет казаться короче, если:
• есть анимированная полоска загрузки;
• движение полоски ускоряется (а не замедляется и останавливается);
• игрокам есть чем себя занять на время ожидания (т. е. они не просто созерцают пустой экран).
Например, на загрузочных экранах удобно показывать советы и туториалы, однако полагаться на них слишком сильно все же не стоит. Не забывайте об ограничениях человеческого восприятия, внимания и памяти: игроки не станут вчитываться в длинные тексты, а если и станут, то навряд ли много запомнят.
Данная методика позволит вам быстрее принимать решения и строить гипотезы об игре и ее опыте, которые затем можно тестировать и анализировать. Она также поможет придумать нарративное обоснование, чтобы свести воедино введение в игру и учебный путь игрока. Если же, наоборот, начать с нарратива (а это заманчиво, поскольку все мы любим истории), а затем встраивать введение в готовый сюжет, то возникает риск нарушить кривую обучения и тем самым испортить опыт. Нарративный дизайн, как и любой другой, должен быть подчинен геймплею и пользовательскому опыту, а значит, должен учитывать мотивацию, поток и особенности обучения игрока.