Игровая разработка без боли и кранчей. Как выжить в игровой индустрии и сохранить вдохновение - Ричард Лемаршан
Будьте терпеливы друг к другу, пока вы прокладываете себе путь через этот непростой процесс. Если вы цените чужие усилия и помогаете друг другу в трудностях, вертикальный срез обретет в ваших глазах такую же ценность, как и в моих – важного инструмента в практике здоровых процессов гейм-продакшена и воплощения единства дизайна, ремесла и искусства.
* * *В следующей главе мы рассмотрим строгий метод игрового тестирования, вдохновленный процессом, который мы использовали в Naughty Dog. Он поможет вам получить наилучшие результаты от итеративного дизайна, используемого при создании вертикального среза.
Глава 12
Проведение плейтестов
Плейтесты лежат в основе производственного процесса игр. Я уже дал вам несколько простых рекомендаций по проведению плейтестов в главе 5. В этой главе мы рассмотрим здоровую практику тестирования, которой вы сможете пользоваться на протяжении всего проекта, и заложим основы «формальных» процессов плейтестинга, которые обсудим в главах 24 и 25.
Конечно, по мере разработки мы и сами проводим плейтесты своих игр. Большинство разработчиков делают это автоматически во время работы, время от времени запуская игру, чтобы увидеть, как все выглядит, звучит и играется. Не менее полезно регулярно проводить быстрые игровые тесты с кем-то еще – товарищем по команде, другом или прохожим, – чтобы проверить, как «приземлится» ваша игра на ожидания реальных игроков.
Мне нравится это выражение – «приземлиться», которое я подхватил где-то по пути. Творческие люди всех мастей используют его, когда говорят о том, как другие воспринимают их работу. Когда что-то «приземлилось», создается опыт. Этот опыт может быть желанным: если моя игра вам приглянется, я увижу, что она вам нравится, что вы понимаете, как она работает, и можете постепенно совершенствовать в ней свое мастерство, что вы хотите играть еще, а ваш интерес не угасает. В таком случае опыт покажется вам приятным и вы будете его ценить. Если моя игра не приземлится на ваши ожидания, множество факторов так и будут кричать о том, что вы хотите выключить все это. Возможно, вас расстроит то, что, похоже, вы не понимаете эту игру – или понимаете ее неверно. Или игра покажется вам слишком сложной, и вы не увидите никакого способа развить навыки, необходимые для достижения лучших результатов. Может, она вообще не придется вам по вкусу и вы пожалеете о потраченном времени. Эта обширная область субъективного опыта – то, на что мы обращаем внимание, проводя плейтесты.
Гейм-дизайнер Таня Шорт упоминает «читаемость» систем. Большинство игр представляют собой системы правил, ресурсов, процедур и отношений, и для понимания игровой системы они должны быть читаемыми: представлены таким образом, чтобы их смысл был ясен. «Читаемость позволяет игроку декодировать новый язык, которому игра пытается его научить»[62]. Читаемость игры – это еще один критерий, который мы проверяем при тестировании.
Модель дизайнера, образ системы и модель пользователя
В рамках беседы о читаемости и понятности игр я предпочитаю концепцию модели дизайнера, образа системы и модели пользователя. Все они взяты из очень важной книги юзабилити-дизайнера и психолога Дональда А. Нормана «Дизайн привычных вещей»[63]. Эта книга любима гейм-дизайнерами и UX-дизайнерами. Ведь она дает представление о том, как люди воспринимают системы и взаимодействуют с ними.
По мнению Дона Нормана, модель проектируемой системы – это то, как дизайнер видит игру (или любую другую интерактивную систему). Это «концептуальное представление разработки самим дизайнером». Образ системы – это то, как игра на самом деле представляется игроку. «Образ системы основывается на ее физической структуре (включая документацию)»[64]. Дизайнер надеется, что образ системы близок к его модели, но на самом деле это может быть совсем не так, особенно на ранней стадии разработки.
И, наконец, модель пользователя – это то, что происходит в голове играющего. «Ментальная модель пользователя создается в результате взаимодействия с продуктом и образом системы»[65]. Но при этом пользователь привносит собственный опыт, предубеждения и способность интерпретировать то, что ему дает образ системы (поле восприятия, про которое писал Стив Суинк в книге Game Feel[66]), что может привести к расхождениям между моделью пользователя и образом системы. И если образ системы не совсем соответствует модели дизайнера, то модель пользователя еще больше отдалится от модели дизайнера, как в игре в испорченный телефон, где сообщение с каждым ходом искажается все сильнее. Дон Норман пишет: «Дизайнер ожидает, что модель пользователя будет совпадать с его моделью, но поскольку дизайнер не общается с пользователем непосредственно – коммуникация осуществляется через образ системы»[67].
Для опытных гейм-дизайнеров это становится потрясением: они уже испытали на себе, насколько трудно эффективно общаться с игроками. Концепции и механизмы в наших играх и историях часто сложны и абстрактны, и надежно донести их до наших игроков чрезвычайно сложно. Ситуация становится еще сложнее, когда мы пользуемся непрямыми методами коммуникации.
Чтобы разрешить эти проблемы, нам приходится сообщать игроку одну и ту же концепцию по многим каналам одновременно: по тому, как выглядит система, какой формы и цвета ее элементы, какие ее действия мы видим, что мы непосредственно выражаем с помощью текста или речи, через последовательное обучение. Мы должны распределять релевантную информацию избыточно (сообщая одно и то же по нескольким каналам одновременно), пока все, кто играет в нашу игру, ее не поймут.
Аффордансы и сигнифаеры
Дон Норман описывает, как образ системы сообщается пользователю с помощью аффордансов и сигнифаеров. Концепция аффордансов пришла из работы психолога Джеймса Дж. Гибсона «Экологический подход к зрительному восприятию»[68] и обрисовывает то, как животные используют окружающую среду. Норман развил эту идею в теорию аффордансов, которые
