
Дизайн-документация. Часть II: ГДД не нужны?
Маргарита Шаповалова, младший гейм-дизайнер компании 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 в виде подробных ТЗ с метками и взаимозависимостями
Выделила жирным, чтобы было понятно, в чем самое главное отличие по сравнению с предыдущим этапом: в документацию добавляется информация необходимая и достаточная для обсуждения и закрепления результатов обсуждений, а все детали сразу оформляются как задачи и добавляются в определенный мейлстоун в соответствие с планом. Далее продюсер приоритизирует задачи.
Если задача большая, то создается основная карточка, в ней кратко пишем об основных целях, прикрепляем ссылки на относящиеся к задаче документы, далее создаём подзадачи. Дробим на подзадачи до тех пор, пока есть смысл.
Плюсы и минусы такого подхода
Плюсы:
- экономия времени: документы мы почти совсем не пишем, так как запаслись ими на предыдущем этапе.
- работа строится быстрее и качественнее: гейм-дизайнер так же становится исполнителем и работает совместно над задачей с программистами, моделлерами и проч.
- документация остаётся свежей гораздо дольше: крупные решения всегда более стабильны
Минусы:
- повышается порог вхождения в проект. Новому человеку придётся о деталях проекта узнавать, играя в сам проект на уровне игрока; читая блюпринты, код или задавать вопросы коллегам. Это, кстати, полезные навыки, особенно для гейм-дизайнера.
- если вдруг понадобиться передавать документацию кому-либо, а она без подробностей. Такое может потребоваться в случае продажи проекта. Придется писать кучу сопроводительной документации.
В заключении
Геймдев — комплексная сфера, поэтому документоведение и документопередача интересные и сложные темы. Еще раз хочу повторить мысль о том, что работа над документами и с документами зависит от того, какой у вас проект, как строятся ваши процессы и как вы договорились с командой.
Доложу еще в эту статью некоторую информацию, которая, надеюсь, сделает вашу работу над документацией чуть проще, понятнее и приятнее.
- Стремитесь к тому, чтобы документ легко читался человеком вне контекста.
- Критически относитесь к используемому словарю терминов. Словарь — главный инструмент коммуникации, он должен быть ёмким и доступным.
- Пишите на одной странице описание одной сущности, фичи или игровой механики. Это позволит легче потом ориентироваться в документации.
- Добавляйте необходимые ссылки на сопутствующие страницы других документов.
- Описывайте сущность и её особенности в том виде и объёме, которые необходимы для выполнения задачи другими сотрудниками.
- В финальной документации не оставляйте описание вариантов, которые не приняты в работу или не планируются к выполнению.
- Обсуждения на полях не являются документацией, поэтому решенные комментарии вносите в качестве правок в документ.
- Придерживайтесь одного стиля форматирования.
В первой статье тоже есть советы. Не буду их дублировать, они лежат здесь: Дизайн-документация. Часть I
Гейм-дизайнер — не только человек, который придумывает чем бы таким заняться игроку, чтобы тому было классно, но и человек, который придумывает чем бы таким заняться коллегам. И в его силах сделать так, чтобы коллегам тоже было классно.
Большое спасибо за ваше внимание! Делайте классно!


2 комментария
Дмитрий Медянцев
Кликбэйт!
«мы перестали писать гейм-дизайнерскую документацию» — и следом дается пояснение, что документация все еще ведется, и в конфле в том числе.
А по сути — документация задачами имеет огромный минус — трудно узнать актуальное состояние. Вот есть таска на «реализовать фичу», и есть 50 тасок на правки в эту фичу. И сортировка по времени создания/решения не поможет, и все равно придется всю эту информацию куда-то вмерживать (ну или надеяться, что проблем не возникнет — а они возникнут, муа-ха-ха).
Мне в этом плане как раз больше нравилась связка джира+конфлюэнс, когда «берем абзац в ГДД и делаем из него таску», и если дока изменится — это автоматом отразится в таске, плюс будет видно, изменения произошли ДО реализации, или ПОСЛЕ.
А еще есть риски взаимодействия, когда несколько ГД + несколько исполнителей параллельно работают над смежными частями игры, и могут косвенно зацепить друг друга, и могут быть конфликтующие куски документации. И если документация не централизована — то отслеживать такие моменты неудобно.
MioLinch
Спасибо большое за то, что поделились своим опытом.
Повторюсь, что всё очень индивидуально. Я лишь рассказала о том, как сейчас это делаем мы и почему это удобно. Как будет развиваться и с чем столкнемся, увидим.
Это рассказ о том, что не нужно зацикливаться на чем-то одном, нужно пересиапересма инструменты и не молиться на документацию :3