**Как и зачем писать дизайн документ для игры — Transcript & Summary | SozAI**
Source: https://sozai.app/transcript/writing-game-design-document-purpose/

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

## Key Takeaways

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

## What the video covers

- Дизайн-документ — это полное техническое описание всех правил, механик и систем игры.
- Существуют два условных типа диздоков: коммерческий (для инвесторов) и технический (для разработки).
- Коммерческий диздок включает название, платформу, движок, целевую аудиторию, дату релиза, вдохновителей и монетизацию.
- Технический диздок — более подробный и полезный для команды разработчиков, без лишней информации.
- Диздок быстро растет в объеме, поэтому важна хорошая навигация и использование форматов с автооглавлением (Word, Markdown).
- Рекомендуется подробно описывать управление для всех поддерживаемых устройств в начале документа.
- Все ключевые переменные и термины должны быть собраны в одном месте для удобства изменений и понимания.
- Важна четкая структура документа с жанром, синопсисом, стилем игры и общим описанием мира и передвижения.
- Диздок помогает избежать разночтений и обеспечивает единое понимание игры всеми читателями.
- Использование шаблонов, например, шаблона Скотта Роджерса для коммерческого диздока, упрощает процесс.

## Chapters

1. 00:00 Что такое дизайн-документ и его назначение
2. 00:51 Коммерческий дизайн-документ: структура и содержание
3. 02:09 Особенности коммерческого диздока и советы по его использованию
4. 03:32 Технический дизайн-документ и его важность для разработки
5. 04:37 Проблема разрастания диздока и выбор формата документа
6. 05:22 Навигация и контроль версий в диздоке
7. 06:52 Структура и ключевые разделы технического диздока
8. 08:10 Описание жанра, синопсиса и управления в игре
9. 10:28 Причины раннего описания управления и централизованное хранение переменных
10. 14:51 Стиль игры, мир и передвижение: общие рекомендации

Answers

## Questions about this video

Что такое дизайн-документ и зачем он нужен?

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

В чем разница между коммерческим и техническим дизайн-документом?

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

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

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

## Full Transcript — Download SRT & Markdown

00:00

Speaker A

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

00:15

Speaker A

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

00:32

Speaker A

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

00:51

Speaker A

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

01:05

Speaker A

план разработки и типы монетизации, и только потом описывать сюжет, локации и, наконец-то,

01:10

Speaker A

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

01:29

Speaker A

игру. А тем более знать дату релиза, возраст аудитории игры и все тонкости её монетизации.

01:43

Speaker A

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

01:57

Speaker A

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

02:12

Speaker A

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

02:33

Speaker A

но вы всё равно очень хотите получить от них деньги на вашу игру, лучше использовать концепт-

02:46

Speaker A

документ, о котором я расскажу в каком-нибудь другом видео. В целом, если вам нужно сделать

03:01

Speaker A

хороший коммерческий диздок — просто берите шаблон Скотта Роджерса и заполняете его. То, что

03:17

Speaker A

действительно будет вашим другом, помощником и отличным инструментом в разработке — это

03:37

Speaker A

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

03:52

Speaker A

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

04:10

Speaker A

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

04:22

Speaker A

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

04:37

Speaker A

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

04:51

Speaker A

в размерах и становиться 30-60-90 страничным документом за буквально месяц-два работы над

05:07

Speaker A

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

05:22

Speaker A

Два современных формата, которые хорошо имеют автооглавление: это вордовские документы и

05:38

Speaker A

Markdown. Если вам привычнее работать с Вордом — используйте Google доки. Будет проще и работать

05:56

Speaker A

с кем-то другим, и контролировать изменения и версии вашего документа.

06:06

Speaker A

Лично я использую Markdown и решаю вопрос контроля версий и совместной работы над документом через

06:22

Speaker A

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

06:38

Speaker A

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

06:52

Speaker A

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

07:08

Speaker A

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

07:21

Speaker A

за разделы? Из-за того, что дизайн-документ — это технический текст, как, например, чертёж или

07:26

Speaker A

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

07:40

Speaker A

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

07:54

Speaker A

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

08:10

Speaker A

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

08:24

Speaker A

главное, чтобы читатель хоть минимально понимал, он читает сейчас про "три в ряд" или гоночный

08:44

Speaker A

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

08:59

Speaker A

если таковые имеются, или сделать описание скрещиванием пары игр типа Survival Horror

09:14

Speaker A

как Resident Evil, но со сферическим миром как в Animal Crossing. В синопсисе максимально кратко

09:29

Speaker A

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

09:43

Speaker A

если в дальнейшем тексте упоминается, например, ружьё: старое однозарядное,

09:57

Speaker A

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

10:11

Speaker A

но я рекомендую полностью написать всё управление в игре.

10:28

Speaker A

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

10:43

Speaker A

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

10:57

Speaker A

вернуться к этому разделу и что-то дописать, переписать, поменять кнопки местами или удалить

11:10

Speaker A

что-то. Писать это в самом начале я предлагаю по многим причинам: для начала таким образом

11:25

Speaker A

вы никогда не попадёте в ситуацию, когда ваш дизайн превышает количество кнопок на геймпаде,

11:38

Speaker A

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

11:56

Speaker A

интерфейса или множеством слоёв действий на каждую кнопку. Ещё одна важная причина — и вы

12:15

Speaker A

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

12:24

Speaker A

руки на клавиатуру и "понажимать" вашу игру ещё до прототипа. Возможно, таким образом вы уберёте

12:39

Speaker A

какие-то неудобные кнопки или комбинации клавиш ещё до того, как сохраните первый драфт своего

12:52

Speaker A

дизайн-документа. И ещё одна немаловажная причина — это хранение всех переменных вашей игры в одном

13:08

Speaker A

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

13:20

Speaker A

"А", а спустя полгода разработки решите изменить это на кнопку "X", вам придётся в сотне мест,

13:34

Speaker A

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

13:48

Speaker A

это "А", а в документе обращались к ней как к клавише действия в этой же сотне мест, то чтобы

14:03

Speaker A

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

14:21

Speaker A

хранить абсолютно все часто упоминаемые структуры, объекты, концепты и вообще

14:39

Speaker A

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

14:51

Speaker A

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

15:06

Speaker A

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

15:21

Speaker A

Далее следует описать стиль игры. И стиль подразумевается в максимально широком смысле. Сюда

15:35

Speaker A

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

15:44

Speaker A

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

15:59

Speaker A

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

16:18

Speaker A

если он есть. Например: является ли этой игрой, поделённой на уровни, или это локации с хабом, или

16:38

Speaker A

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

16:54

Speaker A

карт — просто общее описание, что это такое. То же самое касается передвижения — будет ли

17:09

Speaker A

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

17:22

Speaker A

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

17:36

Speaker A

читатель должен иметь полное представление о вашей игре. Относитесь к этой части как геймплейному

Topics: дизайн-документ игровой дизайн разработка игр коммерческий диздок технический диздок управление в игре структура документа навигация в диздоке шаблон Скотта Роджерса Markdown для диздока

Учить по этому видео

- [Карточки по этому видео](https://sozai.app/ru/tools/ai-flashcard-generator/?from=transcript&id=31672)
- [Тест по этому видео](https://sozai.app/ru/tools/quiz-generator/?from=transcript&id=31672)

Бесплатно, составлено ИИ по этой расшифровке. Без регистрации.


---
This is the markdown twin of https://sozai.app/transcript/writing-game-design-document-purpose/ — the same content, without the markup.
Published by SozAI (https://sozai.app). Reuse and quotation are allowed with attribution and a link back.
Machine-readable index: https://sozai.app/llms.txt · data API: https://sozai.app/api/