В большинстве проектов используются разного рода системы отслеживания, такие как Jira. Но их точность и эффективность ограничивают пользователи. По разным причинам студии редко используют все возможности систем отслеживания: главные из них – человеческий фактор и разные нужды каждого отдела. В теории системы отслеживания должны давать полную картину по темпам работ и производительности в студии, но на практике у каждой команды данные разного качества и точности. Кроме того, каждая студия использует систему слежения с разной степенью добросовестности. Мой опыт говорит, что по мере нарастания неточности данных команды начинают игнорировать систему, а то и отказываются от нее, поскольку отбраковка информации и ревизия логов становится неподъемной задачей. Я слышал о продюсерских отделах, которые каждое утро обходили рабочие места разработчиков одно за другим и извещали каждого о его новом задании в Jira, чтобы избежать коллапса системы. Это может показаться слишком времязатратным, но альтернатива гораздо хуже.
Продюсерский отдел может использовать многие инструменты отслеживания, если внедряют их согласно стандарту и добиваются, чтобы команда тоже его соблюдала. Внедрение означает регулярное обновление индивидуальных задач, использование единых правил категоризации и нейминга, задача ясной шкалы приоритетов и правил назначения. Продюсеры не допускают, чтобы задания или баги накапливались только у одного лида; следят за тем, чтобы старые задачи правильно датировались и закрывались; устанавливают строгие форматы для сообщений о багах и прилагаемой к ним информации.
Одна из трудностей для продюсерского отдела заключается в том, что каждый отдел использует систему слежения по-разному согласно специфике его работы. Художники применяют не такие нормы, как программисты. Сроки исполнения оценивают по-разному. Сами этапы выполнения бывают обусловлены большим числом взаимозависимостей или исполнителей. Подразумевая, что у каждого отдела свой продюсер, эти разные подходы к использованию системы можно свести в единый формат, который учитывает потребности каждого отдела. Это достигается их точным переводом на общепонятный язык релевантных данных календарного графика.
Для небольших проектов и команд проблема стоит не так остро. Однако с потерей способности точного долгосрочного планирования открывается ящик Пандоры. Худшая из бед – сваливание в сумеречную зону постоянно съезжающих дедлайнов, за которыми не видно прогресса проекта в конкретном направлении. Не завидую гейм-дизайнеру, работающему в таких условиях, даже если он радуется наступившей «свободе» дизайнерского творчества: она полностью обесценивается наступающим хаосом. Гейм-дизайн без жестких дедлайнов и ограничений едва ли жизнеспособен, и игровая индустрия повидала множество похороненных проектов, где дизайн плавал в туманном море пропущенных дедлайнов. Даже если игра и выходила, то лишь спустя годы работы в невыносимых условиях, с бешеной текучкой, месяцами кранчей и коммерческим провалом в итоге.
Точно оценивать дизайнерские задачи непросто. Продюсер может запросить детализацию, которую сложно провести, но попытайтесь дать точную оценку, когда это возможно. С опытом вы многому научитесь, но начать непростую работу по оценке дизайнерских заданий можно с простого разбивания каждого из них на составные части.

Типы дизайнерских задач
• Концепт-исследование. На стадии препродакшена или даже раньше, до выделения бюджета и составления календарного плана, гейм-дизайнеры могут позволить себе роскошь проанализировать абстрактные идеи для их следующего проекта. В разных студиях этот процесс называют по-разному, но я предпочитаю термин «исследование»: это лучше всего описывает связанную с ним работу. Концепт-исследование подразумевает частые дискуссии, много чтения, просмотра видео и фильмов и долгие размышления. Все это трудно отследить и расписать в рабочем графике, да и результаты с производственной точки зрения оценить непросто. Когда такую задачу можно считать выполненной? Что подразумевается под готовой концепцией? Не пытайтесь ответить на эти вопросы; лучше выставьте концепт-исследованию жесткий дедлайн и до этого срока позвольте гейм-дизайнерам делать все, что они смогут. Срок может составить от недели до нескольких месяцев, в зависимости от масштаба проекта. Это предоставит дизайнерам свободу, которая стимулирует их творческие процессы, чтобы они нащупали и сформулировали идею. При этом они будут ясно сознавать, когда им следует прекратить исследования и обдумывания и что нужно оформить концепцию в полноценный документ для рассмотрения руководством. Не стоит контролировать этот процесс до наступления дедлайна, за исключением случаев, когда ваша дизайнерская команда недостаточно опытна, и ход ее работы нужно время от времени проверять.
К концепт-документу могут прилагаться ранние прототипы, концепт-арты, некоторые ранние геймплейные наработки студии, но это целиком зависит от технологии, требований студии и выделенного времени. Итогом стадии концепт-исследования должен быть как минимум концептуальный документ. Его рекомендуемое содержимое описано далее в этой главе.
• Дизайн-документация. Эта задача сохраняет актуальность с предпродакшена вплоть до альфа-версий. Любой игровой функционал должен быть продуман и описан в разрезе его назначения и характеристик механик и систем. Степень детализации таких документов лучше ограничить изложением общего ви́дения и основных элементов игры [17].
Вся дизайн-документация, рассылаемая дизайнерским отделом, должна быть выполнена в едином формате, стиле и разметке. Это помогает дизайнерам ориентироваться в документации и поддерживать ее высокое качество, да и другие отделы с большей вероятностью ее прочтут, что по само себе непростой труд. (Читатель может удивиться, что команды разработчиков неохотно читают дизайн-документацию и мало кто прочитывает ее полностью!) Любые средства повысить читабельность документации и заинтересованность читателя (тут не помешают мемы) увеличат шансы, что коллеги-разработчики прочтут ваши труды!
Временны́е затраты на написание дизайн-документации оценить непросто, поскольку творческие процессы непредсказуемы, и дизайн вырисовывается в череде открытий в прототипировании и итерациях. Но согласно продуктивному подходу, написание дизайн-документации проходит через три последовательные стадии: драфт (нулевая версия), первая версия и окончательно утвержденная версия.
Драфт
Драфты – это наброски, описывающие главное назначение каждого функционала и его основные компоненты в аспекте разработки. Каждый дизайн-документ должен содержать следующее.
• Назначение. Это главный смысл игрового элемента с точки зрения игрока. Перечислите, в чем заключается его увлекательность, какова предполагаемая реакция игрока на данное игровое действие и какой его вклад в совокупный игровой опыт. Этот раздел сжат и конкретен; по сути это аргументация за внедрение данного функционала.
• Описание структуры. Основная часть документа с последовательным описанием функционала. Включает иллюстрации, диаграммы, схемы, которые разбавляют документ визуальными привязками и дополняют описание графикой, без которой текст воспринимается труднее. Мое правило – одна иллюстрация на страницу, не обязательно крупная или детализированная. Она нужна, чтобы подсказать читателю, какую часть документа он читает, и проиллюстрировать излагаемую тему. Например, если страница описывает ближний бой, то картинка с поединком двух бойцов будет вполне уместной. Описание структуры должно быть удобочитаемым и упорядоченным, с пронумерованными пунктами. Например:
Структура ближнего боя
1. Рукопашный бой
2. Фехтование на мечах
3. Атаки «натиск-удар»
На собрании команды такая разметка сориентирует всех, какая часть документа в данный момент рассматривается, особенно если не все участники находятся в одном помещении.
Описание структуры не может охватить каждый аспект функционала, поэтому не приводите подробные списки в таких документах. Иначе их будет трудно воспринимать. Для детализации используется документация другого типа, которую я называю «характеристики функционала» и о которой расскажу далее в главе.
• Комментарии дизайнера. Последняя часть документа, в которой представлен идейный базис функционала и любые возможные его варианты – например, более простой в реализации план «Б». Здесь также могут быть идеи для обдумывания на будущее; преимущества, которые дизайнер счел решающими; прочие соображения, раскрывающие обоснования этого и других дизайнерских решений. Команде иногда полезно осознать рациональные основания дизайна и понять, почему было принято то или иное решение. Это поможет ответить на массу вопросов, которые иначе будут постоянно всплывать на последующих собраниях. Другой позитивный эффект – укрепление доверия команды к гейм-дизайнеру и его решениям.
Драфт дизайн-документа предназначен для внутреннего пользования команды. Его можно показать коллегам, пояснив, что это нулевая версия, которую ждет множество правок, и, следовательно, не являющаяся заданием. Объявление драфтов способствует выработке консенсуса и дает командам темы для обсуждений, чтобы они смогли подготовить вопросы.
Драфт обсуждается с креативным руководством студии и подлежит официальному утверждению, чтобы стать первой версией дизайн-документа.
Первая версия
Это версия дизайн-документа, в которой учтены все замечания и изменения, возникшие по ходу рассмотрения драфта. Цель – создать документ, пригодный для использования командой. Разработчики читают его, зная, что основная часть его содержимого войдет в игру. Само содержимое остается теоретическим; дизайн-документ – это не сборник разнарядок на выполнение работ. Но он дает командам четкое понимание назначения функционала, его основные компоненты и производственные перспективы.
Первая версия оценивается старшими руководителям команды, которые часто имеют собственное мнение и вносят свои правки. Их должен учесть отдел гейм-дизайна, после чего дизайн игры считается финальным.
Окончательно утвержденная версия
В ней описаны все составляющие игры, рассмотренные, исправленные, обновленные и утвержденные старшим руководством команды. Это значит, что у всех глав отделов была возможность изучить документ и внести свои замечания. Это может быть или обсуждение дизайна с участием всех ключевых участников проекта, или постоянное обсуждение, организуемое продюсерами, которые получают одобрение от каждого отдела в свое время.
После окончательного утверждения дизайн-документа он появляется в базе дизайнерской документации. Доступ к нему имеет каждый член команды, зная, что эти материалы рассмотрены, обсуждены и утверждены официально и окончательно. С этого момента отдел гейм-дизайна несет ответственность за его сопровождение. Дизайн-документы полезны до определенного момента. После альфа-версии их актуальность снижается, поскольку начинаются сокращения контента и функционала, а ключевые элементы переделываются. В идеале у дизайнеров есть время на обновление каждого утвержденного дизайн-документа согласно произведенным изменениям. Однако в реальности сопровождение документации занимает у дизайнеров слишком много времени в ущерб другим их обязанностям разработчиков.
Это одна из причин полагаться на дизайн-документацию третьего уровня – характеристики функционала (FD).
Характеристики функционала
Это тип документов с достаточным уровнем детализации, чтобы по ним работали все отделы. Он созданы в простом формате, удобном для ознакомления, и содержит полную информацию в минимуме слов. Лучшая формулировка, описывающая такие документы, – дизайн-псевдокод.
Впервые примененный в Ubisoft, FD стал ответом на потребность в точной передаче информации о функционале огромным коллективам с разным владением английским языком. Идея была в сокращении текстовой составляющей дизайн-документа и сведении его к базовым фразам. Таким образом, каждый отдел мог получить из него конкретную задачу для исполнения.
Но волшебство на этом не заканчивается. Формат FD – полноценное производственное задание и регрессионный список для отдела обеспечения качества (QA).
Для записи характеристик функционала используются электронные таблицы, например в формате Excel. Типичный FD-документ содержит следующие разделы.
• Название. Название функционала.
• Проект. К какому игровому проекту относится этот функционал.
• Гейм-дизайнер. Имя дизайнера, ответственного за этот функционал. К нему каждый может обратиться с вопросом/просьбой пояснить или изменить данный документ. Дизайнер ответственен за обновление документа по ходу разработки.
• Назначение. Этот параграф повторяет главный смысл данного функционала с точки зрения игрока. Здесь можно привести фрагмент из дизайн-документа или его резюмировать: какое действие обеспечивает данная функция и как оно встроено в общую структуру игры. Это помещает остальную информацию в документе в нужный контекст.
• Описание. Это основное содержимое документа, построчная роспись, которая детально раскрывает механику действия функционала.
Каждая строка описывает отдельную функцию. Приведу несколько примеров.
• Как активировать функционал (нажатие кнопки, взаимодействие и т. д.)?
• Сколько продолжаются эффекты, вызванные в игре (длительность)?
• На какую зону воздействует функционал в игровом мире?
• Связь этого функционала с каким-либо ИИ-поведением.
• Изменения в ИИ-поведении, связанные с активацией функционала.
• Изменения в инвентаре или в активных слотах.
• Элементы UI, связанные с функционалом.
• Пункты меню.
• Изменения в прохождении.
• Боевые эффекты, усиления, ослабления, перезарядки и остановки.
• Анимации, связанные с функционалом.
• 3D-ассеты, связанные с функционалом.
• Эффекты на системах частиц или визуальный отклик.
• Звуковые эффекты или звуковой отклик.