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

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

Оставьте надежду, если вы разрабатываете игру без диздока, потому что она вряд ли доживёт до релиза. Объясняем, зачем и как составлять диздок.

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

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

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

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

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

Какие инструменты использовать для создания диздока

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

Обычно я создаю папку для проекта и добавляю в неё всё: сам диздок, папку с референсами, технические задания и прочее.

Если нужно составить какую-то схему, то я пользуюсь бесплатным сервисом draw.io. В нём можно создавать что-то подобное:

Для подготовки референсов я использую GIMP (графический редактор с открытым исходным кодом) или просто делаю скриншоты и записываю экран.

Диздок — это не:

• набор референсов;
• технические задания;
• сценарий игры;
• эскизы уровней и персонажей;
• фразы вроде «Боевая система как в Dark Souls, создание персонажа как в The Sims 4, разрушаемость как в Minecraft».

Диздок — это

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

• Платформы: ПК, консоли или мобильные устройства.
• Технологии: будете ли вы использовать готовый движок или напишете свой.
• Язык: русский, английский.
• Аудитория: краткое описание людей, для которых делается игра. Полное описание можно вынести в специальный раздел.
• Жанр: нелинейное 3D RPG с открытым миром.
• Настроение: мрачное, светлое.
• Эмоции: какие чувства должна вызывать игра. При этом можно попытаться воодушевить игроков мрачной игрой или заставить почувствовать обречённость в светлой.
• Возрастное ограничение: увидев, что у игры рейтинг 18+ (или A в системе ESRB), дизайнеры спецэффектов сразу поймут, что вы ожидаете от них кровь, а не радугу.
• Количество пользователей, режим: будет ли игрок один или же в команде с другими игроками. Нужно ли подключение к интернету.
• Время, место и длительность для игры: где и как долго человек должен играть в вашу игру, чтобы получить те эмоции, которые вы хотите передать. Например, можно играть три минуты в метро или очереди или засесть на несколько часов вечером у себя дома.
• Главная игровая механика: краткое, но ёмкое описание того, чем будет заниматься игрок. В Mirror’s Edge главные механики — это бег и преодоление препятствий, а в Papers, Please — вершение судеб.

Можно добавить и другие пункты, лишними подробности не будут.

Описание игровых механик и управления

Все игровые механики важно описывать очень точно. Например, вы можете указать, что игрок будет сражаться с врагами, убивать монстров и захватывать замки. Под это описание подходят как Heroes of Might and Magic, так и World of Warcraft, а они сильно различаются.

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

Кнопка E — взаимодействие с предметом или персонажем.

Взаимодействие с предметом или персонажем: игрок наводит курсор на объект и нажимает клавишу E. Тип взаимодействия зависит от типа объекта:

• персонаж — разговор (см. раздел Диалоги);
• персонаж-торговец — открытие окна торговли (см. раздел Торговля);
• предмет без владельца — подобрать предмет в инвентарь;
• предмет с владельцем — украсть (см. раздел Кражи);
• интерактивные объекты — запуск события (см. раздел События).

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

Сами же взаимодействия можно оформить в виде таблицы:

Источник статьи: http://skillbox.ru/media/code/kak_napisat_dizayn_dokument_dlya_igry/

GameDev: Пример написания диздока

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

И так, что за зверек такой и почему без него не обойтись.

Дизайн-документ или концепт-документ ( англ. game design document ) — это детальное описание разрабатываемой компьютерной игры. Диз. док. создается и редактируется командой разработчиков или одним разработчиком и в основном используется в индустрии видеоигр для организации работы разработчиков. Документ создается в результате сотрудничества между дизайнерами , художниками и программистами как руководство, которое используется в процессе разработки. Когда издатель поручает создание игры разработчикам, команда разработчиков должна создать документ, который часто связан с соглашением между издателем и разработчиком; разработчики должны придерживаться дизайн-документа во время процесса формирования игры.

По большому счету диздок вам не понадобится если вы что-то делаете один, но с каждым новым человеком в команде этот документ будет все более необходим.

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

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

В нашем случае он будет включать в себя:

4) Стилистика для художников, и референсы

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

Destiny of owl, судьба совы (Рабочее название).

Может 10 раз еще поменяться, но пока на мой взгляд оно хорошо отражает суть игры.

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

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

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

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

Двойной прыжок — Нажать прыжок будучи в воздухе. (? перышек)

Прыжок от стены — Нажать прыжок будучи вплотную к стене (? перышек)

Парение — удержание кнопки прыжка (? перышек)

Возможность цепляться когтями за стены и потолок.

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

Прыжок от стены — второй прыжок

Прыжок от потолка — Парение — Второй прыжок — зацепится за другую поверхность или потолок.

Цель каждого уровня собрать нужное количество перышек и пройти на следующий уровень. Уровни построены в виде головоломок как на скорость, так и на соображалку. Проход на следующий уровень открывается после необходимого количества перышек или ключа(?).

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

4) Стилистика для художников, и референсы

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

Здесь выкладывать ссылки на референсы и остальное не буду, дабы не приобретать лишних проблем.

Игра будет выложена на Google play за 2.5$.

Рекламы или внутреннего магазина в игре не будет.

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

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

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

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

Играйте в хорошие игры, делайте хорошие игры. Успехов в ваших начинаниях.

Источник статьи: http://zen.yandex.ru/media/id/5cb48fb075327600b390b4b7/gamedev-primer-napisaniia-dizdoka-5cf3c1f06d847900afdd48f3

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

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

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

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

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

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

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

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

А что дальше?

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

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

Источник статьи: http://dtf.ru/gamedev/13891-kak-napisat-dizayn-dokument-igry