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

Обновлено: 07.07.2024

Вооружившись знаниями из первой части и потренировавшись в составлении концепт-документа «на кошках», самое время переходить к дальнейшей работе! На очереди – дизайн-документ. Иногда его ещё называют «диздок», реже – «ДД», а особые языковые садисты именуют «ГДД» (вероятно, от английского Game Design Document) и «Вижн» (от английского Vision – подразумевается «ви́дение игры»). Пожалуйста, не будьте языковыми садистами.

Теория,
которая могла выглядеть сплошной стеной текста,
если бы не две картинки

Дизайн-документ – полное описание будущей видеоигры. От своего предшественника, концепт-документа, отличается максимально возможной детальностью и проработкой каждого затрагиваемого аспекта – это и механики, и уровни, и сюжет, и интерфейс, и вообще всё, что должно быть в игре. В определённом смысле дизайн-документ можно назвать подробным планом, в котором указано, что надо делать, но не указано кем и как (для этого существуют другие документы).
Дизайн-документ составляют для упрощения работы и повышения её эффективности. Большинство видеоигр включают в себя такое количество компонентов и взаимосвязей, которое не влезет ни в одну голову. А ведь есть ещё коллеги, они нуждаются в актуальной информации и если не смогут найти её «на бумаге», то начнут постоянно задавать вопросы. При вербальном обмене информацией сначала что-то забудется, затем вспомнится то, чего не было, потом перепутается всё, что уже есть, – и так снова и снова. Результаты обычно не радостные:
а) многократные переделки одних и тех же элементов;
б) дублирование работы;
в) хаос во взаимодействии с коллегами;
г) постепенное разноплановое изменение общей структуры и, как следствие, нарушение целостности готовой видеоигры.

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

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

В дизайн-документ крайне желательно добавить следующую информацию:
1. Данные для идентификации игры.
а) название (рабочее или итоговое – разница не принципиальна);
б) жанр (если он есть – ведь не все игры создаются по шаблонам);
в) тип графики (двух- или трёхмерная);
г) стилистика;
д) платформы (персональные компьютеры, консоли, планшеты-телефоны с указанием операционных систем).
2. Пользовательские настройки.
Из названия логично следует, что в данном пункте указываются те настройки, которые доступны игроку и могут быть им изменены. Уровень звука и музыки, включение субтитров, смена разрешения игрового экрана, выбор языка, «горячие» клавиши и клавиши управления для клавиатуры, мыши, геймпада.
3. Интерфейс.
Схематичное изображение всех окон меню с указанием активных элементов – кнопок, переключателей, полос прокрутки – и действий, которые происходят при их использовании. Часть работы может быть делегирована специально обученному человеку – дизайнеру интерфейсов (больше известен под модным наименованием UI/UX-дизайнер). При разделении обязанностей на совести игрового дизайнера остаётся назначение действий, а дизайнеру интерфейсов поручается двигать элементы туда-сюда для достижения лучшей эргономики и внешнего вида.
4. Уровни.
Практически в каждой игре есть уровни. Выглядят они по-разному: ветвистые коридоры, локации со свободным перемещением, постройки из фигур, сменяемые подложки заднего фона, – но они есть, а значит, их существование должно быть учтено, подсчитано и описано. Отображаются схематичным образом с указанием ключевых элементов: здесь пол, там лава, слева тайник, справа пропасть, за дверью головоломка, место появления персонажа отмечено крестиком, монстры обозначены ноликами.
Бывает и такое, что уровни в игре есть, а подвести их под общую схему не получается. На выручку придёт обычное текстовое описание. Даже самые процедурно-генерируемые уровни из всех процедурно-генерируемых имеют правила – их-то и нужно указать:
а) как собирается уровень и из чего (типы поверхностей – почва, дорожки, мосты, энергетические платформы, ледяные кубы);
б) какие пассивные объекты привязаны к поверхностям (камни бочки, тумбы, стенды);
в) при каких условиях появляются активные объекты (существа, оружие, бонусные очки, пакеты здоровья).

Типы уровней

5. Игровые объекты.
То, что располагается на уровнях, и то, с чем игрок может взаимодействовать. Объекты, на которые можно запрыгнуть, подлезть под них, обойти, упереться лбом (кроме стен уровня). Объекты, которые можно толкнуть, собрать, перетащить, выбросить, уничтожить или пораниться при столкновении. Одним словом – список. В него скрупулёзно вносится всё до последнего пикселя. Если у объектов есть характеристики и свойства, они тоже указываются (вес, количество единиц здоровья, изменение чего-либо при активации – добавление патронов или брони, уменьшение энергии). И чем больше таких вот характеристик, тем менее понятно будет выглядеть список, если делать его в виде простого перечисления. На помощь придут лучшие друзья игрового дизайнера – таблицы.
6. Сюжет.
История мира, описания персонажей и монстров, диалоги, задания – всё, что относится к литературно-художественному тексту.
7. Система звуков и музыки.
Заполнение данного пункта может вызвать проблемы у игровых дизайнеров, начисто лишённых музыкального слуха, но кое-какие действия выполнить придётся. Указать количество музыкальных композиций и, по возможности, их жанровую принадлежность. Перечислить объекты, которые должны издавать звуки, и дать краткое описание: звук падающего камня, звук лазерного выстрела, звук сменяемой обоймы, звук мотора.
При необходимости добавляются данные о персонажах, которых необходимо озвучить: количество, половая принадлежность, возраст, особые приметы (акцент, хрипение).
В некоторых видеоиграх звуки и музыка являются не дополнением, а частью или основой игрового процесса: ритм-игры; представители жанров «стелс» и «хоррор», где важно слушать и слышать. Здесь важно составить и расписать систему от и до: какие действия должен совершать игрок при прослушивании музыки, какая погрешность допускается при ошибочных действиях; на каком расстоянии затихают звуки, каков радиус слышимости у персонажей.
8. Система сохранений и загрузок.
Сохранения условно можно разделить на два типа – автоматические и ручные. Разница между ними в том, что первые происходят при заданных разработчиком условиях и без вмешательства игрока (например, через расположенные на уровне контрольные точки), а выполнение вторых зависит исключительно от игрока – человек должен нажать кнопку «Сохранить», иначе достигнутый им прогресс будет утерян. К типу системы добавляется список объектов и значений, которые должны сохраняться и загружаться.
9. Система социального взаимодействия.
Социум – это люди, и варианты игрового общения с ними должны найти отражение в дизайн-документе. Хороший пример – массовые многопользовательские онлайн-игры, сама их суть сводится к постоянному взаимодействию – и ради достижения целей, и так, из любви к искусству. Однако не ММО едиными! Социальная сторона одиночных видеоигр может выражаться таблицами рекордов, достижениями, локальным и кооперативным мультиплеером, обменом предметами.
10. Система ролевых элементов.
РПГ (от английского RPG – role-playing game) – видеоигра, в которой нужно отыгрывать роли. Абсолютно любые роли – важен сам факт, а не конечный набор. Механики отыгрыша создают относительную свободу действий, вариативность игровых элементов и способствуют многократным повторным прохождениям с отличающимся результатом. Подобные возможности вызывают у игроков настолько большой интерес, что другие жанры нередко заимствуют элементы РПГ для собственного улучшения и развития.
Примеры ролевых элементов:
а) выбор персонажей и прокачка их характеристик;
б) взаимодействие с игровым миром и влияние на него;
в) «деревья» навыков и диалогов (выбор пути развития);
г) свобода перемещения.
При работе с системой ролевых элементов стоит учитывать, что каждый новый вариант развития значительно повышает сложность её составления и последующего тестирования.

На этом основные пункты заканчиваются. Какие-то из них могут оказаться лишними, о других не упомянуто в силу их меньшей распространённости, третьи пока ещё не существуют. Главное, что нужно понимать: чем больше информации об игре упорядочено и записано в дизайн-документ, тем проще будет работать. И речь идёт не столько о игровом дизайнере (хотя проще будет и ему, безусловно), сколько о его коллегах – это те самые люди, которые превращают документацию в рабочий продукт.
Забота о коллегах проявляется и в поддержании чистоты: в дизайн-документе нет места заметкам, размышлениям, сомнениям, неточностям, двояким толкованиям, шуткам (если они не являются частью сюжета). Лишнее должно оставаться в черновиках.

Уже не теория,
ещё не практика

Дизайн-документ – это, в основном, текст и цифры (расчёты, формулы, графики). Инструменты для работы соответствующие – текстовые редакторы и электронные таблицы.
1. Локальные редакторы и таблицы (например, «Ворд» и «Эксель»).
К достоинствам можно отнести расположение файлов (к ним всегда есть доступ) и удобство работы (полный набор возможностей, оформление, простота использования). К недостаткам – сложности с получением доступа у других людей, проблемы навигации (диздок не всегда представляет собой один большой файл, чаще он разбит на логические части, каждая часть – в отдельном файле, и если все они – локальные «вордовские» и «экселевские» документы, то ориентироваться в них непросто).
2. Облачные редакторы и таблицы (например, «Гугл документы», «Яндекс.Диск»).
Плюсы и минусы предыдущего пункта меняются местами. Доступ к облачным документам легко выдать любому количеству людей, проблема навигации исчезает благодаря гиперссылкам и их более удобному использованию. Заплатить за это придётся урезанными возможностями оформления и вечным удалённым доступом (нет интернета? заблокировали учётную запись? увы).
3. Корпоративные редакторы и таблицы (например, решения на основе вики-движка).
Объединение двух предыдущих пунктов – облачный инструмент, который находится в локальной сети.

Пара слов,
которые влезли без очереди

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Типичная схема. Если постараться, то несложно её разобрать в отрыве от ГДД

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

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

Мой мокап для замороженной игры про кулинарию. За референт бралось меню Clash Royale

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

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

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

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

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

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

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

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

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

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

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

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

Со словом "дизайн-документ", или "диздок", связано много ритуалов поклонения. Типа, если правильно написать диздок, то божество (игровая компания) даст денег на разработку игры. А чтобы его правильно написать, надо строго, до запятой, соблюдать какие-то догмы.

Но если просто прошвырнуться по гуглу (или яндексу), получится забавно. Есть статьи про то, как правильно писать диздок (везде правильно по-разному). Также есть статьи, почему его не надо писать. И даже почему он вреден. Не будем вести себя подобно дикарям перед алтарём, а посмотрим в суть.

Диздок надо писать в первую очередь для себя.

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

Диздок, как можно догадаться, находится где-то посередине.

Что такое дизайн-документ и для чего он пишется?

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

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

То есть, диздок – это куда мы записываем все мысли насчет игры? Да, но только это диздок курильщика. Диздок здорового человека имеет чёткую структуру вместо сумбурных мыслей. И его свойство таково, что пока вы его пишете, нежизнеспособные идеи будут отсеиваться сами собой, а вместо них, возможно, будут появляться более подходящие. Я сейчас банально найду в сети план какого-нибудь диздока, не обязательно самого правильного. Вот:

Введение
Биографии героев
Примерный сюжет
Описание геймплея
Описание дизайна
Разбивка на компоненты систем
Разбивка по ресурсам
Диаграмма прохождения игры
Предполагаемый график разработки
Дополнительные идеи и возможности

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

Введение
*Про деньги
Сюжет
Геймплей
Дизайн
Диаграмма прохождения игры
Компоненты
Ресурсы
Дополнительные идеи и возможности

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

И чтобы было чем заполнять, я как будто бы придумал игру под названием Mage Rage . Я её по-честному придумал: какой-то маг ходит и мочит всякую нечисть. Других подробностей пока не знаю. Надеюсь, что написание диздока поможет прояснить вопросы. Хорошо или плохо получится, но кого мне бояться? Только себя.

Я решил поискать игры с названием Mage Rage и нашел как минимум несколько. И как минимум одну "про мага, который ходит и мочит всякую нечисть". То есть моя идея оказалась совсем не новой. Ну и ладно, значит я на верном пути. И мне ничего не мешает сделать свою игру.

Коротко – основная идея игры. Этот раздел должен стать своего рода рекламным банером, который должен привлечь внимание. Хотя кажется глупо описывать игру для самого себя, подобное упражнение очень полезно. Поставьте себя на место постороннего человека и постарайтесь его заинтересовать. Оформление своей идеи внятными словами поможет обнаружить особенности или подводные камни, которые вы ранее не замечали.

После того, как академия магов отправила начинающего мага на гибель, он выжил, овладел разрушительной силой и вернулся, чтобы отомстить. Но сможет ли он сам устоять перед этой силой? Mage Rage – брутальный и атмосферный top-down shooter с безостановочным действием. Меняя ипостаси человека и демона, открывая и комбинируя десятки заклинаний, игрок вступает в битвы с тысячами врагов на десятках уровней, чтобы дойти до главной цели – Совета академии.

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

2. Про деньги

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

целевая аудитория – кто будет играть в эту игру и почему, какие ограничения по возрасту
особенности – чем эта игра отличается от других, чем должна "цеплять"
аналоги – какие аналоги у этой игры есть, и почему надо сделать ещё один аналог
платформы – на каких платформах будет выходить игра
монетизация – за счёт чего она будет приносить деньги
степень погружения – как часто и долго игрок должен играть в игру. 15 минут в день, или несколько часов подряд?

Здесь меня интересуют только особенности, платформы и аналоги.

Сочетание тёмной магической атмосферы с динамичным и брутальным шутерным стилем; широкие возможности комбинирования способностей персонажа. Возможность менять не только атаки, но и формы персонажа: маг может превращаться в демона. Чем чаще он превращается в демона, тем больше попадает под влияние тёмной силы. Визуально насыщенные графические эффекты заклинаний.
Window, Linux, web и мобильные устройства.
Аналоги: Crimsonland (PC, 2003), Enter The Gungeon (PS4, 2020), Mage Rage (ZX Spectrum, 2019)

Описывая особенности, я ещё больше развил идею. Ничего, что она становится всё сложнее и сложнее. Это сырьё для проекта.

Здесь нужно более подробно описать сюжет и героев игры. Но тоже не увлекаться.

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

Сюжет можно развернуть еще абзацев на 5, но не больше. Я не буду тут этого делать в целях экономии места.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Гейм Дизайн Документы (Game Design Document) уже давно стали отраслевым стандартом. Совсем недавно стали появляться аргументы против гейм дизайн документов.

«Он становится устаревшим сразу после публикации». «Никто в команде не любит его использовать». «Никто не обновляет его, и это приводит к серьезной путанице».

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

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

Дизайн документ должен быть доступен для всей вашей команды

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

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

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

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

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

Если бы вы объяснили Halo - используя эту линию - десяти разным людям и сказали им создать игру, у вас получилось бы десять разных игр.

И, вероятно, ни один из них не создал бы планету сверхоружия Halo.

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

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

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

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

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

Все идеи в одном месте

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

Представьте себе Skyrim - «там должны быть драконы!» Может быстро стать «там должны быть драконы, и игрок должен иметь возможность ездить на них!»

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

Внезапно у вас совсем другая игра.

Мы говорим, что вы не должны давать волю своему воображению? Точно нет. Мы говорим, что вы должны установить некоторые ограничения? Ну, только если вы хотите закончить свою игру.

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

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

Такие вещи, как язык дракона и анимация драконов, с которыми он будет сражаться, были бы более важными для игры.

Масштабирование

Больше похоже на Reign of Fire (отличный фильм, как отличная игра еще не была создана из этой концепции?)…

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

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

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

Шаг за шагом

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

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

Это то, что вы можете добавить по мере её разработки. Гейм дизайн документ дает вам перспективу и контекст. Он должен обеспечить надежную платформу для изучения различных игровых идей.

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

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

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

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

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

Как собрать всё вместе

Мозговой штурм

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

Это этап, когда вы решаете, почему вы делаете игру. Что за игра и какой в ней смысл. И чего вы пытаетесь достичь.

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

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

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

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

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

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

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

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

Эксперименты

В основе великих игр лежат отличные идеи. Кто знает, какой вариант игры будет лучшим? Это не всегда та идея, которая возникла в начале разработки игры, это точно.

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

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

Укрепление

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

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

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

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

Для кого вы должны писать геймдизайн документ?

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

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

«Управляй быстрыми автомобилями и взрывай!» Звучит круто для 14- и 15-летних мальчишек, которым ты рекламируешь свою гоночную игру. Но для вашей команды разработчиков это не дает достаточно подробностей, чтобы поддержать сплоченные усилия по разработке.

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

Язык также является важным элементом для рассмотрения.

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

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

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

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

Не забывайте, что это проектный документ

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

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

Как только документ собран, установите сроки

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

И - изменения

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

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

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

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

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

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