Статьи

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

/

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

Этот документ мы так же написали у себя в студии Clockwork Drakkar. Автор, Head of Narrative (в прошлом гейм-дизайнер с внушительным опытом) — Антон Елхов.

Приятного чтения!

  • Аннотация
  • Виды дизайн-документации
  • Неклассифицируемая документация
  • Главные качества дизайн-документации
  • Базовые принципы ведения документации
  • Статусы документов
  • Структура документации
  • Хранение версий

Аннотация

Настоящий документ охватывает базовые принципы написания, нейминга, хранения и контроля версий гейм-дизайн документации.

Виды дизайн-документации

  • GDD — гейм-дизайн документация, которая включает в себя описания логики и принципов работы фичей. Частными случаями GDD являются концепт-дизайн документация и расчетные листы с балансом.
  • CDD — контент-дизайн документация, которая включает в себя описание визуального стиля для механик и ассетов, референсы, мудборды, аудио-визуальные примеры того, каким по итогу должен быть ассет или общая картина
  • UI/UX — документация, посвященная пользовательскому опыту взаимодействия с фичей или приложением, обычно выполняемая в Miro (для user journey) или Figma (для непосредственных ассетов или мокапов интерфейса)
  • Tutorial — документация, посвященная методам объяснения игроку принципов и особенностей использования приложения или механики.
  • NDD — нарративная документация, она содержит в себе информацию по сюжетной части проекта, а именно описывает сеттинг и лор мира, его персонажей, предметы, правила и ситуации. Также к этому разделу относится любая повествовательная система проекта, к примеру кат-сцены, квестовая и диалоговая система
  • CAD — концепт-арт документация — документация, которая обычно является частью CDD, но в отдельных случаях представляет собой обособленный документ с требованиями со стороны ГД на концептирование ассетов.

Неклассифицируемая документация

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

  • Report |
  • Presentation |
  • Pitch |
  • Test |
  • Historical |

Пример:

[Gardariki] Historical | Боги древних славян (v1.0, ready)

* Подробнее о нейминге и статусах смотри ниже

Главные качества дизайн-документации

  • Понятность — язык документации должен быть прост, неспециализиорван, а используемые термины объяснены читателю в самом начале.
  • Однозначность — множественность трактовок тезисов должна быть сведена к минимуму
  • Полнота — целью документации является устранение нехватки информации для исполнителя или иного конечного пользователя. Документация должна максимально отвечать своей цели.
  • Конкретность — требуется максимальная четкость в изложении мыслей, никакой воды, юмора и сторонних рассуждений.
  • Актуальность — ГД должен следить за устареванием тезисов, идей, концепций и расчетов и своевременно устранять эту проблему.
  • Логичность — структура и содержание документа должны быть четко организованы и последовательно изложены.
  • Консистентность (непротиворечивость) — документация или ее части не должны противоречить друг другу, прочим документам системы или базовым установкам игры (например, лору)

Базовые принципы ведения документации

  1. Иерархическая структура: Документация должна вестись в системе, которая позволяет задать четкую иерархическую структуру документов — Confluence, Wiki.JS, Notion и пр.
  2. Облачное хранилище: Требуется единое структурированное облачное хранилище для медиа и документов.
  3. Единое хранилище: Недопустимо хранение проектной документации на личных аккаунтах пользователей.
  4. Версионность: Документация должна иметь версионность (v1.0, v1.1, v2.0) и возможность отката до необходимой версии.
  5. История изменений: Каждый документ должен иметь историю изменений для быстрого поиска информации по версиям.
  6. Архивация старых документов: Старая, неактуальная и обесценившаяся документация должна не удаляться, а переходить в архив.
  7. Ссылки на более мелкие документы: Крупные документы должны содержать ссылки на более мелкие документы и частные случаи. Недопустимо создавать многостраничные “простыни” — с ними невозможно работать, равно как и следить за их актуальностью.
  8. Аннотация: Каждый документ должен иметь раздел Аннотация (Summary) — краткое содержание того, о чем в документе идет речь, иначе на поиск нужного документа тратится много времени.
  9. Используемая терминология и сокращения: Каждый документ должен иметь раздел с используемой терминологией и сокращениями. Не все знают, что такое soft-target, sagger, FTUE, FOV, ARPPU и пр.
  10. Введение термина: Сначала введение термина, затем использование этого термина — обязательно.
  11. Связанная документация: Каждый документ должен иметь раздел “Связанная документация” — для удобства быстрой навигации и поиска информации.
  12. Унификация структуры: Структура документации должна быть унифицирована в рамках компании, на крайний случай — в рамках отдела для удобства читающего. Все документы должны создаваться по соответствующим шаблонам с минимально необходимыми изменениями шаблонов, если таковые понадобятся.
  13. Интеграция мелких документов: Для мелких документов можно опустить создание отдельных CDD, NDD, GDD, UX/UI, помещая релевантную информацию в соответствующие разделы единого документа на дизайн фичи или ассета.
  14. Нейминг и статус готовности: Необходимо соблюдать правила унифицированного нейминга (названия файлов), а именно
    1. [Проект] Тип документа | Название (версия, статус)
    2. Пример: [Gardariki] CDD | Оружие ближнего боя (v1.2, ready)

Статусы документов

  • draft — рабочий документ гейм-дизайнера, который видит только гейм-дизайнер, лид и проджект-менеджер. Только при крайней необходимости дается доступ другим людям. 
  • ready — готов для утверждения
  • final — утвержден. Если внесены правки, возвращается статус ready. 
  • released — все описанные в документе фичи находятся в билде. 
  • old  — старые архивные документы, не реализованные ни в одном из релизов. Статус получают только старые документы, которые нельзя отнести к описанным выше категориям, в дальнейшем его нужно избегать. 

Структура документации

  1. Документация
    1. Техническая — техническая докуметация со структурой по усмотрению лида
    2. Арт — арт докуметация со структурой по усмотрению лида
    3. Гейм-дизайн
      1. Общая информация — о проекте
        1. Описание проекта
        2. White Paper — публичный “обзорный” гдд
        3. Общий GDD — полноценный гдд, где преимущественно используются ссылки на механики и системы
        4. Story Bible — нарративный справочник, энциклопедия по игре
      2. Нарратив
        1. Сценарий
          1. Синопсис
          2. Поэпизодник
        2. Главы
          1. Олаф-предатель — главу надо рассматривать как локальный гдд, если используются механики и пр., то это дается ссылками
            1. GDD
            2. NDD
            3. CDD
          2. Ведьма и Жрец
          3. Сожжение Ладоги
        3. Персонажи
          1. Игровые
          2. Неигровые
        4. Хтонь (монстры)
      3. Игровые механики — максимально абстрагированные от нарратива механики в чистом виде. Чтобы при необходимости можно было бы из них собрать хоть новую главу, хоть демо-версию на конференцию.
        1. Бой
          1. GDD — логика, описание и расчеты
          2. CDD — как выглядит и звучит
          3. Tutorials — как обучаем игрока
          4. UI/UX — как игрок этим управляет
        2. Переключение между персонажами
        3. Инвентарь
        4. Способности
        5. Пути богов
        6. …
      4. Системы, контролеры, сопутствующие механики
        1. Камера
        2. Персонаж
        3. Таргетинг
        4. Перемещение
        5. …
      5. Игровые сущности
        1. Игровые предметы
          1. Оружие ближнего боя
            1. GDD
            2. NDD
            3. CDD
          2. Оружие дальнего боя
          3. Оружие магическое
          4. Снаряжение
          5. Расходуемые предметы
          6. Ресурсы
        2. Строительство
          1. Экономические постройки
          2. Ресурсные постройки
          3. Декоративные постройки
      6. Мультиплеер
      7. Концепты
      8. Питчи и презентации
      9. Монетизация
      10. Аналитика
      11. Обновления
      12. Архив
    4. Менеджерская —  ПМ докуметация со структурой по усмотрению лида
    5. Клиентская — создадим раздел, если потребуется 
    6. Библиотека
      1. Источники
      2. Историография
      3. Базы данных
      4. Ссылки

Хранение версий

Общие принципы версионности

Версионность поддерживается в друх направлениях:

  1. Внутри каждого документа посредством таблицы с историей изменений
Название апдейта и ссылкаСписок правокДата измененияАвторы
GDD Template v1.0Первая версия документа12.07.2024Антон Елхов
  1. А также внутри самой системы документации. Документация final и released отправляется в вики, остальная — в архив:

Пример

  • Зельеварение
  • [Gardariki] GDD | Зельеварение (v2.0, draft) — пересмотр механики, в процессе написания
    • [Gardariki] GDD | Зельеварение (v1.3, final) — заапрувлено, в вики 
    • [Gardariki] GDD | Зельеварение (v1.2, released)  — в билде, в вики
    • [Gardariki] GDD | Зельеварение (v1.1, final) — в архив
    • [Gardariki] GDD | Зельеварение (v1.0, final) — в архив
  • [Gardariki] Tutorial | Зельеварение (v1.1, ready) — написан, но не заапрувлен
    • [Gardariki] Tutorial | Зельеварение (v1.0, final) — заапрувлено, в вики

Порядок работы с версиями

В простом варианте пайплайн выглядит так:
1. Делаем копию с документа, например, версии v1.0, final

2. Отправляем в архив внутри папки отдела, например, GD

3. Переименовываем копию документа в версию, например, v1.1, draft

4. Дорабатываем документ, озаглавленный v1.1, draft

5. Пишем в истории изменений историю изменений.

пока нет нового документа в статусе final, в архив не отправляем

Критерии обновления версий

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

Минорные правки (Версия не меняется)

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

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

Новый документ при минорных правках не создается

Средние правки (Увеличение дробной части версии)

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

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

Глобальные правки (Увеличение целой части версии)

Глобальные правки значительно изменяют документ и, вероятно, игру. Эти изменения требуют существенного пересмотра других частей документа и могут включать полностью новые элементы или переделку существующих. Примеры глобальных правок:

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

Примеры версий

  • v1.0: Первая версия документа, включающая основные элементы и концепции игры.
  • v1.1: Добавлены новые персонажи и их способности, внесены изменения в баланс игровых механик.
  • v1.2: Обновлены правила и описания уровней, добавлены новые элементы окружения.
  • v2.0: Полная переработка системы боя, изменена структура уровней, внедрены новые основные механики.

Вам также может понравиться

Чего надобно, старче? Офферы в F2P!

13.09.2016

Деконструкция: DAYS GONE. ЧАСТЬ 2/3

28.04.2020

Нарративный дизайн Dark Souls

24.11.2016

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