- Почему нужно документировать?
- Что и как документировать?
- С чего начать документацию?
Почему нужно документировать?
Никто не любит делать документацию (кроме тех, кто любит). Скорее всего, причина в том, что жопоболь от документирования получаешь сразу, а полезный эффект сильно отложен во времени. Иногда вообще до следующего проекта, когда получается использовать наработки прошлой игры и плакать от счастья, что “ты из прошлого” потратил на это время. Иными словами, чем дольше и профессиональнее вы занимаетесь одним видом деятельности, тем больше пользы вы получаете от документации.
Кроме того, чем больше ваша команда, тем важнее документирование проекта. Вот лишь несколько кейсов:
- вас распирало от отличного креатива, но уже через неделю от него остались лишь воспоминания уровня “было классно” и никакой конкретики, придется снова потратить много времени на работу с идеями;
- вас было в команде трое, а потом один из вас “не смог” и вышел из проекта, а с ним ушла и его голова, в которой хранилась вся наработанная и нигде не записанная информация, все разработки придется начинать с начала;
- вас сначала было 3, а потом стало 33. И как-то надо всем этим людям быстро вложить в голову одну и ту же информацию, потому что иначе они не могут ничего делать по проекту.
Это неполный список проблем, с которыми могут столкнуться мастера ролевой игры. Но всех их вам будет крайне приятно избежать или хотя бы знать способы минимизировать ущерб от них вашему проекту.
Никто еще не умер от того, что не документировал своей проект. Но многие стали счастливее от того, что все же отважились этим заняться. Далее будет описана ситуация с документированием, близкая к идеальной, но редко встречающаяся в реальности. Что не отменяет того, что к идеалу стоит стремиться.
Что и как нужно документировать?
Документировать нужно все. Всякий раз, когда вы можете сделать документ и разослать его другим, делайте это.
Во-первых, литературная письменная речь отличается от разговорной (устной или письменной) тем, что она более структурирована и формализована. На письме можно позволить себе быть более аккуратными и последовательными, более подробными и наглядными, чем в разговоре. Хотя бы потому что у автора письменного текста больше времени на его подготовку и обдумывание, чем непосредственно при рассказе. И потому что у читателя письменного текста есть возможность возвращаться и перечитывать сложные или непонятные фрагменты столько раз, сколько нужно. А еще по текстам работает поиск по ключевым словам.
Во-вторых, это экономит всем время. Читаем мы быстрее, чем разговариваем. К тому же не всегда получается собрать всех нужных людей в одно время (не все смогли или кто-то присоединился к проекту позже остальных). Текст - универсальный способ донести информацию до всех даже с временным лагом.
В-третьих, у вас потом останется самый настоящий текст. И все (в том числе автор документа) смогут его перечитать через месяц, через два или через год. Человеческая память устроена очень интересным образом, мы постоянно что-то забываем. Текст не забывает ничего.
И уж самое последнее, устное объяснение и текстовое объяснение - это к-к-комбо, которое работает лучше, чем эти объяснения по отдельности.
Дизайн-документ - подробное и конкретное описание того, как все должно быть устроено в ролевой игре. Составляется мастерами разных блоков в соавторстве, как минимум модельщиками, как максимум всеми. Может дописываться и изменяться по ходу разработки игры. На основе него будут составлены конкретные техзадания (или диз-док даже может их заменить). Должен включать в себя: референсы, перечень сюжетов среднего уровня, перечень персонажей (PC и NPC), цели и препятствия в сюжетах среднего уровня и у персонажей, игровые модели и механики, перечень правил, перечень игровых объектов, перечень локаций, перечень игровых документов (тексты, аудио, видео, фото и прочее).
Если говорить более конкретно, вот примерный список позиций, которые нужно отразить в дизайн-документе мастерам ролевой игры:
- Лор (сеттинг, world building) - общее описание мира игры, игровой вселенной и ее базовых законов.
- Геймплей - “глаголы”, чем игроки будут заниматься на игре.
- Движок - то, что порождает “процедурный нарратив”; его может не быть на ролевой игре, или он может быть модельным. Механики на игре, порождающие основной замес и вносящая элемент случайности в ролевую игру.
- Аудитория - кто будет играть в вашу игру.
- Жанр - важно понять, что жанры ролевых игр и кино могут не совпадать, так же как жанры видеоигр и литературы не всегда совпадают. Это должно быть короткое, понятное вашей аудитории определение характера игры. Если ваша аудитория не смотрит аниме и не понимает, что такое “гаремник”, то не пишите, что ваша игра “Стремный детектив” в жанре “гаремник”.
- Формат - сколько игроков, на каком полигоне, какова продолжительность игры.
- План разработки игры - ключевые этапы, их порядок, ответственные за этапы и сроки их реализации. Тут для наглядности хорошо подойдет диаграмма Ганта. Очень важно понимать, что план составляется не для того, чтобы быть полностью реализованным, а для того, чтобы команда могла оценить и распределить свои ресурсы. План можно и нужно изменять, как только появляется в этом необходимость. Для проекта хорошо использовать три уровня планирования: долгосрочное для проекта в целом от начала и до конца (максимально общее, без деталей), среднесрочное на 3 месяца (по сути пересмотр долгосрочного плана ближе к делу, позволяет видеть перспективу краткосрочных задач) и краткосрочное для задач команды на ближайший месяц (максимально подробное). Планы фиксирует и отслеживает главный мастер, а составляют их ответственные мастера своих блоков.
- Описание команды - нужно где-то записать, кто и чем занимается, а также указать способы связи с ними. Это может быть очень короткий и простой документ. Он полезен для координации внутри команды, когда у кого-то возникает вопрос по определенному блоку, он может быстро посмотреть, кому ему их задавать. Также документ пригодится в конце проекта, когда нужно будет припомнить и отметить вклад каждого члена команды. Берете нового человека в команду - начните с того, что добавите его описание в этот документ и поделитесь всеми описанными тут документами.
- Бюджет и сметы должны быть составлены до того, как будет потрачен первый рубль. Бюджет - общий финансовый документ игры, который динамично меняется и непрерывно обновляется, здесь учитываются приход (взносы от игроков и прочее), расход (возмещения команде, закупки, оплата услуг) и считаются остатки (доступные средства, будущие взносы). Сметы - это документы под конкретные техзадания, зачастую составлены теми, кто их реализует. Бюджет лучше делать закрытым для всех, кроме блока организации (АХЧ). Сметы лучше делать закрытыми для всех, кроме блока организации (АХЧ) и тех, кто по этой смете работает. Эти нехитрые предосторожности сберегут нервы всем в команде: и мастера будут меньше нервничать от вида непонятных им цифр и ценообразования, и блок организации не будет бесконечно оправдываться за то, как и почему он делает свою работу.
- Техзадания составляются для каждого блока, они составляются ответственными мастерами по своим блокам вместе с теми, кому задача была поручена. Не стоит просто что-то требовать от людей, стоит обсуждать с ними, что они обещают сделать. По сути это чеклисты с требованиями, которые должен выполнить тот мастер, которому задача, описанная в техзадании, была поручена. Нужны, чтобы команда не запуталась и всегда могла понять, выполнена какая-то задача полностью или ее еще надо доделывать. Техзадания связаны с этапами в плане разработки игры.
- Техдокументы - это все то, что требуется детализировать для игры. Сюда входят таймлайн игры (что и в каком порядке должно случиться на игре), квенты персонажей, открытые и закрытые правила игры, игровые документы. А также описание работы ИТ-системы, если вы ее создавали, схемы доезда на мероприятие, инструкции по оплате участия, форма заявки на мероприятие, инструктажи для игротехников, описание порядка регистрации игроков на мероприятии, списки раздатки (раздаточных материалов), краткие инструкции по работе моделей для размещения внутри игры и любые другие описания и инструкции, которые могут потребоваться до игры или на игре.
Все эти документы должны быть недоступны игрокам. Если и когда на полигоне что-то пойдет не так, как планировалось, это не всегда портит ролевую игру. Очень важно понимать, что все эти документы описывают игру для мастеров и до момента ее начала. С того момента, как в игру войдут игроки, они встанут у руля и будут иметь полное право интерпретировать игровые события не так, как это планировали мастера. И это не плохо. Это специфика ролевого игроделания.
Игроки обычно стараются разгадать мастерский замысел. Радуются, если им это удается. И расстраиваются, если нет. Мастерская группа не обязана только радовать игроков, но должна бы не расстраивать. Выложенные после игры все-все документы обязательно вскроют нестыковки и недоработки у мастерской группы, а также “неверные” интерпретации игроков. Лучше от этого воздержаться, так у игроков будет больше оснований ощущать себя соавторами игры, а, следовательно, у них будет больше положительных эмоций от игры.
С чего начать документацию?
Начать документацию стоит с выбора единого рабочего пространства для всей команды, никаких исключений. Люди могут работать, как и где им удобно, но сразу настройте себя и их, что в таком случае придется делать двойную работу: и в удобном кому-то виде, и по шаблонам для мастерской группы.
Выбрать платформу для документации нужно до начала проекта. Хорошо подойдут любые облачные сервисы, то есть такие платформы, с которыми можно работать онлайн и группой участников, а также куда можно загружать файлы разных форматов.
Очень удобен GoogleDrive или OneDrive, потому что у них есть свои текстовые редакторы, редакторы таблиц, редакторы блок-схем, опросные формы и другое. Они доступны онлайн, работают офлайн, выгружаются в форматах десктопного ПО, они бесплатны, общеизвестны и делают автосейвы и бекапы всех изменений в документах. Также у них есть интеграция с таск-менеджерами и многими другими сервисами.
Стоит сразу научить всю команду определенным образом называть и структурировать файлы проекта. И какое-то время следить за тем, что они все делают корректно. Ни в коем случае нельзя оставлять файлы без понятного названия или устраивать свальный грех из файлов.
Хороший вариант сразу создать в корневой папке проекта подпапки и файлы для каждого блока подготовки ролевой игры. Внутри такой подпапки стоит ввести правило, что в корне лежат только общие для проекта файлы, файлы по направлениям или файлы мастеров стоит складывать в папки следующего уровня. Пример такой структуры можно увидеть ниже.
Правилом хорошего тона будет оговоренный (или настроенный) запрет на редактирование файлов, в которые вас прямо не приглашали. Персональные папки - это рабочие пространства отдельных мастеров, там изменения можно только предлагать в формате советов или комментариев. Последние 2 опции ни в коем случае нельзя блокировать, это замедлит групповую работу с файлами.
Для всех документов по умолчанию стоит выставить права на доступ только по приглашению. Также можно использовать опцию - запретить приглашать новых пользователей или скачивать файлы всем, кроме их владельцев. Такие опции не стоит вводить тайно, о них стоит прямо предупредить команду и пояснить, почему принято такое решение.
В названии папок хорошо использовать нумерацию, это позволит их упорядочить не по алфавиту, а по смыслу. В названии файлов, которые по смыслу должны быть закреплены сверху можно добавить символ или цифру перед названием. В названии файлов или папок, которые должны быть снизу можно добавить перед названием последнюю букву русского или английского алфавита (zсвалка). Если есть файлы с ключевыми словами, отражающими смысл, и, как следствие, с одинаковыми названиями (например, “мастерка” или “новость”) стоит добавлять к ним дату и\или давать после символа “” поясняющий комментарий. В таком случае все однотипные файлы будут визуально упорядочены вместе. А за счет даты или комментария они будут отличаться друг от друга.
Указывая дату, лучше использовать формат ГГГГ-ММ-ДД или ГГ-ММ-ДД. Указывать год стоит потому, что проект может начаться в одном году, а быть закончен в другом. Лучше указывать год в 4х-значном формате, потому что тогда визуально даже не привыкшим к такому виду названия документов людям будет ясно, что это дата, а не какой-то цифровой неведомый шифр. Указывая сначала год, потом месяц, потом дату, вы сразу сортируете файлы в хронологическом порядке. Указав сначала дату, а потом все остальное, все первые числа каждого месяца будут у вас идти перед всеми вторыми числами каждого месяца, что неудобно.
Соблюдение этих рекомендаций сделает работу над игрой более структурированной и оптимальной. Но это довольно неочевидная вещь, пока не попробуешь. Ваша команда, если она состоит из новичков, может быть против. Обязательно потратьте время, чтобы всех убедить попробовать и втянуться. Чаще всего люди возражают против документации, потому что им не хватает опыта и они не понимают, как это делать. Объяснять надо столько раз, сколько требуется, чтобы мастер понял, как, что и зачем надо делать. Важно, чтобы объясняющий говорил на одном языке с тем, кому объясняет. Хорошим шагом будет объяснять по цепочке: кто-то не знал, но разобрался первым, его можно привлечь к объяснению тем, кто застрял на каком-то моменте. Если кто-то не понимает и после тысячи объяснений… это либо саботаж, либо глупость. Ни то, ни другое не сделает проект сильнее.
Контент распространяется по лицензии Creative Commons (CC BY-SA). Как указывать авторов: Больше не мастерю и другое вранье, 2022. Екатерина (КошкинС) Кулдина, Максим (Margulix) Панкратов, Юрий (Yarrow) Вишняков. vk.com/bnmidv
