Текст книги "Игровая разработка без боли и кранчей. Как выжить в игровой индустрии и сохранить вдохновение"

Глава 12
Проведение плейтестов

Плейтесты лежат в основе производственного процесса игр. Я уже дал вам несколько простых рекомендаций по проведению плейтестов в главе 5. В этой главе мы рассмотрим здоровую практику тестирования, которой вы сможете пользоваться на протяжении всего проекта, и заложим основы «формальных» процессов плейтестинга, которые обсудим в главах 24 и 25.

Конечно, по мере разработки мы и сами проводим плейтесты своих игр. Большинство разработчиков делают это автоматически во время работы, время от времени запуская игру, чтобы увидеть, как все выглядит, звучит и играется. Не менее полезно регулярно проводить быстрые игровые тесты с кем-то еще – товарищем по команде, другом или прохожим, – чтобы проверить, как «приземлится» ваша игра на ожидания реальных игроков.

Мне нравится это выражение – «приземлиться», которое я подхватил где-то по пути. Творческие люди всех мастей используют его, когда говорят о том, как другие воспринимают их работу. Когда что-то «приземлилось», создается опыт. Этот опыт может быть желанным: если моя игра вам приглянется, я увижу, что она вам нравится, что вы понимаете, как она работает, и можете постепенно совершенствовать в ней свое мастерство, что вы хотите играть еще, а ваш интерес не угасает. В таком случае опыт покажется вам приятным и вы будете его ценить. Если моя игра не приземлится на ваши ожидания, множество факторов так и будут кричать о том, что вы хотите выключить все это. Возможно, вас расстроит то, что, похоже, вы не понимаете эту игру – или понимаете ее неверно. Или игра покажется вам слишком сложной, и вы не увидите никакого способа развить навыки, необходимые для достижения лучших результатов. Может, она вообще не придется вам по вкусу и вы пожалеете о потраченном времени. Эта обширная область субъективного опыта – то, на что мы обращаем внимание, проводя плейтесты.

Гейм-дизайнер Таня Шорт упоминает «читаемость» систем. Большинство игр представляют собой системы правил, ресурсов, процедур и отношений, и для понимания игровой системы они должны быть читаемыми: представлены таким образом, чтобы их смысл был ясен. «Читаемость позволяет игроку декодировать новый язык, которому игра пытается его научить»[62]62
  Таня Шорт, How and When to Make Your Procedurality Player-Legible, Game UX Summit 2018. https://www.youtube.com/watch?v=r6rTMGFXktI. – Прим. авт.


[Закрыть]. Читаемость игры – это еще один критерий, который мы проверяем при тестировании.

В рамках беседы о читаемости и понятности игр я предпочитаю концепцию модели дизайнера, образа системы и модели пользователя. Все они взяты из очень важной книги юзабилити-дизайнера и психолога Дональда А. Нормана «Дизайн привычных вещей»[63]63
  Дональд Норман. Дизайн привычных вещей. М.: Манн, Иванов и Фербер, 2021 г. – Прим. ред.


[Закрыть]. Эта книга любима гейм-дизайнерами и UX-дизайнерами. Ведь она дает представление о том, как люди воспринимают системы и взаимодействуют с ними.

По мнению Дона Нормана, модель проектируемой системы – это то, как дизайнер видит игру (или любую другую интерактивную систему). Это «концептуальное представление разработки самим дизайнером». Образ системы – это то, как игра на самом деле представляется игроку. «Образ системы основывается на ее физической структуре (включая документацию)»[64]64
  Дональд Норман, «Дизайн привычных вещей», с. 32. – Прим. авт.


[Закрыть]. Дизайнер надеется, что образ системы близок к его модели, но на самом деле это может быть совсем не так, особенно на ранней стадии разработки.

И, наконец, модель пользователя – это то, что происходит в голове играющего. «Ментальная модель пользователя создается в результате взаимодействия с продуктом и образом системы»[65]65
  Дональд Норман, «Дизайн привычных вещей», с. 32. – Прим. авт.


[Закрыть]. Но при этом пользователь привносит собственный опыт, предубеждения и способность интерпретировать то, что ему дает образ системы (поле восприятия, про которое писал Стив Суинк в книге Game Feel[66]66
  Стив Суинк, Game Feel, с. 50. – Прим. авт.


[Закрыть]), что может привести к расхождениям между моделью пользователя и образом системы. И если образ системы не совсем соответствует модели дизайнера, то модель пользователя еще больше отдалится от модели дизайнера, как в игре в испорченный телефон, где сообщение с каждым ходом искажается все сильнее. Дон Норман пишет: «Дизайнер ожидает, что модель пользователя будет совпадать с его моделью, но поскольку дизайнер не общается с пользователем непосредственно – коммуникация осуществляется через образ системы»[67]67
  Дональд Норман, «Дизайн привычных вещей», с. 32. – Прим. авт.


[Закрыть].

Для опытных гейм-дизайнеров это становится потрясением: они уже испытали на себе, насколько трудно эффективно общаться с игроками. Концепции и механизмы в наших играх и историях часто сложны и абстрактны, и надежно донести их до наших игроков чрезвычайно сложно. Ситуация становится еще сложнее, когда мы пользуемся непрямыми методами коммуникации.

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

Дон Норман описывает, как образ системы сообщается пользователю с помощью аффордансов и сигнифаеров. Концепция аффордансов пришла из работы психолога Джеймса Дж. Гибсона «Экологический подход к зрительному восприятию»[68]68
  Джеймс Гибсон. Экологический подход к зрительному восприятию. М.: RUGRAM, 2015 г. – Прим. ред.


[Закрыть] и обрисовывает то, как животные используют окружающую среду. Норман развил эту идею в теорию аффордансов, которые «определяют, как объект может быть использован», и сигнифаеров, которые «определяют, как люди обнаруживают эти аффордансы: с помощью знаков, воспринимаемых сигналов того, что можно сделать»[69]69
  Дональд Норман, «Дизайн привычных вещей». – Прим. авт.


[Закрыть].

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

Люди часто объединяют эти два понятия под термином «аффорданс», но их важно различать. В видеоигре может быть фича, при которой, если я стою неподвижно в определенном месте уровня более пяти секунд, меня автоматически и мгновенно перемещают в другое место. Эта фича – аффорданс: механизм, который приводит к определенному результату. Но если это место на уровне никак не обозначено, это довольно странная фича. Мы не можем найти место автоматического перемещения, разве что это выйдет случайно, но при этом можем без каких-либо объяснений случайно переместиться, если не туда встанем. Если я знаю, что такое место где-то есть, но я не знаю где, тогда, может быть, я смогу найти его путем утомительного метода проб и ошибок. И в таком случае это скорее баг, чем фича.

Однако мы можем разместить платформу в этом месте автоматического перемещения: у платформы будет светиться нижняя панель, которая тихо гудит, но начинает гудеть громче, когда я встаю на нее; на панели отсчитывается время «5, 4, 3…», персонажа игрока охватывает свечение, а само перемещение сопровождается звуковым эффектом, похожим на раскат грома, – вот мы разработали телепорт. Сама платформа, светящаяся панель, звуковые и визуальные эффекты, а также обратный отсчет – все это четко передает действие аффорданса. Сам аффорданс одинаков в обоих случаях, но сигнифаеры смогли превратить бесполезную игровую механику в особенность нашего гейм-дизайна.

К счастью, вы можете изучить эти вопросы читаемости с помощью плейтестов. Просто наблюдая за тем, как играют ваши тестеры, вы можете понять, совпадают или нет модель дизайнера, образ системы и модель пользователя, а также то, насколько успешно аффордансы переданы через сигнифаеры. Задавая дополнительные вопросы, мы сможете лучше понять, как понимают игру наши игроки.

Плейтесты помогут нам также понять, какой опыт переживают люди, играя в наши игры. И хотя этот процесс довольно сложный, поскольку он гораздо более субъективен, мы можем многому научиться, используя те же методы наблюдения за игрой и последующего общения с тестерами. Чтобы узнать, «приземлилась» ли наша игра на ожидания игроков – как с точки зрения читаемости, так и с точки зрения создаваемого опыта, – мы должны следовать нескольким правилам проведения плейтестов.

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

Сведите к минимуму разговор с вашим плейтестером до и во время теста

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

Как плейтестер, так и дизайнер должны быть в наушниках

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

Приготовьте лист бумаги со схемой управления

Хорошо продуманная игра обычно обучает игроков управлению, вводя его элементы по одному и давая игроку возможность попрактиковать каждый из них. Однако в игре на ранней стадии разработки такое обучение обычно не предусмотрено. Некоторые дизайнеры устно объясняют элементы управления, что может повлиять на непредвзятость теста. Для сохранения объективности теста опытные гейм-дизайнеры готовят подсказку, в которой показана схема управления, и показывают один и тот же лист каждому плейтестеру (рис. 12.1). Ее либо показывают один раз в начале теста, либо оставляют неподалеку, чтобы с ней можно было повторно свериться. Опять же, вы не должны разговаривать с игроком до окончания плейтеста.

Рис. 12.1. Подсказка со схемой управления

Подготовьте письменную подсказку, чтобы помочь игрокам преодолеть известные функциональные или геймплейные проблемы

Очень часто в тестируемой игре возникают проблемы, о которых мы знаем и из-за которых мы можем получить плохие отзывы. Может быть, непосредственно перед плейтестом мы поменяли освещение на уровне, и теперь дверной проем, который должен быть легко виден, полностью скрыт в тени. (Такое часто случалось при разработке Uncharted.) Возможно, в игру закрался баг, из-за которого тестер пройдет уровень, только если ему намекнут, что делать. В таком случае самое время воспользоваться письменной подсказкой (рис. 12.2). Запишите информацию, необходимую плейтестеру для решения известной вам проблемы, и затем покажите ее в нужный момент, не говоря ни слова. Как и в случае с управлением, эта подсказка предоставит всем игрокам одинаковую информацию, гарантируя одинаковые условия прохождения теста. Но будьте осторожны: пользуйтесь этим правилом только в чрезвычайных ситуациях, когда вы знаете, что игрок определенно застрянет и не сможет самостоятельно пройти дальше.

Рис. 12.2. Письменная подсказка

Предложите плейтестеру проговаривать вслух чувства и мысли

«Мыслить вслух» при тестировании игры – говорить о впечатлениях и идеях, которые возникают во время игры, – это хороший способ предоставить разработчику информацию об опыте тестера, которую дизайнер не смог бы получить, просто наблюдая. «Чувствовать вслух» – говорить об эмоциях, которые испытывает тестер, – по сути то же самое. Некоторым это дается лучше, чем другим. Дизайнеры должны попросить своих тестеров вслух поговорить о своих мыслях и чувствах, а затем дать им поиграть. Если тестеры не начинают говорить во время игры, предложите им озвучить свои чувства еще раз, а затем оставьте их в покое. Внимательно наблюдая за тестером, вы сможете узнать почти столько же, сколько и внимательно слушая то, что он говорит. И вы заметите, что большинству людей трудно разговаривать во время напряженных моментов игры, когда все их внимание занято геймплеем.

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

Добавьте предупреждение, если это необходимо

Предупреждать о содержимом игры важно, потому что это дает нам свободу добавлять все, что мы посчитаем необходимым, и ограждает от опасности тех, кто не хочет видеть определенный контент. Возможно, из-за исторических ассоциаций, что игры обычно делаются для детей, гейм-дизайнеры иногда неохотно обращаются к так называемой взрослой тематике. Но в видеоиграх как развивающейся сфере развлечений и форме искусства пора полностью пересмотреть этот подход. Предупреждение в начале теста действует точно так же, как и возрастной рейтинг фильма, – так мы можем предупредить людей о наличии любого типа контента, которого они, возможно, пожелают избежать. Найдите в интернете информацию о том, какой вид контента требует предупреждения и как правильно оформить это в игре[70]70
  В общем случае речь идет о наличии насилия и эротики или о том, что может вызвать приступ эпилепсии. – Прим. ред.


[Закрыть].

Будьте внимательны к игровому опыту вашего плейтестера

Внимательно следите за тестером, чтобы увидеть, что он делает в игре. Обратите внимание на его реакции и поведение. Что он, кажется, понимает в том, что можно и чего нельзя делать в игре? Чего он не понимает? Что он пытается сделать, а чего не пытается? Какие эмоции он проявляет?

Записывайте все, что ваш плейтестер делает и говорит

Наблюдая за тестером, тщательно и как можно подробнее все записывайте: что он делает в игре, что он, кажется, думает и чувствует и как он сам описывает свои мысли и чувства. Многие из нас, особенно молодые люди, уверены, что наша память четко и безошибочно фиксирует все события, словно жесткий диск компьютера. На самом деле, как много раз доказывали психологи и ученые-когнитивисты, наша память подвержена ошибкам и сильно зависит от эмоций. Ваши впечатления от того, как тестер пройдет вашу игру и отзовется о ней, сильно повлияют на вашу память о том, что же делал сам игрок. Вот почему вы должны записывать все, что замечаете во время теста. Уже в первые минуты вы должны исписать заметками ваш блокнот, пытаясь ухватить мельчайшую деталь того, что делает тестер. Каждый раз, когда вы видите какой угодно плюс или минус вашей игры, делайте заметки. Затем, когда вы просмотрите их после игрового теста, вам откроется все лучшее в вашей игре и самые большие ее проблемы. Вы будете знать, что действительно работает, а что нужно исправить в первую очередь.

Не помогайте плейтестеру

Это одно из самых фундаментальных, но самых трудно выполнимых правил плейтестов. Мучительно наблюдать за тем, как кто-то играет в игру в процессе разработки, если вам нельзя хоть как-то помочь. Ваши тестеры столкнутся с проблемами в игре, которую вы создали, неправильно поймут механику и сюжет, будут пытаться продолжить и застрянут с концами – соберитесь с духом и храните молчание, старательно сопротивляясь искушению каким-либо образом помочь им. Примите эту боль и сделайте ее мотивацией для внесения исправлений в следующем цикле итерации. Если ваш тестер сам задает вам вопросы или обращается к вам за помощью, извинитесь и скажите – вежливо, но твердо, – что вы не можете помочь и что вы хотели бы, чтобы он продолжил самостоятельно. Это единственный способ четко увидеть, какой отклик находит ваша игра у людей. Единственное исключение из этого правила – письменная подсказка, как было описано выше.

Следите за временем

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

После плейтеста проведите заключительную беседу

Когда время тестирования подойдет к концу, проведите с вашим тестером заключительную беседу. Формат этого разговора выбирайте сами, но у меня есть несколько общих рекомендаций, которые вам помогут. Начните с открытого вопроса, чтобы сфокусировать внимание тестера на интересующем вас аспекте игры. Избегайте вопросов, на которые можно ответить просто «да» или «нет» или, например, числом. Проектный директор и художник Марк Таттерсолл составил список из пяти открытых вопросов, которые можно задать плейтестерам – этот список представила Алисса Макалун на сайте игрового издания Gamasutra[71]71
  Сейчас Game Developer. – Прим. ред.


[Закрыть].

• Какой момент или взаимодействие понравились вам больше всего?

• Какой момент или взаимодействие понравились вам меньше всего?

• В какой момент вы почувствовали себя наиболее сообразительным?

• Было ли что-то, что вы хотели сделать, но чего не позволила игра?

• Если бы у вас была волшебная палочка и вы могли изменить любой аспект игры или испытанный вами опыт, что вы поменяли бы в условиях неограниченного бюджета и времени?[72]72
  Алисса Макалун, 5 Questions You Should Be Asking Playtesters to Get Meaningful Feedback («Пять вопросов плейтестерам, благодаря которым вы получите содержательный отзыв»), Gamasutra, 10 октября 2016 г. https://www.gamedeveloper.com/design/5‑questions-you-should-be-asking-playtesters-to-get-meaningful-feedback. – Прим. авт.


[Закрыть]

Эти вопросы раскроют суть важных аспектов дизайна игры. Что остается в памяти игрока по хорошим или плохим причинам? Когда игрок чувствовал, что он может проявить свободу воли, а когда нет? Какие творческие идеи возникли у игрока, которые вы упускаете из виду? Используя эти вопросы в качестве примера, какие открытые вопросы задали бы вы?

Записывайте все, что скажет в заключительной беседе ваш тестер (с его согласия), либо делая заметки, либо записывая разговор. По мере вашего разговора не заставляйте тестера высказывать какое-либо особое мнение, но следите за тем, что он говорит, – если вы не совсем понимаете какой-то комментарий, но он кажется вам интересным, попросите тестера развить мысль.

Небольшое замечание об особенностях тестирования игр для детей от гейм-дизайнера и продюсера Алана Данга: «Проводить тестирование с детьми довольно трудно: они, как правило, хотят угодить взрослым и не хотят, чтобы с ними ассоциировался негатив. Один из способов обойти это – спросить детей, как они описали бы эту игру своему другу или ровеснику и что, по их мнению, подумал бы об игре кто-то другой»[73]73
  Частная беседа, 10 мая 2020 года. – Прим. авт.


[Закрыть].

Не объясняйте игру

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

Не отчаивайтесь

Тестирование – очень эмоциональный процесс для дизайнеров. Творческие люди обычно вкладывают много сил в то, что они делают. И когда мы показываем наш труд другим людям, то можем почувствовать себя незащищенными, встревоженными или даже запаниковать еще до того, как услышим первые отзывы. Часто противоречивые отзывы от разных тестеров ошеломляют, и в конечном счете мы теряемся в лабиринте нашего дизайна. Эти смешанные чувства сильны даже при тестировании усовершенствованной и хорошо работающей игры – представьте, насколько они сильнее, запутаннее и сложнее с чем-то новым и полным проблем. Если мы не справимся с этими эмоциями, они нас сломают. Заставят нас сдаться, отказаться от игры и начать что-то новое. Или вообще отказаться от гейм-дизайна.

Хороший способ справиться с эмоциями – предвидеть их и быть готовыми бороться с ними любым удобным для вас способом. Вы можете напомнить себе, что игра – это не дизайнер, занять некоторую эмоциональную дистанцию. Никогда не стоит выражать сложные эмоции перед игроком, но и сдерживать их тоже плохая идея – лучше всего найти здоровый способ их выразить. Я призываю гейм-дизайнеров оказывать друг другу эмоциональную поддержку после игрового теста: жаловаться и даже ныть при необходимости, выражая разочарование или печаль от того, что тест прошел не так, как хотелось бы. Выплесните эмоции таким образом, чтобы это не было токсично – зло или гадко, и не было направлено на человека, – и позвольте им уйти в прошлое. Как только вы справитесь с переживаниями, просмотрите ваши заметки. Кропотливо все изучите, чтобы понять, что работает в вашей игре, а что нет. Будьте честны с собой и признавайте как свои успехи, так и неудачи. Начните составлять план решения проблем и верьте, что следующий тест пройдет лучше. Так бывает почти всегда. Следуйте совету, который дал Мэтью Фредерик в книге 101 Things I Learned in Architecture School:

Отнеситесь к процессу разработки с терпением. Не подражайте популярным изображениям творческого процесса как зависящего от единственного внезапного прилива вдохновения. Не пытайтесь решить сложную проблему за один присест или за неделю. Примите неопределенность. Признайте нормальным чувство потерянности, которое сопровождает большую часть процесса[74]74
  Мэтью Фредерик, 101 Things I Learned in Architecture School, с. 81. – Прим. авт.


[Закрыть].

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