Дизайн документа как составить

Как написать хороший технический дизайн документ и не провалить проект

Введение

Любой успешный проект начинается с ясного и понятного плана, который определяет направление работы и описывает подход к его реализации. Проработка проекта на ранних этапах с достаточным уровнем детализации экономит время во время разработки и позволяет успешно завершить проект в предсказанные сроки и бюджет. Именно для этой цели и созданы технические дизайн документы («design doc» или «дизайн док»). Дизайн документы помогают разработчикам понимать основные требования к проекту, его архитектуру и функциональные возможности, а также процессы обеспечения безопасности и отказоустойчивости, масштабирования и эксплуатации.

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

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

Зачем нужны дизайн документы?

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

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

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

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

Улучшение качества. Одна голова хорошо, а две лучше. Технические документы позволяют обнаружить потенциальные проблемы и ошибки в проекте еще до его начала. Куда намного проще переписать текст или перерисовать диаграмму, чем переделывать запущенную техническую систему. Это позволяет снизить риски и улучшить качество результата.

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

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

Что должно быть в хорошем дизайн документе?

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

Цель. Любая работа начинается с целеполагания. Всегда важно понимать, чего нам нужно достичь.

Требования. Важно прописать требования в явном виде в самом начале. Именно требования определяют дальнейший дизайн системы и работу по проекту. Все требования можно разбить на 2 блока: функциональные и не функциональные. К функциональным относится описание того, как должна работать система, какие функции предоставлять. Нефункциональные требования — это часто ограничения, предъявляемые к системе. Нефункциональные требования касаются таких вопросов, как масштабируемость, производительность, надежность и отказоустойчивость, безопасность, сложность и стоимость поддержки. Также в требованиях стоит прописать ожидаемый уровень нагрузки, количество запросов, объема и количества хранимых и передаваемых данных.

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

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

Предлагаемое решение. Данная секция описывает то, как вы предлагаете достигать исходную цель, учитывая вышеописанные требования. К этому моменту уже есть достаточно хорошее понимание, что надо сделать, какие есть проблемы и как их можно решать. Эта секция отличается от проекта к проекту. В некоторых она должна быть сфокусирована на верхнеуровневой картине архитектуры и взаимодействии разных сервисов и систем хранения данных друг с другом. В других может быть больше погружения в детали кода, алгоритмов или проектирования API. В этой секции я бы всегда рекомендовал строить повествование от большего к малому. Сначала дизайн описывается поверхностно, и далее по ходу текста происходит уточнение и погружение в детали. Также очень полезно прикреплять графические материалы в виде диаграмм или иных изображений. Человеческий мозг так устроен, что одна хорошая визуализация может раскрыть суть лучше тысячи слов.

Безопасность и конфиденциальность. Данная секция зависит от проекта и не в каждом документе является обязательной., Но если вы собираете и храните данные, то стоит задуматься о выполнении требований законодательства стран, где будет работать сервис. Стоит явно продумать и прописать планы по обеспечению безопасности и конфиденциальности собранных и производных данных, включая политики и процедуры работы с ними. Если ваша система будет принимать контент, создаваемый пользователями (user generated content), стоит заложить возможность модерации такого контента. Если вы позволяете постить фото или видео, очень быстро появятся те, кто начнет загружать взрослый контент. Если вы позволяете публиковать текст, вскоре появятся те, кто будут постить ссылки на разного рода фродерские и просто сомнительные ресурсы. Также стоит помнить, что система должна поддерживать право на забвение и удаление контента по требованию автора. В случае предоставления публичного доступа к сервису из интернета, надо отдельно продумать риски эксплуатации дыр в безопасности.

Производительность и отказоустойчивость. Обязательный пункт, если вы делаете комплексную систему или новый сервис. По идее в требованиях должны быть прописан уровень доступности сервиса и какой SLO вы должны выполнять. Я бы рекомендовал сразу фиксировать цели по доступности и производительности ещё до начала проекта. Потому что в дальнейшем может случиться так, что вы в них не попадаете, а их выполнение требует значительных доработок и переделок. Куда проще обдумать это заранее и сразу учитывать в своей архитектуре.

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

Масштабируемость. Важно иметь план как будет масштабироваться система в случае увеличения нагрузки и просто во время своей жизнедеятельности. Будет ли это простой и рутинный процесс добавления железа или же сложный процесс, требующий инженерных доработок? Есть ли понимание как можно масштабировать каждый из компонентов системы? Понятно, что увеличение нагрузки на порядки не всегда имеет смысла закладывать сразу — всё имеет свою цену. Но иметь план по масштабированию системы в 2-5 раз от обычных рабочих нагрузок стоит.

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

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

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

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

На что ещё обращать внимание при написании дизайн документов?

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

Первым шагом обычно стоит описать разделы про цель и требования. Далее можно посмотреть на них и задаться вопросом, а что нам не хватает в текущей системе? После погружения в текущие реалии существующей системы полезно зафиксировать это в секции «Текущее состояние». Этот шаг особенно актуален, если не вы изначально проектировали исходную систему или не имеете глубокое погружение в неё.

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

Также еще несколько рекомендаций, на что стоит обращать внимание при написании технического документа:

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

Простой и понятный язык. Нет ничего более утомительного, чем читать длинные и сложные предложения длиною в абзац. Если к концу предложения забываешь, что было в начале, это усложняет восприятие. Я бы рекомендовал писать кратко, просто и понятно. Отдельно стоит отметить документы на не родном языке (например, английском). Точно стоит избегать желание впихнуть всю ту новую лексику, которую вы недавно усвоили на языковых курсах. Не стоит усложнять жизнь себе и коллегам. Выражайте мысли максимально простыми и общеизвестными словами и выражениями.

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

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

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

Заключение

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

• Building a better Go linker

• Go Smarter Scavenging

• Scalable Go Scheduler Design Doc

Спасибо за внимание и успешного написания технических дизайн документов!

Советы новичкам от опытного геймдизайнера

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

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

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

Тут важно отдельно выделить человеческий фактор. Даже при самом идеально написанном техническом задании (далее, ТЗ) будут те, кто его поймёт не так. Кто-то неправильно интерпретирует очевидный вам оборот. Кто-то не будет знать термина или будет знать его омоним (которые в индустрии встречаются довольно часто). Кто-то просто пропустит строчку, читая по диагонали. Действовать с такими людьми жёстко — с высокой вероятностью угробить собственную компанию.

Некоторые, желая сэкономить, нанимают геймдизайнера только для написания документации — результат обычно плачевный. Фильмы не снимают без режиссёра, даже когда из Marvel уволила гениального Эдгара Райта и он оставил после себя максимально полные раскадровки, они всё равно наняли другого человека, чтобы тот доделал фильм. Хотя раскадровки Райта, конечно, лезут из всех щелей и теоретически можно было бы работать по ним.

Теперь о том, как писать сам ГДД. Крупные компании используют для этого сервисы вроде Confluence, но я, поработав в них, нахожу их не особо удобными, по сравнению с самым доступным способом ведения документации — Google Docs. Легко заполнять, легко делиться, легко ориентироваться, да ещё и бесплатно. Если вы беспокоитесь за безопасность, всегда есть возможность сделать корпоративный аккаунт Gmail и тогда никто за пределами студии не зайдёт в вашу документацию.

Следующий большой вопрос — ГДД в одном файле, или как набор ТЗ. Скажу прямо — оба варианта имеют право на жизнь. Первый вариант имеет смысл использовать если у вас небольшой проект вроде match-3 или подобной игры. ГДД до 20 страниц объективно удобнее хранить одним куском. Если же у вас есть гора различных режимов или контента, например миллиард различных танков для WoT, или подробное описание каждого уровня для шутера, то лучше это всё распихать по разным документам, оставив главному лишь структуру.

Также это удобно для выдачи задач: кинул ссылку на конкретный документ — и не паришься, разъясняя, где искать. Но, повторюсь, очень часто удобнее хранить всё в одном файле так как многие проекты не отличаются размером.

Оглавление

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

В мой первый месяц работы у меня случилась неприятность: я выложил спецификации по самолётам для World of Warplanes в один подраздел (за давностью лет не помню уже в какой), а программисты искали его в соседнем (художники, кстати, не промахивались). Сначала я хотел продублировать ссылки, чтобы их можно было найти везде, но потом я понял, что правильнее просто выложить все ссылки в виде структуры прямо в главном документе. Тогда сразу появляется понимание структуры проекта и не нужно делать лишних кликов для перехода на нужную страницу.

Вступление

Место для краткого описания игры. Фактически краткая выжимка концепт-документа: название, технологии, платформы, аудитория. Это информация не для вас и не для вашей команды, а для продюсеров, которые, открывая ваш документ, должны мгновенно понять, что у них в руках. И заодно понять, не лажанулись ли вы с позиционированием и своими возможностями.

Базовый геймплей

Необходимо выделить для себя, какая часть игры у вас является базовой, то есть, в чём игрок будет проводить больше всего времени. Например, в нашумевшей Gardenscapes игрок в основном играет в match-3, хоть это и не подчёркивается. Там создатели делают упор на обустройство сада, а match-3 как бы второстепенное занятие, служащее для зарабатывания звёзд. Но на самом деле в этом разделе нужно описывать именно его.

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

На этом этапе часто встаёт вопрос: как структурировать написанное так, чтобы программисту его было легко читать. Перепробовав множество разных вариантов, я пришел к выводу, что лучше всего поступить так: в каждом разделе использовать свою нумерацию с иерархией. То есть, пишете утверждение. Под следующим номером другое утверждение. Если у вас есть уточнение или дополнение к основному утверждению, то переходите на один уровень вглубь и пишите там. Например: 1. Персонаж двигается в изометрии при помощи WASD. 1.1 Если игрок направляет персонажа в стену, тот останавливается при столкновении со стеной. 2. При нажатии на ЛКМ игрок стреляет. И так далее.

Важно описать всё не красиво, а точно, не упустив ни малейшего аспекта. Баг, сделанный программистом, чинится им же в ограниченное время. Дизайнерский баг (непродуманный момент) может разом перечеркнуть многие месяцы работы команды. «Не ошибается тот, кто ничего не делает» — отличная фраза для такой ситуации, потому что не реально предусмотреть всё, но одно дело не продумать один экран, а совсем другое — ошибка в базовой механике, из-за которой всё неиграбельно.

В первые три-четыре года работы геймдизайнером и в первые три-четыре месяца на новом рабочем месте вы обязаны подружиться с лидом программистов, чтобы скидывать ему свеженаписанные ТЗ с вопросом: «Нормально?». Это значительно повышает их качество и снижает время, потраченное на разбирательства.

На минутку вернувшись к теме хорошего геймдизайнера, могу сказать, что он ежесекундно должен ставить себя на место других людей и задавать себе вопросы: «Что мне понятно из этого экрана?», «Что будет понятно обычному геймеру?», «Куда бы я нажал, если бы открыл это меню в первый раз?», «Как может человек интерпретировать эту иконку?» и ещё около миллиарда таких же. Главный же вопрос гейм-дизайнера (если уходить в дебри) это «Почему?» . От «Почему PUBG такой популярный?» до «Почему эта фича, которую я придумал, будет востребованной?».

HUD или интерфейс базовой игры

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

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

Интерфейсы и главное меню

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

Лично я для этого использую программу Pencil Project, но вы вольны выбирать всё, что угодно. Хоть карандашом на бумаге рисовать и фотографировать. Вместо картинок — прямоугольники, кружочки, стрелки. Минимализм.

Теперь о том, что этими самыми программами мы будем рисовать. Начать лучше всего со схемы экранов. Возьмите все ваши экраны и окна и разложите на экране. Проведите стрелочки: откуда куда игрок может переходить. Это своего рода интерфейсное оглавление, которое поможет собирать проект.

Дальше идут мокапы всех окон, начиная с главного меню, и заканчивая самым маленьким окошком с кнопкой «Ок» . Не забывайте про то, как из них выходить! Под каждым мокапом должно быть краткое и понятное описание каждой кнопки и другого элемента окна и что они делают. Лайфхак для сложных экранов: возле каждого элемента поставить кружок с числом, а снизу пронумерованные пункты.

Когда художник отрисует это окно, рекомендую наложить эти же кружочки на его рисунок и подменить его в ГДД. Это поддерживает актуальность и понятность, особенно если в процессе отрисовки что-то изменилось, например, положение кнопок.

Остальные фичи

Дальше мы просто бьём проект на мелкие составляющие и описываем каждый в своём разделе. Туториал, инвентарь, диалоги, глобальная карта, прокачка — всё, что у вас есть. Описывается всё так же, как и базовый геймплей. К каждой из фич в раздел стоит запихнуть мокап того, что с ней связано.

Функциональные разделы

В конце ГДД можно вставить несколько разделов, которые являются очень полезными для некоторых жанров.

Балансировка — описание того способа, которым гд будет балансировать игру. Нужен практически для всех игр, особенно f2p. Оптимальным вариантом для меня является xml-файл, который конвертится и заливается по специальному адресу. Потенциально ужасный вариант — веб-интерфейс, в котором каждый параметр нужно вводить ручками.

Админка — возможность банить и поощрять пользователей через веб-интерфейс. Необходима для он-лайн игр.

Сбор статистики — жизненно необходимая вещь для f2p. Перечислить все точки сбора статистики и формат её получения.

Minimum Value Product или MVP — описание минимально играбельной версии, которую можно выложить на общий доступ, чтобы проверить, насколько ваш базовый геймплей востребован. Необходимо если вы делаете f2p и придумали оригинальный геймплей.

Чего НЕ должно быть в ГДД?

Прежде всего — описаний анимаций. Это самая частая ошибка новичков. Называйте действия конкретно: «Пушка стреляет». Да, у вас мультяшный стиль и пушка перед выстрелом надувается, будто тужится — всё это не важно программисту, а аниматор лучше вас знает особенности движка и как сделать всё атмосферно. А пожелания лучше передавать ему лично.

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

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

Литературных описаний — никто не оценит.

А что дальше?

После того, как вы написали все ТЗ и лид программистов уверенно сказал «Нормально», вы переходите на главную часть работы геймдизайнера — коммуникации. Если эта статья вам понравится, то я напишу ещё одну — как правильно выдавать работу разным специалистам и принимать результаты.

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

Научитесь: Профессия Геймдизайнер с нуля до PRO
Узнать больше

Доклад, по мотивам которого публикуется материал, был прочитан в начале октября в Высшей школе бизнес-информатики НИУ ВШЭ.  

Антон Подакин

Почему важно писать дизайн-документ?

За 8 лет в игровой индустрии я сталкивался с разными точками зрения насчет создания гейм-дизайнерской документации. До работы в Rocket Jump, где мы выстроили грамотную структуру работы с ГДД, доводилось слышать достаточно много негатива в адрес диздоков. Гейм-дизайнеры находили разные изобретательные оправдания, чтобы не вести документацию. Вот некоторые из них:

Какой итог?

• Вы получаете от исполнителя (например, художника) не то, что хотели.
• В свою очередь, продюсер тоже получает от вас не то, что было нужно.
• Вы тратите время на лишние объяснения и дополнения, которых можно было избежать.
• Вы забываете, какие решения были приняты. В этом случае, скорее всего, придется продумывать фичу заново. А сроки уже поджимают, да и результат, скорее всего, получится не таким, как задумывалось изначально.

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

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

• описание игры (ЦА, платформы, жанр);
• схема геймплея;
• описание механик и интерфейса;
• используемые в разработке технологии;
• требования к графике/арт-дизайну/звуку;
• сюжет/лор;
• заметки гейм-дизайнера.

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

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

• гейм-дизайнер;
• продюсер;
• QA;
• программист;
• UI-дизайнер;
• сценарист;
• художник;
• маркетолог / комьюнити-менеджер;
• новый сотрудник компании.

В каждом случае человек «выдергивает» из документа нужную ему информацию. И именно от гейм-дизайнера зависит ее качество и целостность.

Конечно же, дизайн-документ — не панацея. Но он здорово экономит как ваше время, так и время ваших коллег, и, как итог, повышает качество конечного продукта, исключая эффект «сломанного телефона».

Три всадника ГДД-апокалипсиса

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

Неоднозначность/непонятность

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

Неграмотность

Чтение документации сильно усложняется, если в тексте полно проблем с орфографией, грамматикой и пунктуацией. Позаботьтесь об этом.

Информация не по существу

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

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

Выбор инструментария

Существует множество инструментов для работы с документацией. Из них можно выделить группу wiki-движков:

• MediaWiki;
• DokuWiki;
• Markdoc;
• Sphinx.

Различаются они используемыми языками, функциональностью «из коробки» (поддержка стилей, аккаунты с разными правами, заливкой и типом хранения файлов и тому подобным), расширяемостью. Есть даже большой сайт, где можно в деталях сравнивать между собой различные движки.

Помимо wiki-движков используются следующие системы:

• Google Docs (или аналоги — например, офисный пакет iCloud);
• Evernote;
• GitHub.

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

Мы в Rocket Jump используем связку Confluence и JIRA. Первый сервис — инструмент для ведения документации, второй — известный таск-менеджер. Оба очень хорошо дополняют друг друга — например, в статью в Confluence можно интегрировать задачу из JIRA, отслеживать ее статус. При использовании других систем могут возникнуть сложности при интеграции таск-трекера с документацией.

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

Советы из практики

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

1). Сохраняйте актуальность и полноту информации. Устаревший или недоделанный диздок — почти так же плохо, как и его отсутствие. Чтобы понимать проект и правильно его развивать, нужно постоянно видеть общую, правдивую, детализированную картину.

2). Для оформления документов лучше всего создать отдельный небольшой регламент, по которому все будут понимать, как нужно оформлять ГДД. Сюда — утвержденные шрифты, тонкости касательно форматирования, что в документе означает курсив, что нужно выделять «болдом» и так далее. В будущем это ускорит навигацию по диздоку и упростит коммуникацию в команде.

3). Стоит разработать единый для вашей команды стиль оформления ГДД и его структуру. Ниже — упрощенная структура документации, которой мы пользуемся в Rocket Jump:

4). Работая с конфигами, пропишите в диздоке те механизмы и структуры, которые вы в будущем захотите варьировать во время настройки механик. Если не сделать это заранее, велик шанс, что потом придется просить программистов «вытаскивать» из кода то, что можно было сразу вывести на поверхность. Вот пример одной из страниц нашей документации, где приведен кусок кода, с которым нам нужно будет иметь дело в будущем:

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

6). Прописывая формулы, обязательно приводите пояснения (легенду) — за что отвечает каждая переменная, и как она взаимодействует с другими элементами формулы. В дальнейшем, если вы будете использовать одну переменную в разных точках ГДД (а такое будет), это сильно упростит работу.

7). Соблюдайте единство нейминга. Договоритесь «на берегу» и зафиксируйте в документации, как в команде будут называться юниты, предметы и прочее. Это благотворно повлияет на дальнейшую работу с локалями и не приведет к недопониманиям и лишним поискам. Никому не хочется накануне сборки патча узнать, что один и тот же юнит у четырех сотрудников называется по-разному:

Именно поэтому мы в Rocket Jump ведем на каждом проекте полноценный глоссарий, в котором приведены утвержденные названия всех сущностей.

Итог

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

Читайте также: 

• Как написать хороший дизайн-документ?
• Бенчмаркинг в игровой разработке или с чего начать создание игры?