Как написать диздок

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

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

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

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

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

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

Некоторые, желая сэкономить, нанимают геймдизайнера только для написания документации — результат обычно плачевный. Фильмы не снимают без режиссёра, даже когда из 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, чтобы программисты легко могли подтянуть его прямо в игру. А потом его же будете локализовывать.

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

А что дальше?

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

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

Как написать диздок

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

О том, как написать диздок, который существует в крупных компаниях (автор этих строк работал с документацией Obsidian Entertainment, Allods Team, Raven Software, The Workshop, Slightly Mad Studios, преподает курс проектной документации в геймдизайне в Высшей школе бизнес-информатики НИУ ВШЭ на программе профессиональной переподготовки Менеджмент игровых интернет-проектов), и будет эта краткая статья. Разумеется, кому-то описанное в ней может показаться очевидным. Она рассчитана на тех, кто как раз ищет ответы на вопросы «как написать диздок» или хочет устроиться работать геймдизайнером в крупную компанию-разработчика.

Проектная документация сейчас представляет собой не большой дизайн-документ, не набор файлов MS Office, и даже не файлы в Google Docs.

Почти всегда это вики-движок. Наиболее популярен Atlassian Confluence, но можно встретить и MediaWiki, как правило, с множеством плагинов и используемый в «старых» компаниях, и DocuWiki для небольших pet-project’ов или для маленьких студий. Поэтому готовность работы с документацией крупных проектов стоит начинать с умения работать с принятым на проекте вики-движком. То, что описывается как “диздок”, обычно заменено тремя отдельными документами в вики:

• Концепт-документ – краткое изложение самой идеи игры. Вида «У нас будет онлайн-игра про запуск и перехват ядерных ракет с бесконечным геймплеем, зрелищными спецэффектами и асинхронным PvP!». В нём описывается идея и основные составляющие игрового процесса (очень кратко), а также пара самых ключевых USP («unique selling point», то, что «продаст» идею игроку и уникально на рынке).
• Vision – это уже более развернутый документ, описывающий то, что хочется получить в итоге. Не сам игровой процесс, а всю игру, как конечный бизнес-продукт.
• Feature List (может быть обёрнут в другие документы в зависимости от модели разработки) – список с кратким описанием фичей, того, из чего состоит игра. К примеру, сборка ядерных ракет, аркадный перехват, асинхронное PvP, клановая система, система достижений, и так далее, как правило, со ссылками на отдельные документы с подробным описанием геймдизайна (об этом далее). Также в нем каждой фиче выставляется приоритет, стоимость и последовательность разработки.

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

Теперь переходим к Vision. Этот документ уже масштабнее, и обычно включает в себя следующие элементы:

1. Краткое описание игры. Здесь уже не только основная идея, а игра в целом.
2. Жанр игры.
3. Целевая аудитория и исследование рынка.
4. Примеры подобных игр на рынке и отношение к ним: конкуренты они или нет, есть ли пересечение аудитории, заимствование или противопоставление идей.
5. USP (Unique Selling Points) игры – то, что выделит игру на рынке, и что использует маркетинг для привлечения трафика / новых игроков.
6. «Формула успеха» – какие элементы игры будут самыми качественными / важными. Это может быть революционная графика, честная физика и т.д. Здесь в отличие от USP нужна не уникальность, а качество.
7. Составляющие геймплея, вкратце.
8. Сеттинг и стиль игры. Например, жестокий киберпанк в жёлто-серых тонах, светлое эпичное фэнтези в аниме-стиле, только куда подробнее и с примерами арта;
9. Бизнес-модель, в том числе монетизация.

Последовательность и цели написания здесь очевидны: написав концепт-документ, геймдизайнер определяет основную идею. Далее в Vision он описывает, как и почему эта идея будет работать: на какой аудитории, за счет каких элементов проект будет пользоваться успехом, и как он будет зарабатывать деньги. При этом, написание концепта и Vision – итеративный процесс. Написав концепт, можно попробовать продать предложенную в нем идею (инвестору, начальству, на крайний случай – самому себе) и улучшать его до тех пор, пока идея не будет продана. Написав Vision, можно оценить, есть ли у игры шансы на популярность и коммерческий успех, и перерабатывать его, меняя USP, сеттинг, стиль и прочие переменные, пока не будет хоть какая-то уверенность в результате.

Третий же документ Feature List представляет собой «разбор» описанной двумя предыдущими документами игры на компоненты. Это мостик к, собственно, разработке. Сообразно описанному в нем, продюсер или иной руководитель может составлять планы, рассчитывать майлстоуны, спринты и многое другое, но эта тема достойна отдельной статьи.

Простой же геймдизайнер, утроившись на работу в крупную компанию, вряд ли будет составлять вышеописанные три документа, но прочитать и запомнить их придётся. Основное время геймдизайнера уходит на последующий уровень — самый масштабный по объему. Это диздоки конкретных фичей, описанных в Vision и Feature List’е. К примеру, дизайн ездовых животных или дизайн нанесения клановых эмблем на броню… Впрочем, есть и куда более масштабные: дизайн системы характеристик персонажа или дизайн развития базы игрока.

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

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

• Шаблоны. Да, шаблоны и творчество могут казаться трудно совместимыми, но если на проекте несколько геймдизайнеров, и каждый пишет, как ему вздумается, продюсерам и исполнителям это радости не добавит.
• Связи с другими документами, фичами и задачами. Каждый диздок – это не просто сферический текст в вакууме. Он входит в какую-то группу (например, PvP-фичи), ссылается на другие документы, содержит в себе список задач (в JIRA/Bugzilla/Trello/GitHub/…), оценки готовности, ссылки на отчеты тестеров и результаты плейтестов.
• Собственно, фан и геймплей! За всеми слоями структуры диздока важно не потерять то, что игра все-таки должна быть интересной и увлекательной, фича должна работать в плюс всей игре, а не просто выполнять оторванную от общей идеи задачу.

Что же стоит описать в диздоке? Помимо просто описаний самой фичи, есть немало других элементов:

• Автор и статус (черновик, в работе, сделано, отказались, устарело). Когда на вики сотни диздоков, и за долгие годы работали десятки геймдизайнеров, без этих простых разделов понять, какой диздок актуален, затруднительно.
• Текущая задача. Что хочется получить. К примеру, обеспечить игроков развлечением, пока тренируются войска в казармах.
• Причины возникновения задачи и необходимости решения. Важный пункт, наличие которого спасает от фичей «чтобы круто было» или «у конкурентов есть». Последнее – бич многих геймдизайнеров, когда фичи копируются подчистую, даже несмотря на то, что многие их элементы в разрабатываемой игре лишние, не будут работать или работают в минус, даже если у конкурента это USP и приносит огромный доход.
• Краткое описание решения. Чтобы можно было охватить общую идею.
• Развернутый дизайн. Подробное описание реализации.
• Ожидаемое поведение игрока, типовая сессия. Нужна для того, чтобы ответить на вопрос «А как в это играть?» с позиции игрока. Без этого легко получить фичу, которая вроде бы и имеет смысл, но игроки на форумах пишут “И что это вообще такое?”.
• Место фичи в игре и связь с другими фичами. Очевидно, фича должна поддерживать и дополнять другие фичи или общий геймплей игры, а не повторять или подавлять их собой.
• Задачи на реализацию и ассет лист. Список того, что нужно сделать, чтобы фича заработала: какие функции на уровне кода, что нарисовать художнику, нужно ли написать тексты реплик персонажей сценаристу и т.д. Иногда это составляет продюсер, но нередко и сам геймдизайнер.
• Требуемая статистика. Какую информацию собирать и анализировать с плейтестов и серверов. Как много времени игроки проводят в геймплее фичи? Ездят ли они на лошадях или автомобилях в фиче о средствах передвижения, стреляют ли из Сайги или Вепря в ближнем бою шутера?
• Требуемое тестирование (+ edge cases). На что QA-отделу обратить особенное внимание при проверке фичи. QA могут такое составлять и сами, но нередко только геймдизайнер может сходу сказать, что «если вдруг игрок эксплоитами типа сложения эликсиров наберёт 1000 навыка Торговли, то сможет продать товар дороже, чем купил, и сломает всю экономику! Поэтому нужно убедиться, что такое невозможно даже теоретически».
• Deployment и оперирование. Раздел для оператора. Как описать фичу в patch notes? Нужно ли выложить о ней статью в энциклопедию игры? Требуется ли что-то отобрать у игроков и выдать компенсацию для запуска фичи?
• Планы на будущее. Собственно, все идеи, которые могут улучшить фичу в будущем.

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

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

07.02.2020

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

Геймдизайн-документ (диздок) — это детальное описание ключевых аспектов разрабатываемой игры. В этой статье преподаватели ВШБИ НИУ ВШЭ, авторы образовательных программ “Менеджмент игровых проектов” и “Основы создания игр”, поделятся своим опытом создания дизайн-документов для игровых проектов.

Зачем нужен диздок

Благодаря геймдизайн-документу каждый член команды видит “картину целиком”, что значительно облегчает понимание текущих задач на проекте. Кроме того, в диздоке фиксируются все доработки и правки, возникающие в процессе разработки. Написанием документации занимаются геймдизайнеры при поддержке всех ключевых специалистов (от программистов до технических художников).

При работе с небольшими проектами геймдизайн-документы обычно создаются в виде отдельного файла. Для крупных разработок используются специальные облачные хранилища с десятками отдельных ТЗ (технических заданий). Например, sunwiki, confluence или корпоративный сервис от Google.

Что пишут в диздоках

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

• Оглавление. На первой странице обычно описывают иерархию и структуру проекта. Здесь же находятся ссылки на все важные файлы и разделы, что существенно упрощает поиск информации о конкретной фиче (особенности проекта);
• Вступление. Здесь пишем краткое описание проекта: название, платформу, используемые технологии и целевую аудиторию игры;
• Геймплей. В этом разделе даем четкое и подробное описание игрового процесса. Важно! Сразу согласуйте описанные механики с командой программистов, чтобы избежать проблем в будущем;

• Интерфейс. В первую очередь описываем, что игрок видит во время кор-геймплея (базовой игры). Важно не засорять экран лишней информацией в этот момент. Дайте пользователю необходимые данные, но проследите, чтобы они не отвлекали от игрового процесса. Этот пункт геймдизайн-документа пишется совместно с командой художников;
• Мокап интерфейсов и главного меню. На этом этапе создаются графические наброски (схемы) всех игровых окон и интерфейсов. Они нумеруются, и под каждый экран пишется краткое описание;
• Игровые фичи. В этом разделе описываются ключевые механики: обучение, инвентарь, диалоги, глобальные карты, прокачка и другие. Обязательно создание мокапа для каждой фичи;
• Функциональные разделы: балансировка игры, панель администратора (необходимая для многопользовательских проектов), сборщик статистики (для f2p-игр), а также описание минимально играбельной версии игры (прототипа) для проверки востребованности ее базового геймплея.

Что не стоит писать в диздоке

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

• Описание анимаций. Их следует описывать в отдельных задачах для аниматоров. Например, если речь идет о шутере, старайтесь указывать конкретное действие оружия с учетом особенностей движка и визуального стиля проекта;
• “Тяжелые” референсы. Как правило, примеров нужно много и «весят» они прилично. Лучше всего хранить картинки в отдельных папках, а на видео давать ссылки;
• Тексты и литературные описания. Под них лучше завести отдельные xml-файлы, которые будет удобно использовать программистам.

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

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

Как написать идеальный дизайн-документ

Об этом вы сможете узнать, пройдя обучение по программе “Менеджмент игровых проектов” и “Основы создания игр” в ВШБИ НИУ ВШЭ в Москве. Вместе с опытными преподавателями создадите собственную игру, узнаете нюансы разработки, правила создания программной логики и механики.

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

Хотите стать геймдизайнером? Посмотрите лекцию нашего преподавателя  Константина Сахнова!

Еще больше информации вы найдете на канале
МИП ВШБИ на YouTube. Подписывайтесь и не пропускайте свежие записи с открытых мероприятий ВШБИ НИУ ВШЭ.

← Назад к списку

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

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

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

За 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 ведем на каждом проекте полноценный глоссарий, в котором приведены утвержденные названия всех сущностей.

Итог

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

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

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

Я написал уже не один шаблон диздока для инди-разработчика – своей команды – и нахожусь в процессе написания новых. Чтобы наша команда, которая разрабатывает приложения для iPhone, имела возможности выбора.

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

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

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

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

Введение

1 абзац с описанием игры. Опишите игру покороче, как если бы у вас было только 7 секунд для рассказа кому-нибудь. Постарайтесь передать настроение игры – общий энтузиазм («Это фантастический и захватывающий 3D платформер!») ценится меньше, чем текст по существу:

Дама пропала, и как всегда, виноваты вы. Теперь вам надо пробиться сквозь орду нежити, прежде чем ее принесут жертву божеству зомби… а вы даже не успели позавтракать. The Battle for Zombie Breakfast – это ужас/мрачная 2D игра с боковой прокруткой, в жанре «избей их всех» и главным героем по имени Исайя Наместник.

Биографии героев

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

Примерный сюжет

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

Описание геймплея

1-2 абзаца, описывающих каждый отдельный режим геймплея, начиная с основного игрового процесса. Например, в Half Life 2 сначала бы описывались общие передвижения героя и стрельба, затем ответвления геймплея (например, гравитационное оружие), затем последовательность использования транспортных средств.

Описание дизайна

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

Разбивка на компоненты систем

Примерный список необходимых систем (например, в большинстве списков наверняка будут: 2D и/или 3D-рендеринг, машина состояний, система сохранения/загрузки файлов, система пользовательского интерфейса, обработка столкновений, система частиц и т.д.). Не забудьте про специальные функции, которые могут не иметь собственной системы, но надо учитывать при создании других систем (например, дневные/ночные циклы, связанный с игровым процессом звук и т.д.). Если вы будете использовать API/SDK для системы, тоже делайте отметку, потому что внешнюю систему вам все равно придется изучать/интегрировать.

Разбивка по ресурсам

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

Графические ресурсы: Перечислите все основные области для дизайна (игрок, враги, миры, UI/меню, HUD, эффекты), примерно описывая, какими должны быть уже проработанные анимации и состояния, и все что вы на данный момент думаете об использовании пайплайнов/программ.

Текстовые ресурсы: Определите основные области (тьюториал, подсказки, скриптовые диалоги/квесты, динамические диалоги, повествование) и попытайтесь оценить количество работы, требуемой для каждой из областей.

Звуковые ресурсы: Аналогично, основные области (звук в игре, отклик UI/HUD, музыка, голоса) должны быть определены и описаны.

Предполагаемая диаграмма прохождения игры

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

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

Предполагаемый график разработки

И вот мы дошли до той части, где люди теряют самообладание, – до примерного графика разработки, который надо разбить на разделы подобные упомянутым в документе ранее. Планируйте жестко, но будьте реалистичны – скорее всего, вы не будете успевать день в день согласно плану. Не стоит конкретно планировать, что вы завершите такой-то этап к такому-то времени. Здесь должно быть количество рабочих часов на каждого члена команды и кто за что будет нести ответственность.

Дополнительные идеи и возможности

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

Готово! Диздоки, выполненные по этому макету, могут быть и кратким концептом (2-3 страницы), и полным дизайн-документом (от 5 до 50). И наконец, несколько общих советов:

• Описывайте подробно, но не жестко. Помните, что в ходе проекта все разрешено изменять и развивать, а диздок – это общее описание, а не план. Если вы зафиналите проект совершенно другой игрой нежели та, которую вы описали в документе, это неважно – главное, вы ее сделали.
• Не стесняйтесь подсматривать, как описывают игры в чужих диздоках. Чаще всего именно так характер игры станет понятнее вам/членам вашей команды. Но не кладите это в основу всего документа. «Остряк Грим Фанданго с FPS качества COD4 и генерацией уровней как в LittleBigPlanet» звучит круто, но не объясняет, что вы делаете или как вы собираетесь это делать.
• Пишите хорошо. Только то, что диздок предназначен для членов вашей команды, не означает, что его не надо делать выразительным и читабельным. Помните, что вы неоднократно будете обращаться к тесту во время разработки, чтобы понять идеи и чувства, с которых вы все это начали.

Шаблон диздока для инди, о котором хорошо отзывались на форуме Unity: https://docs.google.com/document/d/1-I08qX76DgSFyN1ByIGtPuqXh7bVKraHcNIA25tpAzE/edit?usp=sharing

Источник: Статья на Gamasutra.com