Геймдизайн документация для опытных

Документация, что это? Зачем это? Как это? Такие вопросы возникают у многих разработчиков когда они сталкиваются с необходимостью написания документации. И самое интересное, что документация как раз таки и должна отвечать на эти 3 главных вопроса. Но об этом чуточку попозже, для начала давайте узнаем суть документации

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

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

Также и с играми или любыми другими проектами — документация нужна чтобы в удобной форме объяснить разработчику как ему нужно реализовать определенную часть продукта

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

Исходя из такого ассоциативного интро можно уже сделать несколько выводов о смысле документации

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

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

И так, как начать?

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

Достаточно внимательные читатели обратили внимание, что про эти 3 вопроса я упоминал в самом первом предложении своего интро.

Так вот эти 3 вопроса “что? , зачем? , как? ” магическим образом структурируют в вашей голове самое важное понимание — понимание цели и сути документации.

Именно это основа для любой хорошей документации

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

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

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

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

Описание

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

Описание должно быть максимально кратким и максимально информативным. Его задача чтобы разработчик понимал, что это вообще за фича и зачем она нам нужна в проекте.

Описание можно воспринимать как небольшой интро перед основной частью документации

US — юзер стори

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

Пишите юзер стори в формате:

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

Писать юзер стори можно от лица геймдизайнера, разработчика, игрока главное обозначит «что он хочет” и »для чего он это хочет”

Вот еще пример юзер стори

Я как игрок [хочу интересную игру] для того, чтобы [проводить в ней много времени по вечерам]

Исходя из этого мы сразу пониманием для кого нам эта игра нужна и как он будет ее использовать

Для кого — для игрока, значит мы делаем игру для игроков

Что он хочет — интересную игру

Для чего он это хочет — для того, чтобы проводить в ней много времени

Оперируя этой информацией мы уже четко понимаем что нам нужно будет сделать и мы уже можем выдвинуть гипотезы как нам это сделать

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

Раздел логики

Основной раздел сборки вашего шкафа вашей игры.

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

Но есть чеклист, которого я стараюсь придерживаться:

Флоу

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

Три важных правила флоу:

Пример флоу:

В данном примере мы видим

ЭДЖ кейсы

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

Можно выделить две основные причины описания ЭДЖ кейсов:

Тут оформление ЭДЖ кейсов на усмотрение каждого гейм-дизайнера, но очень важный момент, каждый ЭДЖ кейс должен иметь ответ, как фича должна реагировать на данный кейс

Пример ЭДЖ кейсов:

Вот еще один пример ЭДЖ кейса

Первый пример описывает особый кейс, который не покрывался логикой работы фичи.

А второй пример описывает кейс неправильной логики работы фичи

Как мы выяснили документация это важный элемент в разработке, который служит инструкцией в сборке игры.

Во время написания документации сам гейм дизайнер должен понимать, что он описывает задавая себе три вопроса "что? ” “зачем? ” "как? ”.

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

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

Читателям отличных документации, а у меня на этом все. Спасибо за прочтение, надеюсь оно принесло вам пользу. Обязательно оставляйте ваше мнение в комментариях