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

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

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

Регулярные плейтесты на протяжении всего проекта постепенно войдут в привычку у членов нашей команды, и к тому времени, когда надо будет провести формальные тесты на этапе продакшена, обилие дополнительных инструментов вас не ошеломит и все пройдет гладко.

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

Просматривая свои записи, я заметил, что многие из них легко попадают в одну из трех категорий.

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

2. Сомнительные места: возможно, надо исправить. То, что не работает или, по крайней мере, работает не так, как предполагалось, – требует тщательной проверки. Эти проблемы могут крыться в самом дизайне (модели дизайнера), в игре (образе системы) или в понимании игры игроком (модели пользователя). Их надо внимательно изучить и найти возможное решение.

3. Предложения: новые идеи. Во время игровых тестов рождается множество идей: они могут либо стать золотой жилой для разработчика, либо вовсе не иметь отношения к тому, чего разработчик пытается достичь. Обсуждая выдвинутые предложения, принимая одни и отвергая другие, мы можем усовершенствовать дизайн нашей игры.

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

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

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

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

Главное правило оценки обратной связи – не занимать оборонительную позицию. Вам знакомо это чувство: кто-то говорит что-то критическое – или это звучит как критика, – и ваши чувства вспыхивают. Мысленно вы кричите: «Что за чушь!» – и начинаете про себя составлять список всех причин, почему это чушь. Вы думаете, что ваши доводы рациональны, но, взглянув на них позже, видите, как сильно они были искажены эмоциями.

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

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

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

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

Чек-лист действий для оценки обратной связи

✓ Смотрите и слушайте.

✓ Все записывайте.

✓ Отнеситесь к отзывам серьезно – не занимайте оборонительную позицию и не отвергайте их слишком быстро.

✓ Можно ли классифицировать отзывы как (1) надо починить, (2) возможно, надо исправить или (3) новая идея?

✓ Запланируйте исправление того, что надо починить.

✓ Оцените, насколько возможные исправления и новые идеи соотносятся с целями вашего проекта.

✓ Внимательно интерпретируйте то, что говорят игроки, руководствуясь тем, что вы видели, пока они играли.

✓ Обсудите обратную связь с соратником.

«Мне понравилось, мне бы хотелось, что, если?..» (I Like, I Wish, What If?..) – это способ получить эффективную обратную связь, разработанный дизайнерской и консалтинговой фирмой IDEO. Во многом этот метод пересекается с техникой сэндвича, которую мы обсуждали в главе 6. Я научился этому методу у гейм-дизайнера и исследователя Денниса Рамиреса, и теперь это основной элемент программы в изучении гейм-дизайна в USC. Эта техника применима, когда дизайнеры тестируют работу друг друга, и она также отлично подойдет для эффективного общения практически по любой теме, включая обсуждение процесса разработки игр или отношений между членами команды.

Техника «Мне понравилось, мне бы хотелось, что, если?..» настолько проста, что едва ли нуждается в каких-либо объяснениях. Просмотрев какую-то творческую работу – возможно, протестировав игру или прочитав проектный документ, – мы формулируем наш отзыв словами: «Мне понравилось, мне бы хотелось, что, если?..» Например: «Мне нравится, как персонаж прыгает, – им удобно управлять в воздухе. Мне бы хотелось, чтобы он поднимался в воздух немного быстрее после нажатия кнопки прыжка. Что, если вы сократите или уберете начало анимации прыжка?»

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

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

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

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

IDEO, дизайнерское агентство, придумавшее эту технику, признает, что коммуникация – ключевой аспект дизайнерского процесса и что даже в трудных разговорах мы должны оставаться в первую очередь товарищами и друзьями – тогда наши проекты будут успешными. Авторы документа Bootcamp Bootleg из Стэнфордского университета говорят:

Дизайнеры полагаются на личное общение и, в частности, на обратную связь во время проекта. Вы запрашиваете отзывы пользователей о вашем дизайне и отзывы коллег о разрабатываемых вами структурах. Вне самого проекта коллеги-дизайнеры должны сообщать о том, как они работают в команде. Лучше всего давать обратную связь от своего лица. Например, «Мне иногда кажется, что ты меня не слушаешь» вместо «Ты не слушаешь ни слова из того, что я говорю». В частности, хороший метод поощрить открытое обсуждение проекта – техника «Мне понравилось, мне бы хотелось, что, если?..»[75]75
  Томас Боз и Дейв Баггероер, Design Thinking Bootcamp Bootleg. https://dschool.stanford.edu/resources/the-bootcamp-bootleg. – Прим. авт.


[Закрыть]

Так что попробуйте технику «Мне понравилось, мне бы хотелось, что, если?..» и посмотрите, насколько она подойдет вам и вашей команде. Это простой, но изысканный способ эффективнее вести диалог в команде и создать атмосферу уважения и доверия.

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

В искусстве существует подход: «Это моя работа: мне не нужно ее объяснять или оправдывать». Но современные художники, похоже, все больше интересуются тем, как их работы воздействуют на людей. Дизайн и искусство все чаще участвуют в социальной рекламе, политической активности и этике. В своей книге «Дизайн как отношение»[76]76
  Элис Росторн. Дизайн как отношение. М.: Музей современного искусства «Гараж», 2021 г. – Прим. ред.


[Закрыть] (Design as an Attitude) дизайн-критик Элис Росторн подчеркивает, что чистота – это «не подлежащий обсуждению компонент желаемого дизайна». Она говорит: «Если у нас есть какие-либо причины чувствовать себя неловко из-за этических или экологических последствий любого аспекта дизайн-проекта – от его разработки, тестирования и производства до распространения, продаж и маркетинга… такой дизайн вряд ли можно будет назвать желаемым»[77]77
  Элис Росторн, Design as an Attitude, с. 123. – Прим. авт.


[Закрыть]. Помимо этого, у искусства есть возможность позитивно влиять на мир, выявляя несправедливость и продвигая равноправие.

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

Глава 13
Концентрическая разработка

Жили-были два часовщика по имени Хора и Темпус. Оба они делали прекрасные часы, и у обоих было много покупателей. Люди заходили в их магазины, и телефоны постоянно разрывались от звонков. Однако с годами Хора процветала, а Темпус становился все беднее и беднее. А все потому, что Хора открыла принцип иерархии…

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

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

Сложные системы могут эволюционировать из простых систем только при наличии стабильных промежуточных форм, составляющих иерархию. Вот почему иерархии так распространены в системах, которые представляет нам природа. Среди всего разнообразия сложных форм время эволюционировать было только у иерархических систем[78]78
  Герберт Саймон, The Sciences of the Artificial, перефразировано Донеллой Медоуз в книге Thinking in Systems: A Primer и Ричардом Лемаршаном. Медоуз и Райт, Thinking in Systems, с. 83. – Прим. авт.


[Закрыть].

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

• В каком порядке это все надо собрать?

• Действительно ли нам все это потребуется для создания замечательной игры?

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

• Что произойдет, если нам потребуется внести серьезные изменения по итогам тестирования или отзывов?

• Соберется ли игра в конце разработки? Если у нас закончится время, все ли части, которые у нас есть, соединятся в единое целое?

Впервые я услышал термин «концентрическая разработка» в 2002 году в разговоре с Джоном Спинэйлом, тогдашним руководителем студии Crystal Dynamics. Сегодня Джон известен тем, что он – управляющий партнер и соучредитель компании JAZZ Venture Partners с опытом работы в качестве инвестора и предпринимателя в области медиа и развлекательных технологий.

Однажды мы с Джоном обсуждали здоровый подход к созданию игр и то, насколько эффективно сначала создавать основные элементы игры, а затем работать над остальными. По моим наблюдениям, такой подход использовали многие отличные команды, с которыми я сталкивался, и Джон назвал такой подход концентрической разработкой. Когда я начал работать с Naughty Dog, то обнаружил, что они работают таким образом уже много лет.

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

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

Рис. 13.1. Концентрическая структура замка

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

Для игр с персонажем игрока, которым непосредственно управляет игрок, основные механики составят наши три C: персонаж, камера и управление. Вот только в этот раз рассматриваем только то управление, которое влияет на перемещение персонажа. Этими механиками могут стать:

• элементы управления движением и камерой в игре с видом от первого лица;

• алгоритмы перемещения персонажа игрока и камеры в сайд-скроллерах;

• элементы управления движением персонажа игрока и камеры в игре с видом от третьего лица.

В играх без персонажа игрока я первым делом обращаю внимание на механику, с которой игрок взаимодействует напрямую:

• механика перемещения камеры по карте и взаимодействие в один клик для стратегической игры в реальном времени;

• наиболее часто используемые механики взаимодействия в игре-головоломке;

• основы анализатора текста в текстовых приключенческих играх.

Вам, дизайнеру, решать, каковы основные механики вашей игры. Выберите то, что, по вашему мнению, обеспечит прочную основу для геймплея. Разобраться с основными механиками обычно не так уж сложно. Например, в Tetris основные механики – летящие вниз тетрамино и возможность перемещать их влево и вправо и вращать по часовой стрелке и против нее. В SimCity это возможность укладывать дорожную плитку, строить инфраструктуру или зонировать пространство. В Sims – возможность управлять конкретным персонажем и взаимодействовать с конкретным объектом. В Dance Dance Revolution основные игровые механики в то же время самые простые части геймплейного цикла: стрелки, бегущие по экрану, и возможность нажать на кнопку, как только стрелка доберется до нижней части экрана.

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

В игре с персонажем игрока предстоит реализовать очень многое, чтобы добавить в игру персонажа, камеру и управление движением. Для 2D-игры мы должны спроектировать персонажа и создать анимацию состояния бездействия и движения. Для 3D-игры мы должны создать модель персонажа игрока, ее текстуру, создать анимацию бездействия и ходьбы или бега. Мы должны подключить элементы управления игрой так, чтобы входные данные приводили к движению в игре, и мы должны создать алгоритмы управления камерой. Для игр без персонажей игрока аналогичная работа выполняется при создании арта и анимационных ассетов и настройке элементов управления и камеры.

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

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

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

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