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

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

Документацию я условно разделю на две большие группы:

Оба типа имеют одну общую особенность. Это пошаговая инструкция о том КАК мы делаем тот или иной продукт. Эта инструкция является ДОГОВОРЕННОСТЬЮ внутри команды которая НЕ ПОЗВОЛЯЕТ творить кхм "творчество" так как является связующим звеном между продюсером, инвесторами и командой. Если документация пишется, вероятней всего у вас что то получится.

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

Для начала обозначим критерии качественного документа а потом будем углубляться в подробности.

С первым пунктом все понятно. Не нужно давать прям сверх подробную документацию со скришотами куда нужно нажимать кнопочки. Достаточно описательно обозначить флоу выполнения и только если требуются так скажем "кастомные" шаги описывать их детально. В остальном будьте любезны соблюдать MVC (Model-View-Controller) при разработке инструментов пайплайна. Чем МЕНЬШЕ "кастомных" шагов в вашем документе тем лучше. В противном случае если их не избежать - делайте инструмент. Не пытайтесь учить коллег смежным дисциплинам. Команды которые требуют с художников знать гит или не дай бог разбираться в устройстве стримов - обречены на страдание. Поэтому прежде чем делать "кастом" подумайте а лучше посмотрите на примеры решения схожих задач коллегами из других студий. GDC например.

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

Актуальность это ключ к успеху. Если ВСЯ команда будет в курсе того КАКИМИ способами мы делаем ту или иную фичу это благотворно будет влиять на настроения в коллективе так как избавит его от бесконечных переделок. Вам может показаться смешным, но в моем опыте есть пример где группа вроде бы токовых людей с богатым игровым опытом раз за разом переделывали плевую фитчу для ААА проекта в течении года, а когда проект пошел на поддержку эта фитча начала переживать вторую волну переделок и до сих пор не финализирована и вызывает ряд проблем, и судя о том что ребят ничего не смущает "рефакторинг" будет происходить еще очень долго. 

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

Перед командой встала задача, которая маячила с первого дня разработки, но теперь стала очевидной для всех. Необходимо расставить определенные изображения на билбордах по всем игровым картам, а так же по поверхностям определенного типа таких как асфальт, трава, бетонные блоки. Задача понятная. Опустим момент того что лиды по направлению проебали "красный флаг" и на опыте не подняли вопрос необходимости решения этой задачи в приоритете до момента ее возникновения, нас это не интересует мы окунемся в документацию.
Что написано в документации? Начнем с ГДД. Документа нет. Спускаемся ниже - в тех. ГД. Тут тоже ничего нет, так как и ГДД нет. Спускаемся в техарт? Ничего. Мб в Левел дизайне будет что то? Бинго! Так как задача уже исполнена силами Левел дизайна было найдено "кастомное" решение и оно ОЧЕНЬ подробно расписано и соответствует критериям качества. Респект!

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

Не проебали бы ГД этот момент, тогда бы эта задача была решена не гигантским "кастомом", а процедурно с таким запасом прочности что больше не пришлось переделывать, а так получается из за того что этот "кастом" находится в формата "сам в себе" любое изменение потребует ручного контроля и проработки. Простыми словами - поддержка решения, учитывая специфику проекта, становится бесконечной и ребятки вместо сосредоточения на улучшении проекта погрязнут в бесконечном ручном труде. Как по мне это отличный пример ВАЖНОСТИ документации. При ее отсутствии вы обязательно родите дыру в бюджете.

Как это ДОЛЖНО БЫЛО БЫТЬ СДЕЛАНО:
- ГД описывает сущности

- ГД описывает кастомизацию

- тех ГД пообщавшись с разработчиками описывает как эта система уживется в Архитектуре проекта и делает ее описание

- На основание этого Техарт предлагает процедурное решение так как внезапно есть такой человек

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

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

- НАЗВАНИЕ ПРОЕКТА

  - Словарь Терминов

  - Геим Дизайн
  - Сущность 1 (Например Оружие)

  - Сущность 2 (Например Персонажи)

  - Сущность 3 (Например Свет)

  - Сущность 4 (Например Окружение)

  - Сущность 5 (Например Карты)

  - Сущность 6 (Например UI)

  - Сущность 7 (Например Звук)

  - Информация по движку специфичная для проекта
  - Информация специфичная для платформ релиза
  - Техарт

  - Левел дизайн

  - R&D

  - Организационная ветка

Допустим у нас есть проект - Шутер в котором мы играем в виртуальный страйкбол. Предполагается наличие мультиплеера, поэтому будет реклама спонсоров прям внутри игры. От ивента к ивенту реклама будет меняться.

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

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

В игре предполагается наличие:

- Блоков

   - тип А

   - тип Б

   - тип В...

- Заборов

   - тип А

   - тип Б
   - тип В...

- Вышек

   - тип А

   - тип Б

   - тип В...

- Асфальта

  - тип А...

- Билбордов

   - тип А... и.т.д

На объектах класса:

- Билборд

- Забр

- Вышка

- Асфальт

Должна располагаться спонсорская реклама при игре в онлайне. Рекламные банеры представляют спонсоры. В соответствии с договоренностью с рекламодателями в игре банеры будут следующего вида:
- Прямоугольные

- Круглые

- Ромбовидные

- Квадратные

- Элипсовидные

...итд

Документ описывающий критерии разработки банеров (Ссылка)

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

Внешний вид и дополнительные вариации определяются арт отделом (ссылка на документ в разделе Сущность 4 (Например Окружение))

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

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

Финальным продуктом будет объект с возможностью замены рекламы на нем в заранее отведенной для этого месте.

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

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

Бонусом уже на этом этапе можно завозить каталогизацию :)