Игровая разработка без боли и кранчей. Как выжить в игровой индустрии и сохранить вдохновение - Ричард Лемаршан
2. Это отличная возможность использовать технику сэндвича (глава 6) и «Мне понравилось, мне бы хотелось, что, если?..» (глава 12), чтобы установить доверительную атмосферу, полную уважения к работе дизайнеров, и приступить к коллегиальной конструктивной критике.
3. Комментарий старшего представителя обзорной группы должен быть относительно кратким и излагать основные проблемы игры. Цель состоит в том, чтобы как можно быстрее открыть тему обсуждения и подискутировать с другими членами обзорной группы.
4. Затем подключаются другие члены обзорной группы и делятся своими мнениями. Между ними может завязаться оживленная беседа.
1. Члены обзорной группы могут либо начать говорить спонтанно, либо поднять руку, чтобы их пригласила игровая команда или тот, кто ведет собрание.
2. Часто разговор развивается совершенно естественно. Члены обзорной группы будут развивать комментарии друг друга, а иногда и не соглашаться с ними. Несогласие между членами обзорной группы может оказаться очень продуктивным, оно приведет к некоторой (вежливой и уважительной) дискуссии, углубляющейся в несовершенства игры.
3. Один из членов команды, представляющей презентацию, должен делать заметки (или, с разрешения обзорной группы, аудио- или видеозапись), чтобы зафиксировать комментарии обзорной группы.
4. Разработчики могут еще раз продемонстрировать те разделы игры, которые особенно интересны группе. Если игра короткая, можно показать ее полностью. Это побудит к подробному обсуждению той или иной части игры.
5. Во время обсуждения разработчики игры могут быстро получить достаточно четкое представление о сильных и слабых сторонах своей работы с точки зрения обзорной группы. Обзор также поможет выявить, насколько по-разному разные люди воспринимают один аспект игры.
5. Когда время, отведенное для обзора, истекает, разработчики игры благодарят группу за отзывы.
1. В рамках обыкновенной вежливости разработчики должны поблагодарить обзорную группу за время, внимание и советы.
2. К тому же это станет хорошим заделом на дальнейшее сотрудничество с обзорной группой.
6. В случае, когда рассматривается сразу несколько проектов, например на ежеквартальной деловой встрече или занятии по разработке игр, мы переходим к следующему проекту.
1. На моих занятиях мы равномерно распределяем время, которое у нас есть для обзора, между проектами. Демонстрация некоторых игр занимает больше времени, и в каждом конкретном случае мы решаем как-то этот вопрос.
2. Члены команды разработчиков и обзорной группы могут продолжить общение вне собрания, если, когда время выйдет, еще остается что обсудить.
3. Количество времени, которое мы тратим на просмотр каждой игры, обычно увеличивается по мере продвижения разработки.
i. В конце этапа препродакшена на каждую игру выделяется по пятнадцать минут. Вертикальные срезы, которые мы рассматриваем, часто довольно короткие, и их прохождение может занять всего две-три минуты. Это оставляет нам достаточно времени для обсуждения.
ii. На этапах альфа- и бета-тестирования мы изучаем игры куда дольше, и время на обзор увеличивается по крайней мере до тридцати минут.
Мозговой трест Pixar
Этот процесс или его вариации хорошо подойдут для обсуждения большинства проектов. Отчасти он вдохновлен Мозговым трестом (англ. Braintrust), описанным Эдом Кэтмеллом и Эми Уоллес в книге «Корпорация гениев». Вариации этого метода можно найти в творческих сообществах по всему миру[135].
Интересная и важная особенность Мозгового треста Pixar заключается в том, что он никак напрямую не влияет на принятие решений творческой группой, чья работа обсуждается: это экспертная группа, в которой режиссеры, рассказчики и художники из разных проектов собираются вместе, чтобы обсудить разрабатываемый проект, не имея полномочий обязывать следовать их замечаниям. Команда должна выслушать полученную обратную связь и решить, как с ней работать.
В то же время творческая команда, чья работа рассматривается, действительно несет ответственность за решение выявленных проблем. Если на обзорах снова и снова даются одни и те же замечания, это сигнализирует о более серьезной проблеме с проектом, из-за которой в конечном счете придется либо отменить проект, либо сменить руководство.
В «Корпорации гениев» говорится, что наиболее важная характеристика Мозгового треста – «способность анализировать эмоциональные биты фильма так, чтобы никто из участников сам не поддавался эмоциям и не занимал оборонительную позицию»[136].
Благодаря самой структуре Мозгового треста, боль от необходимости внесения изменений и найденных недостатков сведена к минимуму. Режиссеру ни к чему занимать оборонительную позицию, потому что никто на него не давит и не говорит ему, что делать. Не режиссер, а фильм находится под микроскопом. Вы – это не ваша идея, и если вы слишком тесно отождествляете себя со своими идеями, то вас будет обижать любое замечание. Чтобы создать здоровую систему обратной связи, исключите из уравнения борьбу за власть – другими словами, вы должны сосредоточиться на проблеме, а не на человеке[137].
Давление власти слишком часто становится причиной плохих отзывов на этапе обзора майлстоуна: президент студии или издатель хотят видеть определенные фичи или контент и не успокоятся, пока этого не получат. Особенно в коммерческом контексте руководству игровой команды часто приходится иметь дело с обзорами такого типа, как мы обсудим в разделе «Представление проекта заинтересованным сторонам».
Итак, чем глубже мы внедрим практику Мозгового треста Pixar в наше рассмотрение игр в процессе разработки, тем лучше. Стоит устранить борьбу за власть из обсуждения, и мы тут же можем сосредоточиться на объективных качествах игры и на том, соответствует ли она целям проекта.
Что делает замечание полезным
Замечание – это часть обратной связи, этот термин используется во множестве различных областей творчества. Замечание, которое я даю вам о вашей работе, будь то
