Делимся опытом: 5 примеров написания документации по разработке игр

Многие геймеры в детстве и юности мечтали разрабатывать игры. Некоторые начинали свой путь в молодости. И лишь единицы становились профессионалами в этом деле ближе к зрелости. Однако, сейчас на дворе не 90-е и даже не ранние 0-е, поэтому учиться геймдизайну и разработке игр, стало значительно проще. Но разработка игр, как и раньше, требует не только навыков программирования или способностей к рисованию, но и грамотной организации. Прежде всего, начинающему разработчику в организации процесса работы поможет разработка документации — дизайн-документ, технические задания, сценарий, эскизы и так далее.

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

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

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

Пишется дизайн-документ для решения сразу нескольких задач:

1. Поможет вам держаться плана — начав разработку, вы можете увлечься процессом, забыть свои изначальные идеи и просто потерять связь с реальностью. Диздок станет для вас планом, которой поможет вести разработку игры правильным курсом и не отвлекаться.
2. Поможет вам и другим людям понять, что вы хотите сделать — подробное описание игры в массе своих деталей создаст общее видение проекта. Каждый член вашей команды поймет, что от него требуется, а издатель решит, стоит ли выделять вам средства на разработку.
3. Покажет вашу серьёзность — издатели не заинтересованы в финансировании прожектов, которые не представляют собой либо чего-то сверхуникального или просто прибыльного. И тем более, если разработка представляет собой нечто нереализуемое. А каждый уважающий себя специалист со стороны, которого вы нанимаете, посмотрев ДД скажет, готов ли он присоединиться к проекту, или же игра не стоит свеч.
4. У вас будет поле для экспериментов — Документ будет корректироваться. И не раз. Именно в документе вы можете рассмотреть новые элементы и их взаимодействие с другими компонентами игры, не тратясь на разработку прототипа, который может оказаться нежизнеспособным.

Надеюсь, посмотрев на этот список, у вас появилось понимание того, что если дизайн-документ если и не обязателен, то крайне желателен. Но возникает вопрос. А как же ведётся разработка документации для геймдевелоперов?

Пишем диздок и смотрим на примеры

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

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

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

Отличным примером подобного текста будет первый раздел в дизайн-документе free-to-play shooter-a от первого лица Dirty Bomb. В разделе Game pillars. Здесь разработчики описывают особенности своего продукта и компании. Они выделяют три основы, в каждой из которых расписаны конкретные особенности. Возможно это не самое лучшее структурное решение, но хороший рекламный ход.

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

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

Всё это может вызывать непонимание и путаницу в голове. Поэтому, лучше всего посмотреть на документы, составленные уже профессионалами. Одним из хороших примеров может стать диздок (ссылка удалена) проекта «Ryaba’s Revenge». Почему стоит обратить внимание на этот документ. Во-первых, он на русском языке, это облегчит вам понимание, особенно если ваши знания английского оставляют желать лучшего.

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

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

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

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

Ещё один документ сюжетно-ориентированного проекта, удостоившегося массы наград и похвал, 3D квеста «Grim Fandango». В этом документе подробно расписаны головоломки и катсцены, а также в виде таблиц рассмотрены структура головоломок и локаций. Не совсем ДД, но хороший пример детального описания одного раздела.