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

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

Key Takeaways

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

Summary

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

Chapters

Full Transcript — Download SRT & Markdown

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

Speaker A

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

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

Frequently Asked Questions

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

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

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

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

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

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

Get More with the Söz AI App

Transcribe recordings, audio files, and YouTube videos — with AI summaries, speaker detection, and unlimited transcriptions.

App Store Google Play

Or transcribe another YouTube video here →