Маргарита Шаповалова, младший гейм-дизайнер компании OctoBox Interactive, рассказывает, как в их студии изменился подход к разработке и процессам в команде.

 

 

 

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

Чиво?

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

Дано

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

В студии OctoBox Interactive есть мобильное и PC подразделения.

Я работаю в PC подразделении над тактическим мультиплеерным шутером от третьего лица про мехов — Blazing Core. Наша команда насчитывает порядка 30 человек.

Мы находимся на последнем этапе продакшена — 7 сентября вышли в открытую бету.

Предпродакшен игры занял ~год, продакшен ~2 года.

Планирование, процессы и документация

Потребность в том или ином типе документации зависит от проекта, договорённостей внутри команды и этапа разработки.

Обычно в разработке выделяют 3 крупных этапа:

  • препродакшен
  • продакшен
  • постпродакшен

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

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

Предпродакшен может включать в себя:

  • сбор требований и идей
  • определение MVP (minimum viable product)
  • формирование питча и концепт-документа
  • формирование технической документации и ТЗ
  • формирование визуальной составляющей: стилистика, уровень графики
  • прототипирование
  • целевая аудитория и анализ рынка
  • планирование этапов работ, сроков, ресурсов, стоимости
  • какая-нибудь бизнесовая штука (обмен документацией, подписание договоров с партнёрами)

Подробнее о том, как писать питч и концепт-документ и что в них может соджержаться, читайте здесь: Дизайн-документация. Часть I

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

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

Продакшен может включать в себя:

  • детальное планирование этапов работ (майлстоуны, итерации)
  • ГДД (описание фичей, балансные таблички)
  • постановка ТЗ
  • написание кода
  • разработка интерфейсов
  • создание игрового контента (персонажи, карты, пушки)
  • тестирование
  • поддержание документации в актуальном состоянии
  • подготовка маркетинговых материалов
  • работа с аудиторией

Постпродакшен — этап работы над игрой после релиза. На этом этапе осуществляется поддержка игры и её развитие.

Постпродакшен может включать в себя:

  • исправление ошибок
  • поддержка игроков
  • привлечение и удержание игроков
  • внедрение новых фичей (читай повторение предыдущего цикла)

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

А как у нас?

Было

На этапе предпродакшена и продакшена мы:

  • писали ГДД в Confluence, балансные таблички в Google Docs
  • разработка строилась на принципах Agile, системой организации служил Kanban
  • задачи ставили в Trello

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

Все документы разного объема и степени детализации.

За год предпродакшена и два продакшена наш Confluence разросся до 1964 статей (техническая документация, ГДД), игра же тем временем бурно развивается, некоторые вещи в процессе разработки меняются.

Как всю эту документацию поддерживать в актуальном состоянии?

Никак :3 На поддержание такого объема требуются немалые ресурсы, которых у нас нет. Поэтому мы кое-что решили.

Стало

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

Чуть позже, за месяц до ОБТ, на планёрке гейм-дизайнеров с продюсером решили внести некоторые изменения в полиси и делать следующее:

  • рабочие таблицы в Google Docs всегда поддерживаем в актуальном состоянии (тут ничего не изменилось)
  • общие описания новых фичей, их взаимосвязь по-прежнему оформлять в виде статей в Confluence
  • детализацию фичей сразу переносим в YouTrack в виде подробных ТЗ с метками и взаимозависимостями

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

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

Плюсы и минусы такого подхода

Плюсы:

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

Минусы:

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

В заключении

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

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

  1. Стремитесь к тому, чтобы документ легко читался человеком вне контекста.
  2. Критически относитесь к используемому словарю терминов. Словарь — главный инструмент коммуникации, он должен быть ёмким и доступным.
  3. Пишите на одной странице описание одной сущности, фичи или игровой механики. Это позволит легче потом ориентироваться в документации.
  4. Добавляйте необходимые ссылки на сопутствующие страницы других документов.
  5. Описывайте сущность и её особенности в том виде и объёме, которые необходимы для выполнения задачи другими сотрудниками.
  6. В финальной документации не оставляйте описание вариантов, которые не приняты в работу или не планируются к выполнению.
  7. Обсуждения на полях не являются документацией, поэтому решенные комментарии вносите в качестве правок в документ.
  8. Придерживайтесь одного стиля форматирования.

В первой статье тоже есть советы. Не буду их дублировать, они лежат здесь: Дизайн-документация. Часть I

Гейм-дизайнер — не только человек, который придумывает чем бы таким заняться игроку, чтобы тому было классно, но и человек, который придумывает чем бы таким заняться коллегам. И в его силах сделать так, чтобы коллегам тоже было классно.

Большое спасибо за ваше внимание! Делайте классно!