Дизайн-документация. Часть 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 в виде подробных ТЗ с метками и взаимозависимостями

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

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

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

Плюсы:

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

Минусы:

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

В заключении

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

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

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

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

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

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