Статьи

Воркфлоу и пайплайны гейм-дизайнера

Данная статья похожа на статью для менеджера проекта или того, кто выполняет его обязанности. Но я часто по тем или иным причинам участвую в формировании процессов и уже прошёл через несколько разных подходов. Так что решил поделиться последними практиками, которые нам удалось ввести в команде (и нам стало лучше!). Возможно, ведущим дизайнерам или тем, кто занимается организацией работы в небольших командах, тоже будет интересно почитать. Заранее оговорюсь, что любые процессы должны помогать достижению поставленных целей именно вашей команде, так что не стоит ничего брать за чистую монету потому, что у других людей тот или иной подход работает.

Ответственность гейм-дизайнера

У нас небольшая команда, мобильная игра и почти фиксированный цикл разработки каждой версии (допустим, релиз раз в месяц, а дата релиза известна за 2 месяца). И циклы, и подходы к разработке, и релизный пайплайн со временем менялись, как и состав команды разработки. И чтобы эффективно продолжать работать, процессы нужно улучшать.

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

Гейм-дизайнеры проекта работают одновременно над 4 версиями:

  • PRODUCTION aka LIVE
    • Поддержка ивентов
    • Анализ выпущенных фичей
  • RELEASE CANDIDATE aka RC
    • Финальная проверка версии и конфигов
    • Подготовка ивентов
  • DEVELOPMENT aka DEV
    • Поддержка разработки (общение с разработчиками и актуализация документации)
    • Плейтесты
  • PRE-PRODUCTION aka PREP
    • Концептирование и препродакшн фичи
    • Написание дизайн-документации

Последний этап (который на самом деле первый) я как раз и буду разбирать в следующей главе, так как на данный момент у нас это самый затратный в плане времени и сил этап для гейм-дизайнеров.

Процесс дизайна фичи

Этап, который начинается с предложения той или иной фичи и завершается презентацией фичи всей команде. Рассмотрим весь пайплайн в деталях.

Feature Request (Запрос)

  • Участники этапа
    • Кто угодно
  • Описание этапа
    • Краткое описание фичи, объясняющее базовую механику, цели, мотивацию игроков и целевые KPI
  • Результат этапа
    • Эпик в статусе BACKLOG
    • Питч-документ

Та или иная задача может взяться откуда угодно — просто родиться в чате или на совещании, либо появиться в результате анализа статистики. Каждую неделю мы проводим одно совещание, во время которого делимся тем, что дизайнеры успели за неделю, что собираются делать дальше и обсуждаем следующую версию, чтобы удостовериться, что все в курсе, какие фичи мы делаем и собираемся делать, и устаканиваем видение дальнейшего развития проекта. И ещё одно совещание раз в 1-2 недели, на котором с продюсером и аналитиками обсуждаем находки и результаты анализа выпущенных фичей, чтобы определить, что мы можем предпринять для их улучшения.

Новые большие задачи сразу выносятся в Epic в статусе BACKLOG. Готовый питч представляется тем, кто отвечает за видение проекта (в нашем случае: продюсеру и креативному директору). Если на таком абстрактном уровне фича выглядит привлекательной, то дизайнеры начинают свою работу.

Concept (Концептирование)

  • Участники этапа
    • Гейм-дизайнеры
  • Описание этапа
    • Расширение питча до базового концепта с основными механиками и совместимостью с текущей версией игры
  • Результат этапа
    • Эпик в статусе CONCEPTING
    • Концепт-документ

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

Production Evaluation #1 (Первичное обсуждение)

  • Участники этапа
    • Продюсер
    • Ведущий гейм-дизайнер
    • Ведущий аналитик
  • Описание этапа
    • Обсуждение объёма фичи, цели, KPI и соответствует ли концепция поставленным целям
  • Результат этапа
    • Greenlight — ответ на вопрос «Что делать дальше?» — отложить, доработать или убить фичу

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

Polished Concept (Работа над ошибками)

  • Участники этапа
    • Гейм-дизайнеры
  • Описание этапа
    • Полировка концепта по результатам обсуждения и подготовка к техническому анализу
  • Результат этапа
    • Финальный концепт-документ

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

Architects’ Review (Технический анализ)

  • Участники этапа
    • Архитекторы (Client, Server, GUI)
    • Тимлид QA
  • Описание этапа
    • Оценка фичи на предмет технических ограничений и изменений в архитектуре проекта
  • Результат этапа
    • Риски и ограничения
    • Оценка трудозатрат

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

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

Объём оценивается не в часах, а в поинтах, т.е. скорее сложность. Так как в версии обычно несколько фичей и концепты зачастую готовы все вместе (чтобы участники этого этапа могли пройтись по всем документам сразу), то оцениваются они по 10-бальной шкале, где 10 — самая сложная фича в версии.

Production Evaluation #2 (Финальное решение)

  • Участники этапа
    • Продюсер
    • Ведущий гейм-дизайнер
  • Описание этапа
    • Оценка трудозатрат и ценности фичи в разрезе следующей версии
  • Результат этапа
    • Определение версии, в которую войдёт фича
    • Эпик в статусе TO DESIGN
    • POINT OF NO RETURN — последний шанс «убить» фичу

Финальный этап настоящего препродакшна, в результате которого становится понятно, войдёт ли фича в предстоящую версию, либо отложится на следующую версию (если фича большая и её нужно разрабатывать 2 версии, например). Отложить на более чем 1 версию нельзя — большая вероятность, что фича станет неактуальной и её нужно будет переработать. Т.е. если приходит понимание, что ни в следующую, ни в версию после неё фича не войдёт, то её нужно «убить» — даже если это значит, что она просто вернётся в BACKLOG до поры до времени.

Design Completion (Завершение дизайна)

  • Участники этапа
    • Гейм-дизайнеры
  • Описание этапа
    • Подготовка документации, мокапов, событий для статистики и базовой версии баланса и экономики
  • Результат этапа
    • Эпик в статусе DESIGN IN PROGRESS
    • Полноценная документация по фиче

Кто-то считает данный этап уже разработкой. Но для нас этап DEVELOPMENT начинается тогда, когда программист или художник начинает работать над конкретными задачами. А ведь задач ещё нигде и нет.

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

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

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

Estimation & Tasking (Создание задач и их оценка)

  • Участники этапа
    • Все причастные к разработке
  • Описание этапа
    • Разбивка документации на задачи и их оценка исполнителями
  • Результат этапа
    • Эпик, наполненный задачами (User Stories, но об этом позднее)
    • Эпик в статусе OPEN FOR DEV
    • UML-дизайн

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

Team Presentation (Презентация)

  • Участники этапа
    • Гейм-дизайнеры
    • Вся команда
  • Описание этапа
    • Презентация фичи следующей версии (или всех сразу) с живым обсуждением
  • Результат этапа
    • Понимание состава следующей версии всей командой
    • Понимание, кто из команды над чем будет работать (для упрощения дальнейшей коммуникации)

Финальная встреча перед началом разработки, в ходе которой ответственный дизайнер представляет фичу, а команда задаёт вопросы. Обычно документ скидывается заранее, чтобы больше людей могли с ним ознакомиться и подумать над вопросами. На каждую большую фичу мы создаём канал в Slack (где-то на этапе первичного обсуждения), в который потом приходят люди по мере их вовлечения в разработку.

Всё. Дальше начинается DEVELOPMENT.

Архитектура задач

Когда дело доходит до непосредственно представления конкретных задач для разработчиков, мы решили руководствоваться немного видоизменённым подходом на основе User Story. Мне лично не очень нравится громоздкие формулировки (хотя они и позволяют разобраться в сути) типа «Я как игрок хочу что-то сделать, чтобы что-то получить».

«Получить» (как причина/мотивация) — это объяснено в описании фичи. «Игрок» у нас по умолчанию, так как задачи мы бьём по принципу взаимодействия — то есть функциональный элемент, с которым взаимодействует игрок. Или скорее тестируемая совокупность элементов для получения определённого игрового опыта. Тестируемая потому, что каждую такую задачу можно протестировать от начала до конца, будучи уверены, что все слои разработки были закрыты к моменту тестирования.

До этого часто случались ситуация, при которых клиентская часть уже готова, а серверная ещё нет и понять, когда оно будет готово, было проблематично. В результате чего тестирование делилось на несколько этапов с отдельной проверкой клиента, сервера, а потом ещё всё вместе. Теперь каждая часть фичи делается полностью всей командой и её проще тестировать как отдельный функциональный элемент. Наименее важные (nice-to-have) элементы выносятся в конец списка и, в крайнем случае, фича останется функциональной без них.

Для разбивки фичи на задачи мы решили использовать следующий формат (в скобках — вспомогательные элемент, который в название задачи не попадает):

(players should) be able to do something

(игрокам нужно) что-то мочь сделать

В качестве примера возьмём простую систему получения уровня в игре.

  • (игрокам нужно) Получать опыт за битвы
  • (игрокам нужно) Показывать окно получения нового уровня при его достижении
  • (игрокам нужно) Получать различные награды при получении нового уровня

Внутри каждого из этих пунктов будут конкретные задачи для конкретной области (Server, GUI, Balance, и так далее).

В первой задаче будут серверные задачи по хранению опыта и таблицы уровней, клиентские задачи на получение данных с сервера и отображению опыта в профиле и набора его после битвы. У художников будут задачи на ассеты, и так далее.

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

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

  1. читая документ, рисовать путь игрока от первой встречи до финальной точки;
  2. отметить самодостаточные шаги взаимодействия игрока с фичёй;
  3. трансформировать эти шаги в определённые задачи (User Story).

Если руководствоваться этим подходом, то мы получаем базовое наполнение в виде EPIC → USER STORY с шаблоном выше. Если читать наполнение эпика сверху вниз, то должна складываться полноценная картинка того, с чем сталкивается игрок в рамках этой фичи.

Дальше, разберёмся, как это разработчики и художники сами себе заводят задачи. В каждой User Story есть те или иные компоненты (Server, GUI, Balance, …), которые определяют кого и как затронет каждая User Story. Те, кто будут разрабатывать фичу, читают документацию и понимают, какие задачи им предстоит выполнить, чтобы эта User Story полноценно заработала. Таким образом и у каждого разработчика появляется хорошее понимание, что это за фича такая, а значит и воплотит он её точнее 🙂

На выходе мы имеем осознание, какой компонент уже завершён, а какой ещё в процессе — т.е. прозрачность разработки и возможность более чётко определить сроки и прогресс по той или иной задаче. И главное, что протестировать ту или иную часть фичи можно будет, как только все компоненты завершены (вся User Story автоматически отправляется в IN QA).

Единственный минус (из найденных пока) данной архитектуры — это заведение багов. Открывать их в конкретную User Story было бы логично, но мы не хотим, чтобы User Story переоткрывалась. User Story закрыта — функционал выполнен. Баги есть баги. Если же по какой-то причине функционал не был выполнен полностью, то да — это причина повторного открытия задачи. Баги мы заводим в теле Эпика (да, их становится много, но мы не обращаем внимания) и линкуем каждую к определённой User Story. Таким образом, если зайти в каждую User Story, то можно увидеть список багов и их статус.

Пока, тьфу-тьфу, работает.

Структура документа описания фичи

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

Feature Description Document — так вот называется у нас. Документ описания фичи.

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

Перед тем, как рассказать о самом документе, в качестве лирического отступления кратко расскажу о структуре всей документации:

  • Дизайн-документация
    • Версии в разработке
      • 2.0
        • Фича 1
        • Фича 2
      • 2.1
        • Фича 1
      • 2.2
        • Фича 1
    • Выпущенные версии
      • 1.8
        • Фича 1
      • 1.9
        • Фича 1
    • Концепты
      • Концепт 1
      • Концепт 2
    • Icebox
      • Концепт 3
      • Концепт 4

Такая структура позволяет быстро охватить развитие проекта (подходит, имхо, только проектам в оперировании), посмотреть какие фичи были добавлены в какую версию, какие идеи есть в работе и какие были отложены «на потом» (Icebox).

Теперь собственно документ каждой фичи.


Название фичи

Статус

  • Используется для быстрого понимания, в каком состоянии документ
    • WIP (в данный момент дизайнится)
    • DEV-READY (готово к разработке)
    • LIVE (фича в релизе)
      • NB! Если фичу надо улучшить после релиза, то для улучшения создаётся отдельная страница (Фича 2.0) с линком на оригинал и описываются нововведения и изменения

Ссылка

  • на задачу в таск-трекере

Оглавление

  • Ссылки на ключевые части документа

Краткое описание фичи

  • В одно предложение для того, чтобы сразу понять, что это за фича

Цель

  • Зачем делается фича с точки зрения разработчика и чем она будет полезна проекту

Мотивация

  • Почему в эту фичу будет играть игрок и чем она будет полезна ему

KPI

  • Список целевых метрик, на которые фича повлияет и ожидаемая степень воздействия (от 1 до 3)

Механики

  • Блок разбивается на несколько частей, в каждом из которых описывается определённая механика фичи подробно (с мокапами, ссылками на таблицы и референсами)

Примеры использования

  • Множество примеров сценариев взаимодействия и ожидаемое поведение игры (обязательно с пограничными случаями)

Контент

  • Список контента, который надо изменить/произвести (экраны, предметы, анимации, и т.д.)

Награды

  • Список наград, которые игрок может получить в результате взаимодействия с фичёй

Совместимость

  • Описание того, как фича взаимодействует с уже существующими фичами и как их изменить, чтобы они не сломались после релиза новой

Аналитика

  • Список событий, за которыми необходимо будет следить после релиза, или хотя бы список вопросов, которые можно задать аналитикам

Live Ops

  • Что нужно добавить в релиз-ноты и о чём надо оповестить игроков касаемо этой фичи
  • Что нужно сделать с аккаунтами текущих игроков, чтобы фича работала верно

Оценки сложности

  • Таблица с оценками от архитекторов, насколько фича комплексная

Планы на будущее

  • Список возможных идей по развития фичи в будущем, либо ссылки на концепты

Заключение

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

Хотелось бы, чтобы читатель сделал для себя какие-то полезные выводы или понял, чем он может улучшить свои текущие процессы для своей текущей команды.

P.S. кстати, мы ищем гейм-дизайнера уровня senior с релокейтом в Прагу, который будет помогать тащить наш живой мобильный пвп-экшн!

6 комментариев

    • Ilya Ostashko

      А почему убийство фичи на позднем этапе — это подводный камень? Это вполне себе реалия и я её учитываю в процессе. Если вы хотите убить фичу — делайте это до point of no return, иначе много работы будет сделано либо впустую (если фичу совсем убьют), либо тогда, когда её делать не нужно (если её потом перенесут на более позднюю версию). Переходить за черту point of no return нужно, когда вы точно уверены, что фича войдёт в следующую версию. Понятно, что бывают и форс-мажоры, но это скорее исключения.

      Пока единственный подводный камень (то, чего я тут написал, а оно не работает, как хочется), так это что некоторые программисты либо не всегда хотят создавать сами на себя саб-таски, либо делают это неполноценно. ПМ в данный момент работает над этим 🙂 Большинство программистов очень хорошо создаёт на себя саб-таски.

      Если ещё какие-то подводные камни будут обнаружены, я обязательно напишу про них в UPD.

  • Евгений Онянов

    Всегда интересно читать такие статьи, но всегда не хватает практического примера. Понятно, что NDA, но всё же хочется примеров 🙂

      • Евгений Онянов

        Просто не понятно, все фичи вы так расписываете или нет и что вообще к фичам относить. Вот например работаете вы над платформером. И в какой-то момент хотите добавить двойной прыжок или скольжение по стене вниз. Это фичи? Или базовые механики, которые должны были быть заложены с самого начала.

        • Ilya Ostashko

          К фичам относить функционал. Остальное — контент или удобности, для них шаблона нет, описывается как можется и как нужно в текущем проекте/команде.

          В целом, весь этот пайплайн подойдёт тем, у кого производство на потоке, как у нас — постоянные апдейты на живом проекте. Потому что все должны привыкнуть к какому-то одному виду доков и одному процессу, и уже варились в нём. Если это ещё не выпущенный проект или p2p, которому не требуются постоянные релизы ввиду того, что это не GaaS, то данный пайплайн использовать ни к чему — там другие задачи и сроки.

          Если же вы работаете, например, над f2p платформером и вдруг захотели добавить в core gameplay двойной прыжок или скольжение по стене вниз, то можно прогнать через этот же процесс. Описывайте в концепте, что добавление этой механики в core gameplay принесёт игре и проекту. Почему эта механика будет интересна игрокам и они будут её использовать? Как это повлияет на KPI? Много ли нужно переделывать для того, чтобы её добавить в игру? После первого этапа с продюсером можно уже предметно обсудить, нужно ли добавлять эти механики в игру вообще или нет. И дальше по процессу.

Добавить комментарий