Геймдизайн. Рецепты успеха лучших компьютерных игр от Super Mario и Doom до Assassin’s Creed и дальше Сильвестр Тайнан
Именно из-за этой неопределенности мы должны обращать внимание на зависимости. Если бы мы не принимали во внимание любую неопределенность, было бы неважно, в каком порядке выполнять работу. Мы бы генерировали идеи, записывали их, выстраивали их в любом порядке, и в последний день разработки дизайн бы идеально складывался, как мозаика. И в случаях производных дизайнов, основанных на проверенных идеях, это может сработать практически полностью, потому что каждый элемент дизайна определен.
Но в играх с некоторой новизной написанный дизайн часто не соответствует действительности. Существует вероятность того, что в процессе разработки элемент дизайна необходимо будет изменить. И именно эта неопределенность делает зависимости важными.
Например, система набегов гоблинов описана на двух страницах где-то в документации проекта. В ней указано, как и когда появляются гоблины, какую тактику они используют, какие у них есть возможности и стратегии для победы.
Как и у каждого плана, у этого дизайна некоторый уровень неопределенности. Он отражает вероятность, с которой дизайн будет работать не так, как ожидалось. Предположим, что это шаблонный дизайн, поэтому определенность составляет 80 %. По оценкам разработчиков, в этой ситуации восемь из десяти раз система будет работать так, как написано, без существенных изменений. Это весьма неплохо.
Но значит ли это, что с самого начала разработки мы можем быть на 80 % уверены, что нападения гоблинов окажутся в игре и будут работать так же, как написано?
К сожалению, нет; эта цифра в 80 % охватывает только неопределенность дизайна, касающегося нападения гоблинов. Но нападения гоблинов могут пострадать не только в результате изменений, вызванных несовершенством дизайна. Они также уязвимы к изменениям, вызванным несовершенством дизайна, от которых зависят.
Чтобы стек «набеги гоблинов» работал, как и было запланировано, мы сначала должны реализовать персонажей, строительство, строительство стен и боевые системы. Если в какой-либо из этих систем произойдет значительный сдвиг, изменения будут проходить каскадом через стек зависимостей и приводить к изменениям в стеке «набеги гоблинов». Даже если каждый из этих основополагающих элементов имеет чрезвычайно благоприятную определенность в 80 %, то вероятность того, что стек «набеги гоблинов» сработает так, как и ожидалось, умножится на 0,8 в пятой степени, или на 0,33 (33 %), поскольку ошибка в любом из пяти основополагающих элементов приведет к изменению в стеке «набеги гоблинов».
Каскадная неопределенность означает, что верхние элементы стека зависимостей почти всегда нуждаются в серьезном изменении дизайна.
В большинстве дизайнов нет даже 80 % определенности. При разработке рискованных, теоретически прорывных игр большинство проектов терпят неудачу. Определенность в системе часто составляет менее 30 %. При таких условиях дизайн пяти слоев вверх по стеку зависимости останется неизменным в 0,2 % случаев. Так что, в принципе, никогда.
Это значит, что большая часть написанного дизайна для Fantasy Castle – ерунда. Фундаментальные системы почти наверняка изменятся при реализации или тестировании, и эти изменения будут проходить каскадом через дизайн, приводя к изменениям везде. Концепции могут остаться, но все особенности будут меняться снова и снова. К концу разработки большая часть верхней части стека будет в несколько раз урезана или изменена.
Казалось бы, это простая истина, но в ней скрыт глубокий смысл. Каждый разработчик видел, как игры меняются в процессе разработки, особенно если они нестандартные.
Но часто трудно четко сформулировать, почему это происходит. Простой неопределенности в отношении отдельных частей дизайна недостаточно, чтобы объяснить это. Настоящая проблема заключается в том, что каждое изменение создает ударную волну последующих изменений, которые пронизывают весь дизайн через зависимости. Это настоящий виновник массового хаоса многих дизайнов. Это ключевая причина, по которой нужны итерации.
Но подойдет не любая итерация. Мы должны выполнять итерацию особым образом, исходя из зависимостей, которые мы определили с помощью стека. Общая стратегия проста.
Начните с нижней части стека зависимостей и идите вверх через каждый цикл итерации.
Мы начинаем с нижней части, с дизайна, который ни от чего не зависит. После нескольких итераций и плейтестов эта основа становится более определенной. На бумаге определенность могла составлять 40 %, но как только мы провели несколько плейтестов, она может достичь 90 %. Затем мы можем создать элементы, которые зависят от этой основы, и быть уверенными в том, что они не будут разбиты на части дальнейшими изменениями, идущими снизу вверх. И мы просто продвигаемся вверх по стеку, компилируя снизу вверх. Тем не менее все равно будут появляться неожиданные результаты дизайна и сотрясать всю структуру, но мы уменьшаем их частоту и влияние, выполняя работу в правильном порядке.
Например, в игре Fantasy Castle мы могли бы начать разработку игры только с основными персонажами, конструкцией и стенами. Во-первых, это просто игра о людях, строящих стены. Спустя несколько итераций и хорошего плейтеста мы можем добавлять фермерство. После нескольких итераций мы добавляем торговлю и времена года. Мы продвигаемся вверх, строим башню зависимостей снизу вверх. И дизайн, скорее всего, изменится наполовину – после плейтестинга фермерства мы можем почувствовать, что не нужно добавлять времена года, а вот новый элемент в виде болезней сельскохозяйственных культур привнесет больше интереса. Таким образом, вершина стека меняется по мере укрепления фундамента.
Бэклог дизайна
Тот факт, что дизайны в верхней части стека очень неопределенные, не означает, что они бесполезны. У нас все время есть мысли, идеи и наблюдения, и их следует записывать, потому что они могут быть весьма ценными. Но для того, чтобы объединить их во взаимосвязанный подробный проект, требуется проделать большую работу, которая, вероятно, будет аннулирована из-за каскадной неопределенности.
Решение состоит в том, чтобы сохранить идеи в текучей, не заблокированной форме, записав их в бэклог дизайна.
БЭКЛОГ ДИЗАЙНА – это резервуар идей, концепций и впечатлений, над которыми вы не работаете и над которыми не будете работать в ближайшее время. Большинство идей должно идти в бэклог дизайна.
Бэклог дизайна получил название в честь аналогичной концепции из популярной методологии разработки программного обеспечения Скрам – бэклог продукта. Но в отличие от Скрама, он не предназначен для того, чтобы быть частью формализованного процесса разработки. Это неформальный инструмент для сохранения вдохновения.
Только потому, что большая часть дизайна игры Fantasy Castle является ерундой из-за каскадной неопределенности, это не значит, что он бесполезен. Скорее, он требует реорганизации. Большую часть следует рассматривать как не более чем гипотетические идеи на будущее. Эти элементы не нужно объединять в строгий план, поскольку это подразумевает определенность, которой у нас нет. Следует сжижать и помещать в неупорядоченный массив, чтобы в будущем их можно было оттуда извлечь.
Теперь Fantasy Castle выглядит примерно так:
Мой выбор здесь был субъективным. Сначала я решил создавать элементы дизайна для общественных зданий, а все остальное перенес в бэклог дизайна. Другой дизайнер мог бы сосредоточиться на бое или религии. Но независимо от того, что мы выберем, мы должны начать с чего-то и итерировать, прежде чем настраивать фундамент. В противном случае мы строим на фундаменте из песка.
Все, что находится в стеке выше, чем три базовых элемента, будет подвергаться чрезмерной каскадной неопределенности и поэтому не является целесообразным для реализации. На этапе разработки на бумаге, вероятно, определенность упадет ниже 50 %. Но по мере реализации, изучения, исследования и тестирования эти три элемента и их определенность будут расти. Например, дизайн на бумаге системы фермерства будет иметь определенность в 60 %, а функциональный плейтест – 90 % или более. Она может измениться во время итерации, но в этом нет ничего страшного, поскольку от нее еще ничего не зависит.
Только после того, как основа будет устойчивой и определенной, мы можем добавить в стек что-то еще. Теперь пришло время открыть бэклог дизайна, выбрать что-то подходящее и добавить его в верхнюю часть стека. Мы будем хорошо подготовлены к этому выбору, так как будем точно знать, на чем он основан.
Потом нужно просто повторить процесс, выполнив несколько итерационных циклов. Каждый раз, когда дизайн упрочняется, мы производим поиск в бэклоге, вытаскиваем оттуда еще один кусок и помещаем его сверху. Каждый раз, когда у нас появляется новая идея, мы записываем ее в бэклог и откладываем на потом. Большинство бэклогов никогда не будут реализованы. Это нормально – это означает, что те части, которые мы используем, вероятно, хороши. И дизайн растет вверх.
Ядро геймплея
Из 22 элементов дизайна игры Fantasy Castle я решил поместить в бэклог дизайна все, за исключением трех. Но обратите внимание, что мы все еще можем создать эмоционально значимую игру, в которой есть только персонажи, строительство и фермерство. Эти три части сами по себе образуют минимальную, но годную игру, потому что эти три подсистемы составляют ядро игры Fantasy Castle.
ЯДРО ГЕЙМПЛЕЯ – это то, что вытекает из минимальной механики игры, которая лежит в основе ее стека зависимости. Уберите все, что можно убрать, эмоционально не обедняя игру, и то, что останется, и будет ядром игры.
Попробуйте следующее. Представьте игру, которую хорошо знаете. Теперь уберите что-нибудь из ее дизайна. Затем уберите следующий элемент или несколько элементов и так далее. Продолжайте убирать до тех пор, пока игра не перестанет генерировать значимый опыт, пока она не станет тривиальной и неинтересной. Явления, которые у вас останутся, и будут ядром игры – минимальным набором механики, которая заставляет игру работать.
Если вы выбрали современную видеоигру, то могли бы отбросить 95 % или более игры, включая почти весь контент, большинство интерфейсов и элементов управления. Если вы выбрали классическую или настольную игру, то отбросили гораздо меньше. Трудно понять, как можно уменьшить количество шашек и сохранить их функционал. Но даже шахматы можно разделить на части – убрать все, кроме пешек, и игра все еще останется рабочей.
Некоторые примеры ядра геймплея:
• Civilization V. Карта, города, поселенцы, воины.
• Unreal Tournament. Карта, игроки с управлением от первого лица, оружие.
• Starcraft II. Карта, центр командования, работники, пехотинцы.
В основе каждой из этих сложных игр лежит простой цикл итераций, который сам по себе создает полезный опыт. Даже при наличии только рабочих и морпехов игра StarCraft II генерирует интересные решения и стратегии. Одним из самых популярных способов играть в Unreal Tournament был режим InstaGib, который убирал все, кроме одного очень простого оружия – мгновенного уничтожения. Ядро – это и есть игра, хорошая или плохая. Все остальное – просто вариации и шлифовка.
Во многих случаях ядро игры определяет жанр. Например:
• Tower defense. Карта, объект для броска, башни, приближающиеся враги.
• Dungeon crawler. Персонаж, подземелье, герой, монстры, прокачка.
• Fighting game. Движение, удар, блок, бросок.
Ядро игры – правильная основа стека зависимостей, потому что все остальное в дизайне зависит от этих базовых механизмов. Идентифицируя ядро, мы находим кратчайший путь к тестируемой платформе для итерации. Чем раньше вы завершите работу над ядром, тем раньше игру можно будет протестировать. Только теперь вы можете увидеть преимущества итерации на основе тестирования. Поэтому, будучи дизайнером, определите ядро и создайте сначала его. Как только оно будет готово, достаньте что-нибудь из бэклог дизайна, поместите это в дизайн и произведите итерацию.
Если вы не можете найти ядро или работаете над его созданием и у вас получается ужасно, попробуйте начать заново с чем-то другим. Должна появиться очень веская причина, чтобы оставить игру без надежного ядра. И иногда она действительно существует. Например, в приключенческих играх в жанре «указать и щелкнуть» нет реального ядра. Указывание и щелканье не является само по себе рабочей игрой. Эти игры являются исключениями; они работают, потому что их опыт определяется содержанием, а не механикой. В некоторых играх есть несколько возможных ядер. Рассмотрим RPG с открытым миром Fallout 3.
Одним ядром Fallout 3 могут быть персонаж игрока, оружие, монстры. Другим – персонаж игрока, диалоги, квесты. Третьим может быть персонаж игрока, открытый мир, мировое искусство. Эти три ядра делают игру простым шутером, сюжетной игрой с диалогами «ходи и говори» и художественной галереей мирового масштаба соответственно. Но каждое из них все еще представляет собой функциональную игру. Разработчики могли бы начать разработку с любого из ядер, а затем встроить его в другие.
Небольшой стек зависимостей
До сих пор мы рассматривали стек зависимостей как возможность для одновременного анализа всей игры. Но стек зависимостей также можно использовать для анализа дизайна отдельных систем. Если вы попробуете этот метод, скорее всего, будете пользоваться им большую часть времени, так как постоянно анализировать весь дизайн может быть неудобно и трудозатратно.
Рассмотрим, к примеру, разработку персонажа по имени Кэпп в военной игре. Предполагается, что Кэпп будет быстро двигаться, безболезненно падать и атаковать с помощью акробатических боевых движений капоэйры. Ниже представлены способности и системы Кэппа согласно задумке:
• Скорость. Кэпп бегает чрезвычайно быстро, фактически на виражах.
• Удар ногой с разворота. Кэпп делает удар ногой с разворота, поражая всех, кто находится рядом.
• Падение. У Кэппа есть слабое место. В случае повреждения во время атаки он падает на землю.
• Прыжок от стены. Кэпп прыгает и отскакивает от стен, чтобы попасть в специальные зоны или обойти противников.
• Переворот с опорой на руки. Кэпп может сделать переворот с опорой на руки, что позволяет ему сделать прыжок от стены.
• Подсечка. Чтобы компенсировать свою уязвимость при падении, у Кэппа есть небольшая возможность сделать нижнюю подсечку, благодаря которой можно избежать атак противника и нанести ответный удар за один ход.
Точно так же, как можно сократить большинство хороших игр до ядра и они при этом все еще будут работать, можно сократить и большинство хороших игровых систем и они продолжат выполнять свою роль. В этом нам помогает особая функция стека зависимостей. Вот как я выполнил дизайн Кэппа:
Падение вполне логично, если вас атакуют и вы получаете удар – в данном случае удар ногой с разворота. Подсечка – это способность, предназначенная для возмещения падения, поэтому нет смысла делать ее до самого падения. И наконец, прыжок от стены – это увеличение базовой скорости, а переворот с опорой на руки – особая версия атаки прыжка от стены.
Как всегда, учитывая разные детали дизайна, этот стек может быть разным. Например, скорость и прыжок от стены могли бы легко поменяться местами. Этот стек отражает мой записанный на бумаге дизайн.
В каждой части дизайна существует некоторая неопределенность:
• Удар ногой с разворота. В нем существует небольшая неопределенность, поскольку он является производной атак, которые мы видели в других играх. Основная неопределенность заключается в выборе радиуса и времени. Если окажется, что удар ногой с разворотом работает лучше, когда он длится полсекунды, а не три секунды, как предполагали разработчики, изменения могут сместиться вверх к другим способностям.
• Падение. Очень неопределенно. Интуиция подсказывает разработчику, что падение может обескуражить, а это означает, что нам придется полностью заменить его.
• Скорость. Здесь существуют неопределенности, связанные с технологиями. Нестандартное движение на основе физики всегда сложно реализовать хорошо. У ИИ могут быть проблемы с ожиданием или навигацией, а у игроков могут быть проблемы с его управлением. Может потребоваться изменение дизайна или отказ от приема.
• Прыжок от стены. В нем существуют аналогичные риски, что и в скорости, с дополнительными проблемами, с которыми сталкивается ИИ при навигации по путям, которые обычно недоступны. Систему управления прыжков от стены тоже, вероятно, потребуется переделывать несколько раз.
• Переворот с опорой на руки. Сам по себе он не так уж не определен, но он уязвим к множеству каскадных неопределенностей систем более низкого уровня.
• Подсечка. Сама по себе она простая, но уязвима к каскадным неопределенностям нижних уровней.
Не следует идти напролом, работая над всем дизайном, как если бы была стопроцентная гарантия того, что он будет работать. Скорее всего, не будет. Как и в случае с Fantasy Castle, мы должны найти ядро и превратить все остальное в бэклог дизайна.
Ядром этой игры, вероятно, являются удар ногой с разворота и скорость. Благодаря им Кэпп может выполнять свою уникальную роль первоклассного бегуна, что достаточно полезно и выделяет его на фоне других персонажей. Это выглядит следующим образом:
После нескольких итераций ядра оно будет достаточно определенным для дальнейшей компиляции. Только теперь мы можем достать что-нибудь из бэклога, потому что существует большая вероятность, что скорость и удар ногой с разворота изменятся перед тем, как это произойдет, или у нас появится лучшая идея для компиляции.
Зависимости и потребности внешнего дизайна
Работая со стек-зависимостями, необходимо учитывать один факт. Маркетологам и бизнесменам проектные решения могут потребоваться задолго до того, как они потребуются самой игре.
В этих случаях разработчики должны обсудить их с заказчиком и найти золотую середину. Если решение расположено на вершине стека и является очень детальным, выгода, которую эти чрезвычайно ранние решения принесут бизнесу и маркетингу, может не окупить стоимость их принятия на ранней стадии. Например, скорее всего, не стоит сильно рекламировать способность Кэппа делать подсечки, пока этот ход не пройдет достаточное количество итераций, потому что весьма вероятно, что на подсечку повлияют каскадные изменения дизайна.
Маркетинг и бизнес важны. Но в то же время мы не должны заключать геймдизайн в тюрьму неизменных проектных решений. Будьте изменчивыми, не думайте о будущем и обращайте внимание на риск, связанный с зависимостями. Это требует ежедневных усилий, и поначалу не все поймут. Возможно, это расточительно и даже безответственно. Но в конце концов, только так маленький человек может решить такую сложную задачу, как геймдизайн.
Глава 14. Управление
Бригадир Джон устал от рабочих, которые все портят. Поэтому он купил Puppetron – последнее слово в области управления. Ему больше не придется отдавать указания и надеяться, что они будут выполнены правильно. Теперь он мог надеть на голову шлем Puppetron и контролировать все действия рабочих силой мысли. Он стал подобен кукловоду, дергающему за тысячу веревочек, лично координируя действия каждого работника. Это было чудесно.
Бригадир Джон и его команда строили мост. Когда уже половина работ была выполнена, мост рухнул и всех убил.
Следователи обнаружили сотни мест с халтурной сваркой, перекрученные кабели, смещенные стойки и отсутствие болтов. Как будто ни одна из работ не была выполнена работником осознанно.
Создание хороших игр возлагает определенные обязательства. Мы должны исследовать культуру и задумку, решать сложные интеллектуальные головоломки и рисковать. Мы должны использовать любые преимущества и ресурсы. Мы должны думать не только о зарплате, но и о том, что мы делаем. Мы должны вкладывать душу в работу.
Но вкладывание души – дело тонкое. Нужно особое сочетание методов работы, культуры, внутренней мотивации и организационной структуры. У людей должны быть необходимые полномочия, опыт и знания должны передаваться другим, и мы должны доверять друг другу. В этой главе я напишу о создании таких условий, в которых команда смогла бы работать в полную силу.
Банальность зла
Особенности организации – это не просто усредненные особенности ее участников. Важно, как они структурированы. Структура определяет, как знания, власть и ресурсы распределяются внутри команды. Если их распределяют неправильно, группа гениев может вести себя как психи.
В качестве наиболее яркого примера можно привести исторический геноцид XX века. Убийственная бюрократия нацистской Германии, СССР и кхмерской Камбоджи включала в основном совершенно нормальных людей, которые, вероятно, стали бы хорошими исполнителями в другое время и в другом месте. Но в определенной организации с определенной культурой и иерархией они стали винтиками в машине смерти. Политический теоретик Ханна Арендт назвала это «банальностью зла». Она поняла, что ужасы бюрократии совершают не хохочущие сумасшедшие, а легионы канцелярских крыс, покорно следующих своим собственным побуждениям.
Очевидно, что никто не умирает в процессе разработки игр. Я привел эти примеры, чтобы показать, что нет предела тому, насколько плохо структурированная организация может испортить результат, даже несмотря на то, что к исполнению были привлечены хорошие кадры. Наличие человеческих ресурсов необходимо, но они все пойдут впустую в плохой структуре и дисфункциональной культуре. Мы должны правильно понять эту структуру. Таким образом, вопрос заключается в том, как привлечь правильные ресурсы для хорошей работы.
Тейлоризм
Наука, лежащая в основе каждого отдельного действия рабочих, столь обширна по своему объему и содержанию, что рабочий, наилучшим образом приспособленный к фактическому выполнению своей работы, не в состоянии (по причине отсутствия образования или вследствие недостаточности умственных способностей) овладеть этой наукой.
Ф. У. Тейлор
В конце XIX века большинство рабочих определяли методы работы сами. Управляющий поручал каменщику, резчику по металлу или чугунщику задачу, и он выполнял ее в свободное время, используя методы, которым он научился за годы своего опыта и обучения.
Около 1900 года человек по имени Фредерик Тейлор начал изучать рабочие процессы и увидел огромные пробелы в традиционных методах. Он приступил к созданию стиля управления, который впоследствии будет известен как тейлоризм.
Тейлор наблюдал за работой каменщика и секундомером замерял, сколько времени занимает каждое движение. Он записал время, которое нужно для того, чтобы протянуть руку и взять кирпич, положить его в нужное место, выровнять, положить сверху цемент и убрать излишки. Собрав необходимые цифры, Тейлор начал разрабатывать лучший способ кладки кирпичей. Он скорректировал и убрал лишние движения, чтобы найти их наиболее эффективную последовательность. Он убрал лишние шаги, которые делали многие каменщики на этапе кладки. Он перепроектировал инструменты, создав специальные устройство для удержания кирпичей в правильном положении, чтобы их можно было быстро взять. Затем он проинструктировал рабочих, какие именно движения им следует выполнять, и заставил довести их до автоматизма. Этот процесс «научного менеджмента» стал его арсеналом средств, и он применял его к различным сферам, от резки металла до обработки чугуна.
Тейлор не пытался заставить рабочих понять, что они делают. Для него они были неуклюжими идиотами, и их понимание было ненужным. «Рабочий, наилучшим образом приспособленный для фактического выполнения своей работы, не способен в полной мере уяснить себе этот ее научный фундамент без помощи и руководства со стороны тех, кто работает вместе с ним или над ним. Это объясняется у него либо отсутствием образования, либо недостатком умственных способностей» – писал Тейлор.
Тейлоризм – это сосредоточение каждого решения в руках небольшой группы очень умных людей. Один думающий «мозг» наверху направляет действия многих глупых «рук». Концентрируя знания в едином умном мозге, тейлоризм повышает качество принимаемых решений, поскольку этот мозг является наиболее мотивированным, наиболее квалифицированным и наиболее способным и может разумно координировать действия глупых людей, перевозящих чугун.
Идеи Тейлора легли в основу современного исследования эффективности, потому что они работают. За прошедшее столетие полученные им методы обеспечили нас более качественными и дешевыми автомобилями, картофельными чипсами и компьютерами. Этот метод концентрации решений в головах немногих умных людей и устранения лишних телодвижений настолько успешен, что теперь он является предполагаемой частью культуры производства.
Но тейлоризм ограничен видами задач, которые может решить. Основная причина – это количество знаний, которое включает в себя работа. Если работа требует мало знаний, тейлоризм работает хорошо. Начальник производства может знать все о том, что делает каждый из его подчиненных, так как работа на производстве простая и цикличная. Он может принять все решения вместо подчиненных, ведь решений нужно принимать не так много. Он может удерживать в голове любые знания.
Но что происходит, если работа сложная и не повторяющаяся? Что будет, если информации больше, чем может выдержать один мозг? Теперь «главный мозг» перегружен данными. Он начинает игнорировать детали, упрощать или пропускать важные сигналы. Решения становятся хуже, и возникают лишние действия.
Разработка игр – одна из тех задач, в которых тейлоризм терпит неудачу, потому что разработка игр включает в себя действительно огромное количество знаний. Представьте, что в процессе коллективной разработки вы пытаетесь каталогизировать все знания. Каждый раз, когда художник наносит мазок кисти, оценивает и нажимает кнопку «Отменить», он создает крошечный кусок знаний, который говорит, что эта идея не очень хороша по той или иной причине. Каждые 10 секунд самостоятельного тестирования, которое будет проводить разработчик, каждое изменение алгоритма, придуманное программистом, каждый спонтанный разговор с коллегами или возникающая идея являются потенциально полезными знаниями. Их объем растет каждую минуту, секунда за секундой. Ни один мозг или небольшая группа «руководящих мозгов» не сможет воспринять и использовать их все.
И огромный объем знаний – не единственная проблема. Большую часть знаний о процессе трудно или невозможно передать. Это называется неявным знанием. Например, навыки – это неявное знание. Опытный художник может посмотреть на никудышную композицию и просто знать, как ее исправить. Программист может просто знать, как оптимизировать алгоритм, а разработчик может просто знать, как сделать интерфейс лучше. Но никто из них не может объяснить это – эти знания возникают интуитивно на основании натренированного бессознательного. Эти знания невозможно передать ведущему специалисту. Это навык, и на его развитие ушли годы.
Так что тейлоризм, являющийся надежным стандартным методом, не подходит для разработки игр. Но существует решение.
Распределенный разум
Чтобы понять, как создавать игры, не обязательно учиться у мастеров, живших в 1912 году. Можно поучиться у муравьев.
Вспомните, как муравьи собирают еду. Во-первых, несколько муравьев-фуражиров отползают от муравейника. Когда муравей-фуражир находит источник пищи, он возвращается, оставляя за собой след феромона. Другие муравьи инстинктивно следуют по этому следу к еде. Каждый муравей, который находит еду, тянет уже свой собственный след феромона назад, тем самым усиливая его. Если муравей приходит к богатому источнику с едой, след феромона усиливается каждый раз. По мере упрочнения тропки начинаются другие процессы. Появляются более сильные рабочие муравьи и убирают препятствия с тропки. Муравьи-солдаты начинают ее патрулировать, наблюдая за угрозами. Некоторые рабочие муравьи жертвуют собой, создавая из своего тела мост через ямки. Вместе муравьи чрезвычайно эффективно создают, оптимизируют и защищают тропки к лучшим источникам пищи. И весь этот великолепный сложный процесс осуществляется без центрального плана благодаря совместным усилиям глупых муравьев, которые следуют своим простым правилам. Ни один из муравьев не понимает общую стратегию того, что делает колония, но все они в равной степени координируют свои действия в комплексный подход. Как будто колония муравьев образует коллективный, распределенный разум, обладающий гораздо большей силой, чем любой из ее отдельных участников. Муравей – глуп, колония муравьев – умна.
Разработка игр работает по такому же принципу, так как никто не может понять все, что происходит в процессе разработки. Слишком много событий для одного человеческого мозга. Поэтому, подобно муравьям, каждый из нас должен играть свою роль, но только в более широком распределенном разуме. Действия каждого из нас должны выполняться на благо чего-то большего.
Это невозможно с помощью тейлоризма. Мы не можем отнимать решения у рабочих и отдавать их в руки нескольких руководителей. Чтобы распределенный интеллект работал, мы должны разделить власть между членами команды.
Распределение власти
У муравьев нет начальников, которые говорят им, как сделать феромоновую дорожку. Каждый из них принимает собственные решения в зависимости от условий. В этом есть два основных преимущества.
Во-первых, задействуется весь мозг каждого муравья. В тейлоризме интеллектуальные силы рабочих остаются невостребованными, потому что у них отнимается каждое решение. Не использовать такой ценный ресурс – это ошибка, особенно в геймдизайне. Весь смысл работы с командой разработчиков – использовать их мозг.
Во-вторых, при полном распределении власти используются знания, которыми обладает каждый муравей. Каждый муравей очень хорошо знает свое непосредственное окружение, так как он в нем находится постоянно. Если бы королеве постоянно приходилось говорить каждому работнику, что ему нужно сделать, она принимала бы плохие решения, находясь только в одном месте. Она никогда не поймет то, что делает работник № 1314 так же хорошо, как сам работник № 1314. То же самое относится и к геймдизайну. Каждый разработчик понимает свою часть работы так, как никто другой. Каждый разработчик понимает уровень, технологии или механику, над которыми он работает, так, как никто другой.
Разработчики игр могут делать то же самое, что и муравьи, распределяя решения между членами команды. Каждый разработчик выбирает то, что ему ближе всего. Программист системы должен принять решения относительно дизайна этой системы. Дизайнер уровня должен разработать подробный проект уровня. У каждого человека существует сфера естественной власти, которая охватывает те части проекта, которые он понимает лучше всего.
ЕСТЕСТВЕННАЯ ВЛАСТЬ разработчика распространяется на любое решение, в котором он разбирается лучше, чем кто-либо другой из членов команды.
Это не значит, что каждый просто работает только над своей задачей. Разработка игр всегда предполагает интенсивную коммуникацию, поскольку решения часто требуют знаний разных людей. Например, художник никак не сможет решить, как будет выглядеть персонаж, не зная нарративной цели. Писатель не сможет написать хороший диалог для боевой сцены, если он не знает, как она изменилась после последнего плейтеста. Чтобы собрать всю эту информацию, нужна коммуникация.
Например, совещания – это способ сбора информации для принятия решений. Рассмотрим совещание, на котором креативный директор, программист, разработчик и художник решают, с каким из двух возможных вариантов «серого ящика» продолжать работу. Они организовали совещание, так как у каждого из них есть уникальные знания, имеющие отношение к решению.
Разработчик провел пять плейтестов на каждом «сером ящике», поэтому он знает, где у уровня проблемы с балансом и понятностью. Он также работал какое-то время над уровнем, поэтому у него множество идей и неудачных экспериментов.
Программист знает, какой размер и сложность уровня будут работать в игровом движке, а также прочие технические ограничения системы.
Художник лучше всего понимает, как уровень вписывается между предыдущим и следующим уровнями с точки зрения художественного развития игры, а также знает, какие еще художественные ресурсы доступны.
Креативный директор знает общую структуру игры и то, куда будет добавлен уровень, а также какие у него эмоциональные цели, стратегия позиционирования на рынке, более глубокие темы и потребности инвесторов.
Никто из этих людей не может принять решение в одиночку. Они встречаются, чтобы поделиться своими знаниями и принять совместное решение. Это совещание хорошо организовано, на нем присутствуют только люди с необходимыми знаниями и никого лишнего. При отсутствии хотя бы одного из них знаний для принятия решения было бы недостаточно. Приглашать кого-то еще было бы бессмысленно.
Плохие решения принимаются в тех случаях, когда знания не применяются. Например, дизайнер уровней может решить протестировать уровень методом «серого ящика», размер которого слишком большой для компьютера. Программист мог бы его предупредить об этом. Но так как между ними не было никакой коммуникации, его решение придется переделать. Мы инстинктивно обвиним дизайнера уровней, но это неправильно. В данном случае следует винить организационную структуру за то, что дизайнер не получил необходимой информации.
Даже при отличной коммуникации значительная часть соответствующих знаний все еще остается скрытой или слишком объемной, чтобы ее можно было передать. Вот почему лучше, если человек с естественной властью принимает окончательное решение – дизайнер уровней принимает решение о своем уровне, писатель – по диалогу, директор – по общей структуре.
Присвоение и доверие
Слово «arrogant» происходит от французского s’arroger и означает «присваивать чужие полномочия». Люди присваивают полномочия по принятию решений, когда отнимают их у человека, над которым у них естественная власть.
ПРИСВОЕНИЕ – это предъявление прав на принятие решения, которое подпадает под естественную власть другого человека.
Присвоение часто принимает форму микроменеджмента. Микроменеджмент – стиль управления, при котором руководитель отдает распоряжения, связанные с незначительной специальной информацией, которую подчиненный понимает лучше, чем руководитель. Обычно это приводит к плохим решениям, потому что специальные знания подчиненного о работе не принимаются во внимание.
Например, руководитель может выслушать часовой обзор разрабатываемой игровой системы и потребовать внести ряд изменений, которые представляются сотрудникам «на передовой» крайне глупыми. Таких руководителей ласково называют «чайками»[14]. Но руководители делают так не по собственной глупости. Они не потратили сто часов на итерации и тестирования, как сотрудники «на передовой», и не знают нюансов каждого теста, эксперимента или обсуждения. Руководитель может быть очень опытным, но общего опыта редко бывает достаточно, чтобы превысить уровень знаний людей, которые провели за этой работой гораздо больше времени.
Это распространенная проблема, которая возникает из глубинных когнитивных искажений. Геймдизайн полон скрытых возможностей. Один уровень или система могут быть сыграны сотнями или тысячами разных способов, и чтобы понять игру, недостаточно посмотреть ее обзор. Однако кажется, что все именно так и происходит из-за глубоко укоренившегося предположения WYSIATI (что видишь, то и есть). Руководитель не знает, сколько он не знает, так как никогда не видел того, чего не знает. Поскольку он сам не осознает, что информации не хватает, то считает, что видит полную картину. Таким образом, он присваивает себе полномочия по принятию решений, считая, что может сделать лучше, а подчиненные возмущаются и уходят.
Основная причина присвоения заключается в том, что лидеры, зная, что у них больше опыта, не доверяют своим подчиненным. Поэтому они и не хотят давать другим возможность принять важные решения и берут это на себя. Но такой подход не работает – руководитель не может знать о процессе все. В итоге решение становится хуже.
Чтобы вместе работать над игрой, мы должны доверять друг другу. Это не призыв к командной работе или мотивационный лозунг. Это голые факты, и слово «должны» я использую в буквальном смысле. Доверие – это не опция. Мы не можем исправлять чужие ошибки просто потому, что не в состоянии понять работу друг друга. Поэтому лидер, руководящий командой болванов, обречен. Он не может защититься от идиотизма, когда во всей студии принимается слишком много решений, находящихся вне его понимания и юрисдикции. Любые усилия, которые он предпринимает, чтобы защититься от людей, которых он считает тупее, чем они есть, только помешают команде. Единственный вариант – привлечь людей, которым вы можете доверять, и начать доверять.
Задать направление
Мы хотим распределить полномочия на принятие решений, но это не значит, что можно просто закрыть команду в комнате с пиццей и компьютерами и вернуться через два года за готовой игрой. Даже при распределении власти лидеры играют свою роль.
Руководители знают макроструктуру игры. Они знают ее эмоциональные цели, рыночную стратегию, бизнес-стратегию, нарратив, настроение, стиль дизайна, фокусы дизайна и общую структуру механики лучше, чем кто-либо. В этих сферах у руководителей естественная власть, и они принимают решения.
Чтобы эти решения были результативными, у лидеров должна быть возможность управлять подчиненными. Они должны направлять их к поставленным целям, а не указывать, что конкретно нужно делать. Они не должны требовать поменять цвет сапог персонажа. Они должны объяснить причину, по которой сапоги должны выглядеть иначе, и дать художнику возможность решить, как это сделать.
Направление – это цель работы. Какие задачи решает внешность этого персонажа? Какова цель этого уровня? Какова роль этой технологии в общем дизайне? Что понимает руководитель, но не понимает подчиненный?
Лидеры не могут указывать подчиненным, как выполнять любую мелкую задачу. Необходимо задать масштабное НАПРАВЛЕНИЕ.
Направление – это концепция, которую я заимствую из военного управления. Капитан не говорит сержанту, куда именно отправить каждого солдата во время штурма холма. Он думает только о том, какой именно холм будет штурмовать и в какое время. Сержант не думает о других холмах, кроме того, куда его отправили. Он думает о том, как направить своих солдат на этот холм, на который ему указали. А каждый солдат самостоятельно решает, куда целиться и как бежать, чтобы добраться туда, куда его отправил сержант.
Задавая направление, руководитель использует свои уникальные знания о более широких структурах проекта, чтобы обеспечить подчиненного информацией, которой тот не располагает. В то же время, придерживаясь общих соображений и не присваивая себе право принимать мелкие решения, руководитель не отказывается от информации, предоставляемой подчиненным в подробнейших деталях.
Руководитель не может быть готовым ко всем неизбежным проблемам. У него нет суперспособностей разобраться в деталях всего проекта. Но до тех пор, пока подчиненный понимает направление, он может решать задачи и использовать возможности так, чтобы наилучшим образом достичь поставленной цели. Сотрудник может сделать что-то совершенно не так, как предполагал руководитель, но пока он не сходит с заданного ему направления, игра становится только лучше.
Например, руководя уровнем в игре ужасов, высокомерный лидер и приверженец тейлоризма может сказать: «Игрок просыпается в ванне кровавой воды. На зеркале нацарапано: “Ты не сбежишь”. Игрок осматривает дом и находит тело своей подруги. Вскоре после этого он встречает врага с мачете, и поскольку у игрока нет оружия, ему придется бежать из дома, а противник будет его преследовать». Вот список задач, которые необходимо выполнить. И если бы все работали так, как запланировано, все было бы гораздо проще. Но что происходит, если тестировщики отказываются бежать от мачете или смеются над дурацким посланием на зеркале? Сотрудники не могут решить эти проблемы самостоятельно. Они не понимают, что делают, и у них нет полномочий что-либо менять. Следовательно, они должны вернуться к руководителю, а тот, вероятно, предложит им плохое решение, потому что ему не хватает глубоких знаний об уровне и он не присутствовал на провалившемся плейтесте. Специальные знания сотрудников не учитываются, и процесс срывается.
Лидер должен задать направление: «Этот уровень должен научить игрока всем основным элементам управления, кроме управления оружием, которое следует оставить до следующего уровня. Он должен включать историю о мертвой девушке, чтобы мы могли развернуть ее позже. Следует также добавить героя с мачете. Поскольку следующий уровень начинается за пределами заброшенного дома, этот должен закончиться тем, что игрок выходит через входную дверь дома. Это первый уровень, так что игра может начинаться с любой локации. Наконец, не показывайте главного героя, я хочу, чтобы на этом этапе он оставался загадкой». Теперь команда может приниматься за работу. Они могут начать с того же дизайна, который первоначально предлагал менеджер проекта. Но во время итерации они, скорее всего, найдут лучший способ достичь тех же целей. Плейтесты и мозговой штурм раскроют новые уровни проблем и решений, которые лидер никогда не смог бы найти в одиночку. Освободившись от строго регламентированного списка задач, разработчики могут использовать возможности и решать проблемы по мере их возникновения. Дизайн изменится, но поскольку разработчики понимают его роль в более крупной структуре, то смогут убедиться, что он хорошо и правильно вписывается в следующий уровень. А руководитель освобождается от обязанности следить за деталями.
Чтобы задать направление, руководитель должен сначала сам его понять. Иными словами, он должен понимать структуру игры и цели работы каждого разработчика. Поскольку это предполагает сложные мыслительные процессы, плохие руководители часто включают микроменеджмент. Они задают неопределенные направления, а затем критикуют то, с чем приходят подчиненные. Такая «оценка сверху» приносит мало пользы. Руководитель – единственный, кто способен усовершенствовать широкую структуру игры.
Он должен думать об этом, анализировать ежедневно. Если он хорошо справляется с этой работой, у него не останется времени придираться к мелочам в работе подчиненных. Если руководителю нужно оценивать работу для поддержания стандартов качества, его замечания должны ограничиться общими утверждениями о недостатках и предложениями помощи, а не конкретными указаниями, что должно быть сделано.
Как только направления понятны, о них нужно четко сообщить. К сожалению, в разработке игр слишком часто звучит фраза: «Это не то, что я хотел». Результат, который вы видите, означает, что сотрудник не понял направления и поэтому не смог выполнить задачу. Задать направление без микроменеджмента – это навык, который требует внимания и практики. Требуется усилие, чтобы понять и выразить цель, а не просто указать, что конкретно нужно делать.
Сотрудники должны РЕЗЮМИРОВАТЬ новую полученную информацию и предоставлять лидеру соответствующие выводы.
Руководители тоже итерируют. Они итерируют не отдельные уровни или механику, а продвижение уровня, структуры сюжета или позиционирование на рынке. Как и всем остальным, им нужно знать результаты своих решений. Им нужен не подробный посекундный темп или отдельные решения геймплея, а сжатая информация более высокого уровня, которая должна отразиться на более широкой структуре игры. Если одна основная игровая система просто не работает, лидер должен об этом знать. Если тестировщики привязываются к второстепенному персонажу на одном уровне, лидер должен об этом знать, так как подобные результаты могут приводить к изменениям в широкой структуре игры.
В команде, где руководитель задает понятные, четко выраженные направления, а подчиненные предоставляют ему на рассмотрение соответствующие выводы и итоги о проделанной работе, каждый знает ровно то, что ему нужно знать, и не более, а решения принимают люди, обладающие наиболее актуальными знаниями и, следовательно, естественной властью. Руководителю не обязательно везде присутствовать и решать все проблемы, но процесс разработки должен быть целенаправленным и структурированным. Каждый итерирует свою работу – руководитель делает широкие мазки, а рабочие добавляют к ним детали. Благодаря тому что все знания применяются эффективно, вам не нужны гениальные разработчики для того, чтобы создать выдающуюся игру.
Глава 15. Мотивация
- Здесь суета! Здесь праздник жизни!
- Но он не найден влюбленным народом.
- Он на вершине, что видят реже
- Пустынных комнат. Последний взмах кисти…
Мотивация геймдизайнера должна быть и сильной, и тщательно контролируемой. Сильной, потому что нужен мощный драйв, чтобы решать проблемы в процессе разработки игр. Контролируемой, потому что легко можно пойти в неправильном направлении и случайно сделать что-то, что повредит игре. Эта глава посвящена мотивации – ее возникновению, взращиванию и управлению в себе и в других.
Внешние поощрения
ВНЕШНЕЕ ПООЩРЕНИЕ – это награда, которая отделена от самой работы, обычно в обмен на некоторые измеримые результаты работы.
Казалось бы, чтобы люди работали лучше, нужно просто щедро их вознаграждать. Трудолюбивые разработчики должны получать большую зарплату, возможность покупать акции компании, иметь парковочное место, медицинскую страховку, больший офис или множество других плюшек. Это похоже на то, как владелец завода платит рабочим один доллар за каждую тонну чугуна, которую они загрузят в вагон. Такие стимулы называются внешними вознаграждениями.
Внешние поощрения широко распространены в различных сферах: от финансов до правительства и промышленности. Но в геймдизайне они провальны. На это есть четыре основные причины.
Первая причина. Геймдизайн сложно оценить извне, поэтому внешнее поощрение и не работает в играх. Чтобы дать кому-то денежную «морковку» за хорошую работу, мы должны знать, когда этот человек поработал хорошо, а когда – плохо. Оценить работу рабочего с чугуном легко. Мы можем увидеть результат, и все, что нужно, – это подсчитать количество слитков в вагоне. Но в играх очень трудно увидеть качество приложенных усилий. Разные разработчики вносят разный вклад, а разработка игр настолько неопределенна, что даже хорошая работа может привести к катастрофе в результате неудачного стечения обстоятельств. Хорошие дизайнеры, готовые рисковать, могут оказаться на плохом счету по сравнению с теми, кто работает посредственно и не желает идти на риск, так как некоторые из их попыток неизбежно заканчиваются неудачей. Не существует хорошего способа измерить производительность, следовательно, и не существует способа определить поощрение.
Вторая причина. Поощрения вытесняют нашу внутреннюю любовь к работе. Хорошим разработчикам нужны деньги, но для многих из них это не главная причина работать в этой сфере. Большая часть их мотивации гораздо более субъективна. Они хотят создать что-то великое, явить это миру и, возможно, получить признание. Хотят решать сложные задачи. Хотят уважения, авторства и автономии. В повседневной работе они, возможно, не думают о какой-либо более высокой цели, кроме как не подвести своих коллег. Деньги нужны им только для того, чтобы прокормить семью. Если сделать заработную плату определяющим фактором, то легко разрушить внутреннюю мотивацию работать в свое удовольствие. Люди забывают, что они работают из-за интереса, и начинают верить, что работают ради денег. Бонусы в игре могут вытеснить внутреннее удовольствие от процесса игры. Вот почему дорогостоящие юристы не будут предлагать свои услуги нуждающимся пенсионерам за 30 долларов в час, они предложат их бесплатно, а случайные прохожие бесплатно помогут вам выгрузить диван из грузовика, и не возьмут с вас и цента. Пол Маккартни был прав – любовь не купить.
Отрицательное влияние внешних вознаграждений сильнее всего проявляется в творческих задачах. Тереза Амабайл, профессор Гарвардской школы бизнеса, провела многолетнее исследование креативности на реальных рабочих местах. На основании 12 тысяч ежедневных записей в журналах, полученных от 238 креативных сотрудников из семи различных компаний, она искала взаимосвязь между эмоциями, событиями и творческим результатом. Большинство сотрудников говорили о том, что внешнее поощрение вообще не мотивировало их, а те, кого больше всего интересовали деньги, не очень преуспели в творческих задачах. Респондентов в большей степени мотивировали сложные задачи, общность, командный дух и ответственность.
Третья причина. Внешнее поощрение часто создает искаженные стимулы, которые не идут на пользу проекту. Когда каждый сосредоточен на максимальном увеличении своего бонуса, разработка игр превращается в политическую игру. Политика и сплетни ведут к разрушительной конкуренции среди разработчиков. Страх наказания заставляет скрывать результат и избегать риска. Чтобы оставаться в безопасности или завоевать уважение, разработчики могут объединяться в «банды» и отказываться предоставить информацию тем, кто в них не входит. Эта модель подтверждается исследованиями. Амабайл выяснила, что конкуренция подавляет творчество и движение идей и не позволяет людям помогать друг другу. Дэн Ариэли обнаружил, что участники теста, в котором нужно составить предложения, расставив слова в правильном порядке, гораздо реже помогают другим, если расшифровывают слова о деньгах. Наполнение сознания мыслями о долларах делает нас склонными к риску и эгоистичными – худшее поведение для группового творчества.
Четвертая причина. Внешние стимулы отвлекают от работы. Разработчики перестают думать о том, как улучшить игру, их мозг занят мыслями о том, как заполучить бонус больше. А каждая минута, потраченная на мысли о вознаграждении, – это упущенное время, в течение которого разработчик не решал задачи разработки.
Еще хуже, когда внешними стимулами является наказание. Босс может угрожать уволить кого-то, урезать зарплату, наорать или даже проявить неуважение, закатывая глаза в ответ на любые предложения. Подобные угрозы могут привести к немедленной бурной деятельности, но одной деятельности недостаточно, чтобы сделать крутую игру. Геймдизайн требует открытого обсуждения и глубоких размышлений, а под давлением это невозможно. Помните, что страх и гнев подавляют верхнюю височную извилину, отвечающую за творчество? Как писал Фрэнк Герберт в «Дюне», страх убивает сознание – если мы боимся, то неспособны в полной мере раскрыть свои творческие возможности. Вот почему Амабайл обнаружила, что люди, вероятнее всего, совершат прорыв, будучи радостными и счастливыми. Работа в радость позволяет разуму расслабиться и способствует высокоэффективным размышлениям. Страх, вызванный внешними угрозами, может мотивировать, но при этом он может подавлять способность свободно мыслить и выполнять работу должным образом.
Все это может случиться сразу. Например, рассмотрим систему, о которой я когда-то слышал: если разработчики представляли что-то классное на совещаниях в стиле «покажи и скажи», то получали за это ваучеры на покупки в интернете. Эта система – почти абсолютное зло. Люди начинают чувствовать, что работают ради ваучеров, а не ради работы, поэтому теряют интерес к тому, что делают. Сотрудники, которые выполняют неочевидные технические задачи «за кадром», обижаются на тех, кто делает визуально заметную работу, которую показывают на презентациях. Сотрудники тратят время на усовершенствование своей презентации «покажи и скажи», а не делают работу, которая действительно улучшит игру. Им приходится тратить время на размышления о дурацких ваучерах и о том, смогут ли они их получить. В итоге они будут ненавидеть систему, которая обращается с ними как с собакой Павлова.
Значимая работа
Так как же нужно мотивировать разработчиков? Не стоит поощрять геймдизайнеров деньгами за механику или за идею – это приводит к появлению бесполезных механики или идей. Наказание за неудачные идеи, прототипы или тесты только подавляет готовность рисковать, а это вредит инновациям. Награда за отработанное время приводит к появлению большого количества тел на стульях и не способствует реальной производительности. Поощрение отдельных сотрудников за что-либо вообще приводит к зависти и нездоровой конкуренции в команде. Поощрение части сотрудников делит команду на бездельников и неофициальных рабовладельцев. Кажется, что все приведет к неминуемой катастрофе.
Тем не менее в мире появляются новые игры, и некоторые весьма хороши. Хотя проблема мотивации структурно очень сложна, ее возможно решить, зная кое-что о разработчиках.
Разработчики хотят выполнять значимую работу.
Больше всего творческие люди хотят делать работу, которая в мире будет значима. Разработчики будут изо всех сил искать подходящий способ улучшить игру. Никому больше даже не нужно подробно разбираться в том, что он делает, потому что мотивация идет изнутри. Если разработчик знает, что успешно справился с задачей, он будет рад. Если нет, то расстроится.
Но не всегда можно предложить такую значимую работу, особенно в больших студиях. Существует неочевидный способ создания значимой работы. Задача должна приносить пользу. Однако есть и другие важные свойства значимой работы. В идеале она должна предлагать творческий труд, сбалансированные сложные задачи, гордость, признание, право собственности, ощущение востребованности, ответственность и свободу. Задача организации команды заключается в создании среды, которая последовательно обеспечивает работу, предполагающую эти ценности. Джон Лассетер, аниматор студии Pixar, выразил это так:
«Творческим людям быстро становится скучно, они зависимы от настроения и работать с ними непросто. Необходимо позаботиться о них, а также о том, чтобы им было весело. Творческие люди делают действительно хорошую работу, только если перед ними поставлена интересная задача. Им должно нравиться то, над чем они работают. Они должны сильно гордиться тем, что являются частью проекта. Это задача менеджера. Каждый раз вы должны ставить перед ними творческие задачи. Это сложно, но никто не говорил, что работать с творческими людьми легко».
Чтобы креативный разработчик был доволен, не нужна «денежная морковка». Нужно сочетание ответственности, доверия, сложных задач и веры в проект. Кроме того, как отмечает Лассетер, чем лучше люди, тем труднее их мотивировать. Незаинтересованные, посредственные разработчики не чувствуют неудовлетворения, работая над неинтересными задачами, потому что незаинтересованность является их нормальным состоянием. Они – как разнорабочие, работают исключительно за деньги. Великие дизайнеры живут неконтролируемым потоком идей и амбиций. Они должны давать им выход, в противном случае они становятся несчастными. Эта черта характера является как источником их способностей, так и причиной, по которой им «быстро становится скучно, они зависимы от настроения и работать с ними непросто».
Наиболее труднодостижимая цель в системе поощрения разработчиков – САМООПРЕДЕЛЕНИЕ.
Самоопределение предполагает, что разработчик воспринимает себя как часть той работы, которую он делает. Если мотивация находится на этом уровне, разработчик будет размышлять над проектом в душе, в машине и даже когда спит. Он будет тратить любую свободную минуту на размышления над идеями и поиски возможностей и решений. Будет настолько глубоко погружен в этот процесс, что окружающих будет раздражать его рассеянность. Он будет записывать идеи на салфетках или носить с собой блокнот. Будет искать варианты решения задачи, может прийти на работу в любое нерабочее время или встать посреди ночи, чтобы записать идею, которая ему приснилась. Работа больше не просто работа. Это его гордость и цель.
Самоопределение – это целая несокрушимая стихия. Именно так стартапы побеждают гигантские корпорации, как и братья Райт опередили богатого Сэмюэля Лэнгли. Большинство компаний никогда не видят этого, потому что они убивают самоопределение денежной «морковкой» или «эффективными» управленческими методами. Берегите самоопределение, оно может творить чудеса.
Настроение
В благоприятной среде люди чувствуют прилив энергии и безопасность. Они достаточно защищены, чтобы рисковать и задавать вопросы, а их мозг сосредоточен на работе. В плохой неблагоприятной среде они злятся и чувствуют страх. Страх нейтрализует их способность к творчеству, и они тратят всю свою энергию на уклонение от ответственности.
НАСТРОЕНИЕ – это эмоции, которые люди ежедневно испытывают на работе.
Среда зависит от ожиданий людей того, как к ним будут относиться. Если они рискуют, а идея проваливается, ожидают ли они того, что их обвинят, или же ждут, что их успокоят? Если они спрашивают о чем-то руководителя, ожидают ли они подробного ответа или словесной пощечины? Если разработчики чувствуют опасность, они будут работать в страхе и намного хуже своих возможностей. Если они чувствуют благоприятную обстановку и поддержку, они будут идти к цели и рисковать.
Рассмотрим разработчика с крутой, но рискованной идеей. Он решает, рассказать о ней или забыть ее. Он хочет сделать игру хорошей, но его также волнует его социальный статус и эмоциональное благополучие. Таким образом, он инстинктивно просчитывает плюсы и минусы. В благоприятной творческой среде это выглядит так:
Очевидно, что дизайнер расскажет об идее. Это лучший результат для игры и студии. Идея может провалиться, но решение рассказать о ней было правильным. И остается шанс, что эта идея превратит игру в хит.
Теперь рассмотрим пример студии, в которой витает атмосфера вины, страха и неправомерного распределения власти:
В такой атмосфере идея остается похороненной. И поскольку этот шаблон повторяется тысячи раз, игра не может развиваться, потому что никто не рискует. Через год или два все задаются вопросом, почему игра такая легкая, такая неоригинальная, такая безопасная. Обзорщики не дают ей положительных отзывов, и игра умирает.
Обычно никто не понимает, что произошло, потому что плохая атмосфера – молчаливый убийца. Она не приводит к катастрофам разработки. Скорее она делает так, что хорошие идеи не реализуются. Она делает так, что люди не предлагают рискованные идеи и не ведут необходимые дебаты. И хотя никто этого не замечает, отсутствие вышеуказанных параметров ежедневно наносит игре непоправимый вред.
Среда является одним из самых важных факторов, определяющих качество игры, потому что наполняет все. Она меняет отношение людей, их мысли и действия в любом месте, каждую секунду, каждый день.
Страх и любовь
Бывают такие руководители, которые в качестве мотивации используют гнев. Чтобы подтолкнуть людей, они любят прибегать к таким методам, как крик, изощренные оскорбления и вздохи разочарования. Суть состоит в том, что угроза эмоциональной боли не даст людям лениться.
В других областях такой подход может быть эффективным. Как-то я смотрел документальный фильм о том, как знаменитый британский шеф-повар Гордон Рамзи руководил подчиненными на своей кухне. Он все проверял. Малейшая ошибка в блюде или его приготовлении приводила его в бешенство. Он кричал на поваров и официантов за мельчайшие ошибки. Он увольнял по человеку каждую неделю. И это хорошо работало – Рамзи получил самые высокие награды. Но рассмотрим характер работы. Метод Рамзи заключался в поддержании стандартов. Его ресторан был великолепен не благодаря креативности его команды, а благодаря способности прекрасно выполнять четко определенные процедуры приготовления и подачи блюд. Проверки Рамзи были эффективными, потому что опытный шеф-повар легко замечал ошибки в приготовлении пищи. Нет никакого смысла в том, чтобы персонал кухни был креативным или рисковал во время приготовления или подачи ужина.
Но разработка игр – это другое. Дизайн требует рисков, неудач и креативности на всех этапах разработки. Гнев и страх разрушают готовность людей идти на риск и их способность к творческой работе. Самоопределение становится невозможным, если вас всегда заставляют танцевать, стреляя при этом в ноги.
Гнев манит, потому что на первый взгляд выглядит эффективным. Руководитель кричит и видит, как ленивые разработчики начинают суетиться. Но он не видит, как меняется желание 30 сотрудников, наблюдающих за этой живописной картиной, рисковать в дальнейшем. Он не понимает рискованную, но интересную мысль о том, что подчиненный теперь будет бояться его.
Великий кукловод Джим Хенсон всегда хорошо обращался с сотрудникам и никогда не кричал на них. Джим говорил: «Вы хотите на Луну. Вы должны стремиться к Юпитеру. Если вашей целью будет Юпитер, вы обязательно попадете на Луну». Он руководствовался вдохновением, совместной работой и признательностью. Он сосредоточился на других, а не на себе. Находясь на вершине власти, владея миллионами долларов и домами на нескольких континентах, он оставался добрым и отзывчивым. Люди работали на него из любви. Они рисковали, потому что им было нечего бояться. Они отдавали ему все, потому что им не нужно было тратить энергию на то, чтобы защищаться. Их самоопределение сработало, и команда Джима оставалась на вершине в течение десятилетий.
Джим не направил все свои силы на немедленное поощрение. Он не поддался желанию властвовать над сотрудниками. Он понимал, что его работа состоит в том, чтобы «создавать» других для достижения успеха, а не использовать их в качестве инструментов, что его команда была гораздо важнее, чем он сам.
Чтобы собрать урожай щедрости любви, нужно терпение. Страх – это легко, быстро и очевидно, но, в конце концов, это слабое топливо для творчества. Любовь медленная, косвенная и тихая, но будучи взращенной, необычайно сильна. Только любовь может выпустить самоопределение, благодаря которому каждый разработчик сможет извлечь творческую силу из своей сути.
Вот почему в приемной своей студии Хенсон установил гигантскую табличку со старой цитатой Г. К. Честертона: «Художественный темперамент – болезнь, которой подвержены все любители».
Социальная мотивация
Мы уже видели, что внешние поощрения могут нарушить мотивацию разработки игр, но в то же время это единственный внутренний стимул выполнять значимую работу, благодаря которому можно создать наше лучшее произведение. Но иногда все еще есть место для особых, мотивирующих стимулов для вдохновения. Ключевым моментом здесь является не экономическое поощрение или наказание, а более тонкие социальные сигналы. Давайте рассмотрим некоторые виды мотивации, которые настраивают разработчиков игр на нужный лад.
Плейтесты как вид мотивации
Плейтесты хорошо мотивируют, создавая естественные, неограниченные, заслуживающие доверия результаты принятых решений разработки.
Конечно, хотелось бы, чтобы тестировщикам нравилось то, что мы сделали. Здорово, когда они просят поиграть еще. С другой стороны, это ужасно – видеть, что тестировщику скучно, слишком сложно или он находит в игре баги. Удовольствие от успешного и боль от неудачного плейтеста являются сильнейшей мотивацией.
Это похоже на метод кнута и пряника. Но этот метод отличается от стимулов, которые предлагает начальник.
Во-первых, результаты плейтеста являются прямым, естественным следствием. Это не система поощрений, созданная одним человеком с целью манипуляции. Это реальные результаты из реальной жизни. Другими словами, плейтест не работает как кнут и пряник.
Во-вторых, если мы используем плейтест как средство мотивации, не нужно ограничиваться мыслями о том, чего от нас ждет начальник, или полагаться на его понимание. В погоне за одобрением босса мы ограничены его пониманием игры. Выше головы не прыгнуть. Вы всегда ограничены пониманием человека, который вас оценивает. Но если вы работаете над реальностью, а не гонитесь за оценкой, то ничем не ограничены и можете раскрыть весь свой творческий потенциал. Игра всегда может понравиться тестировщику еще сильнее, чем раньше.
Наконец, тестировщики заслуживают доверия. Они не поощряют нас за то, что мы придерживались того же мнения или предположений, что и босс. Они поощряют нас за объективно хорошую работу. Разработчики не сомневаются и не бунтуют против реакции тестировщиков на игру так, как если бы они сомневались или бунтовали против манипулятивных мнений руководителя.
Ожидания как вид мотивации
Если вы относитесь к людям так, как будто они работают хорошо, они будут работать хорошо.
Если все относятся к вам как к дураку, вы можете просто начать играть роль дурака или даже поверить в то, что так оно и есть. Если все смотрят на вас с восхищением, вы начнете копаться в своих идеях, говорить уверенно и раскрывать свои способности думать лучше, так как хотите соответствовать этому образу.
Этот эффект повсеместен. Например, исследователи выяснили, что женщинам сложнее сдать экзамен по математике, чем мужчинам, только если вы не скажете им, что и у женщин, и у мужчин одинаковые способности к этой науке. Их ожидания меняют их убеждения в том, что они могут сделать на самом деле, что, в свою очередь, влияет на то, что они делают. Другое исследование показало, что если учителям говорили, что какие-то дети, возможно, являются гениями, то эти ученики показывали более высокий результат, чем остальные дети, даже если это были совершенно обычные дети, выбранные случайным образом. Учитель относился к ним как к умным, и вели они себя соответственно.
Некоторые пытаются делать наоборот. Они плохо относятся к другим, пытаясь заставить их работать лучше. Такие люди слепо верят, что человек разозлится и, пытаясь всем доказать их неправоту, станет работать гораздо лучше и усерднее. Но это не работает. Хуже некуда, когда с тобой обращаются как с некомпетентным сотрудником. Человек злится, это разрушает творческие способности и создает чувство беспомощности. Если вы проделали хорошую работу, а с вами обращаются как с идиотом, зачем продолжать эмоционально вкладываться в нее?
Лучшие игровые команды стремятся стимулировать чувство элитарности. Они развивают дух товарищества вокруг определенного знака или идеи, которые отделяют их от других. При этом они могут быть разработчиками среднего уровня, но вера в избранность команды побуждает их делать больше. Именно поэтому у Уолта Диснея не было обычных дизайнеров тематических парков, у него были имаджинеры (Imagineers). Вот почему армии постоянно подчеркивают уникальную историю каждого подразделения. Чувство элитарности создает прецедент быть достойным и укрепляет внутреннее чувство индивидуальности. У разработчиков, к которым относятся как к посредственностям в сером типичном офисе с перегородками, нет причин быть лучше. Выделите этих людей, позвольте им создать что-то уникальное, и они оправдают ожидания.
Резиновая курица как мотиватор
Несерьезные, неявные, случайные социальные награды и наказания могут донести информацию, не нарушая творческую среду.
Рассмотрим пример «сломанных компиляций». В разработке видеоигр ошибка в одной строке кода, или, иначе говоря, плохо сконфигурированная часть содержимого либо недопустимый сюжет, может испортить весь код в случае попадания в центральную базу данных, вследствие чего игра ломается. В результате команда несет большие потери, поскольку продолжение процесса разработки возможно только после устранения ошибки.