Шаблон диздока для инди-разработчика

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

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

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

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

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

Введение

1 абзац с описанием игры. Опишите игру покороче, как если бы у вас было только 7 секунд для рассказа кому-нибудь. Постарайтесь передать настроение игры – общий энтузиазм («Это фантастический и захватывающий 3D платформер!») ценится меньше, чем текст по существу:

Дама пропала, и как всегда, виноваты вы. Теперь вам надо пробиться сквозь орду нежити, прежде чем ее принесут жертву божеству зомби… а вы даже не успели позавтракать. The Battle for Zombie Breakfast – это ужас/мрачная 2D игра с боковой прокруткой, в жанре «избей их всех» и главным героем по имени Исайя Наместник.

Биографии героев

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

Примерный сюжет

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

Описание геймплея

1-2 абзаца, описывающих каждый отдельный режим геймплея, начиная с основного игрового процесса. Например, в Half Life 2 сначала бы описывались общие передвижения героя и стрельба, затем ответвления геймплея (например, гравитационное оружие), затем последовательность использования транспортных средств.

Описание дизайна

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

Разбивка на компоненты систем

Примерный список необходимых систем (например, в большинстве списков наверняка будут: 2D и/или 3D-рендеринг, машина состояний, система сохранения/загрузки файлов, система пользовательского интерфейса, обработка столкновений, система частиц и т.д.). Не забудьте про специальные функции, которые могут не иметь собственной системы, но надо учитывать при создании других систем (например, дневные/ночные циклы, связанный с игровым процессом звук и т.д.). Если вы будете использовать API/SDK для системы, тоже делайте отметку, потому что внешнюю систему вам все равно придется изучать/интегрировать.

Разбивка по ресурсам

Похожа на предыдущую, но выполняется для графических ресурсов, текста и звука.

Графические ресурсы: Перечислите все основные области для дизайна (игрок, враги, миры, UI/меню, HUD, эффекты), примерно описывая, какими должны быть уже проработанные анимации и состояния, и все что вы на данный момент думаете об использовании пайплайнов/программ.

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

Звуковые ресурсы: Аналогично, основные области (звук в игре, отклик UI/HUD, музыка, голоса) должны быть определены и описаны.

Предполагаемая диаграмма прохождения игры

Цель этого раздела – пошагово описать действия героя при прохождении игры от начала до конца. Описание может быть общим или иметь много ответвлений (т.е. начало игры > видеосцена > тьюториал > развилка (видеосцена > уровень > экран результатов) > конец), но неплохо предусмотреть, не будет ли у игрока возможностей самостоятельно найти развилку, и не приведет ли это к проблемам.

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

Предполагаемый график разработки

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

Дополнительные идеи и возможности

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

Готово! Диздоки, выполненные по этому макету, могут быть и кратким концептом (2-3 страницы), и полным дизайн-документом (от 5 до 50). И наконец, несколько общих советов:

• Описывайте подробно, но не жестко. Помните, что в ходе проекта все разрешено изменять и развивать, а диздок – это общее описание, а не план. Если вы зафиналите проект совершенно другой игрой нежели та, которую вы описали в документе, это неважно – главное, вы ее сделали.
• Не стесняйтесь подсматривать, как описывают игры в чужих диздоках. Чаще всего именно так характер игры станет понятнее вам/членам вашей команды. Но не кладите это в основу всего документа. «Остряк Грим Фанданго с FPS качества COD4 и генерацией уровней как в LittleBigPlanet» звучит круто, но не объясняет, что вы делаете или как вы собираетесь это делать.
• Пишите хорошо. Только то, что диздок предназначен для членов вашей команды, не означает, что его не надо делать выразительным и читабельным. Помните, что вы неоднократно будете обращаться к тесту во время разработки, чтобы понять идеи и чувства, с которых вы все это начали.

Шаблон диздока для инди, о котором хорошо отзывались на форуме Unity: https://docs.google.com/document/d/1-I08qX76DgSFyN1ByIGtPuqXh7bVKraHcNIA25tpAzE/edit?usp=sharing

Источник: Статья на Gamasutra.com