Анатомия дизайн-документа (часть первая)

Анатомия дизайн-документа (часть первая)

_Тим Райан (Tim Ryan) Независимый разработчик игр, консультант по программному обеспечению. Работал над различными игровыми проектами с 1992 года. Один из последних PC-проектов Тима Райана - MechCommander: The First MechWarrior Game of Tactical Command._

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

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

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

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

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

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

Отклонение от плана
Уникальность вашего проекта может диктовать вам тот или другой план действий. Например, проекты по портированию обычно просты и не требуют отдельной документации, довольствуясь лишь техническим заданием (если не подразумеваются серьезные изменения в дизайне). Сиквелы (такие как Wing Commander II, III) или широко известные некомпьютерные игры (покер или "Монополия") не требуют детального описания устройства игры, а просто отсылают читателей диз-дока к самим играм или к описанию правил. В этом случае лишь специфические отличия от оригинала должны быть "занесены в протокол".

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

"Идейный документ" состоит из следующих компонентов:

Введение 
Предпосылки создания игры (опционально) 
Описание игры 
Основные особенности игры 
Жанр 
Платформа (или платформы) реализации
 
Концепт-арты, варианты графического оформления (опционально)

Введение: Предисловие к описанию идеи игры - возможно, наиболее важная часть документа в целом, оно должно заинтриговать читателя. Попробуйте описать игру одним предложением, но так, чтобы было понятно, что это самая лучшая игра из всех когда-либо существовавших. Включите сюда жанр, смысл, преимущества, фичи, и все те детали, которые нельзя опустить, и которые столь важны, что их необходимо сообщить в самом начале документа. Описывая преимущества игры, помните, что это те самые особенности, которые выделяют ваш проект в ряду схожих игр: 
"Man or Machine - шутер с видом от первого лица для PC, использующий модифицированный движок Quake II, способный заставить игрока почувствовать себя в роли космического дроида-десантника, оказавшегося в гуще событий эпических масштабов в техногенном мире 37-го века, мире жестоких межзвездных конфликтов". 
Можно разбить ваше введение на несколько коротких предложений, чтобы выразить мысль более четко и ясно. Но помните, что чем длиннее ваше главное предложение, тем более размытой кажется основная идея.

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

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

Основные особенности игры: Это то, что выделяет вашу игру из огромного количества других, то, для чего игра создается, и чему в дальнейшем будет посвящена основная работа над проектом. Это все фичи игры, на которые вы лишь намекали во введении и о которых упоминали в описании. В принципе, это те самые детали, которые привлекают покупателя, и именно их потом пишут на коробках с готовой игрой и выносят в заголовки в руководстве пользователя. Данный раздел также включает некоторые вспомогательные детали: 
"Искусственный Интеллект: Man or Machine использует продвинутые алгоритмы искусственного интеллекта, подобные тем, что сделали Half-Life игрой года". 
Количество "фич", которые нужно включить в описание - вопрос стратегической важности. Пара-тройка ключевых особенностей в описании - плохой тон, если вы хотите создать что-то более сложное, чем паззл. Список, не умещающийся на одном листе - тоже плохо, так как он выглядит слишком сложной задачей и отпугнет финансистов. Мало отличительных особенностей в игре - и ваша идея уже не выглядит продаваемой, много фич - и действительно важные особенности теряются среди незначительных. 
Не надо вписывать в ваш "главный список фич" те, что давно считаются само собой разумеющимися, такие как "отличная графика" или "привлекательная музыка". Превосходная графика и профессиональная музыка сегодня присущи каждому мало-мальски значимому проекту, и всегда ставятся во главу угла. Однако если вы думаете, что они действительно на голову выше всего, что существует на рынке в данный момент, то упомяните о них.

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

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

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

Общие ошибки 
Приведем ошибки, которые обычно совершаются на стадии выработки игровой идеи.

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

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

Документу не хватает конкретных деталей. Просто говоря о геймплее как о "похожем на Command&Conquer с примесью MechWarrior, управление роботами в тактических сражениях", вы даете недостаточно информации. Вам нужно сфокусироваться на действиях игрока, и более конкретно на том, как игра может принести удовольствие. Более детальный подход к описанию геймплея поможет читателю более четко представить себе смысл игры.

Идея игры не кажется привлекательной. Можно рассмотреть все слова, которые использует игрок для описания игрового процесса (стрелять, покупать, командовать, бежать, строить, смотреть и т.д.), и представить, как каждое действие выполняется в отдельности. Затем представить, насколько это интересно для целевой аудитории. Будьте объективны. Если что-то в вашей игре делать неинтересно, немедленно избавьтесь от этого действия и замените его другим, более веселым.

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

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

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

Анализ рынка 
Техническая оценка 
Правовая оценка (если требуется) 
Оценка стоимости и доходности проекта 
Концепт-арты, графическое оформление 
Анализ рынка - должен проводиться маркетинговым отделом или фирмой, специализирующейся в данной области (подразумевается, что ваша компания может позволить себе это). Если вы занимаетесь анализом рынка самостоятельно, то помните, что это более серьезное занятие, чем простое угадывание цифр и обдумывание тенденций рынка. Для начала загляните в Интернет (www.gamestats.com) и изучите финансовый успех хитовых игр того же жанра, что и ваш проект. 
Целевой рынок: Определяется жанром и платформой (эти детали затрагиваются при описании идеи игры). Можно уточнить сектор рынка, на который направлена ваша игра, приведя в пример несколько успешных тайтлов из этого же сектора. Несколько игр данной тематики также будут служить ориентиром для вашего проекта и показывать, насколько в целом перспективен выбранный вами целевой рынок. Также укажите предпочтительный возраст аудитории, пол, и другие характеристики. Если ваша игра - сиквел к известной игре или базируется на лицензионной технологии, опишите существующий рынок игр в серии или технологически сходных игр. 
Хиты: Дайте список самых продающихся проектов в этом секторе рынка. Представьте его в виде количества проданных единиц, включите также даты релиза. Даты можно давать приблизительные - "первый квартал 1998" или "весна 1998", список желательно составить в хронологическом порядке. 
Нелишним будет указать платформы успешных тайтлов, если они отличаются от вашей. Рынок для каждой платформы формируется по-разному, поэтому можно включить сюда и игры, не имевшие шумного успеха, но базировавшиеся на той же платформе, что и ваша игра. Эти данные могут быть полезны при изучении жанрового спроса в зависимости от платформы. Например, походовые стратегии отлично продаются для РС, но совершенно непопулярны для Sony Playstation. 
Сравнение ключевых особенностей игр: Выделите особенности, свойственные успешным проектам на рынке, сравните их со списком достоинств вашего проекта, который дан в описании идеи. Можно упомянуть о важных деталях. 
Тактика: В проектах Command & Conquer, Dark Reign, и Myth, вы управляете войсками, отдавая им указания атаковать определенные цели или занять определенную тактическую позицию. Большинство юнитов имеют уникальные характеристики, сильные и слабые места, которые становятся очевидными через некоторое время. Используя преимущества и недостатки юнитов, игрок вырабатывает определенную тактику действий. Tanktics, в свою очередь, предоставляет гораздо более широкий выбор приказов, чтобы обеспечить более тонкое управление юнитами (атаковать, захватить в плен, таранить, сменить позицию), и как следствие, более продвинутую тактику. Грамотное расположение юнитов и выбор целей приобретает еще больший смысл при использовании преимуществ ландшафта, особенностей стрельбы юнитов, наличия уязвимых мест. Каждый юнит несет различное вооружение, броню, и имеет различные скоростные характеристики, что делает управление еще более тактическим. Со временем игрок способен достичь высот в управлении юнитами, и научиться создавать составные скриптовые команды.

Технический анализ - должен проводиться опытным девелопером, желательно старшим программистом или техническим директором. Затем технический анализ, претерпевая изменения и со временем пополняясь, перерастает в план проекта. Анализ должен настроить читателей документа на оптимистичный лад относительно коммерческого успеха игры. 
Экспериментальные технологии: Определите, какие моменты в вашем проекте имеют экспериментаторский характер, какие новые или неопробованные технологии вы хотите внедрить. Не включайте в этот список те идеи, которые уже прошли апробацию в других проектах, даже если они в новинку для вашей команды. Например, если ваша команда никогда не разрабатывала трехмерный движок, не считайте это экспериментальной технологией, внесите его в другой раздел технической документации. Но если ваша команда работает над новой системой шейдеров в трехмерном движке, то это уже кандидат на позицию в списке экспериментальных технологий. Конечно, к тому времени, когда будет готова эта статья, шейдеры уже войдут в повсеместное применение. 
Включите в ваш документ время, необходимое на разработку новой технологии, начиная от времени подготовительной работы до непосредственно включения "фичи" в игру. Вообще, внедрение экспериментальных технологий - очень длительный процесс, так что чем больше экспериментов у вас в планах, тем дольше времени требуется для завершения проекта. Многих менеджеров отпугивает необходимость тратить по 18 или по 24 месяца на теоретические изыскания, но иногда это время необходимо для создания высокотехнологичных проектов, на голову выше всех подобных в индустрии. Об этом следует упомянуть в вашей документации, и не забудьте сказать о том, какие выгоды повлечет революционная технология в вашей игре. Пусть все почувствуют, что эксперименты хорошо окупаются. 
Основные задачи создания проекта: Необходимо составить небольшой список основных задач проекта. Их нужно описать обычным литературным языком, не вдаваясь в технические подробности и не используя специализированных технических терминов. Они должны быть понятны каждому. Слово "Основные" означает месяцы напряженного труда. Укажите также приблизительное время на выполнение задачи, соотнесенное с вашими финансовыми и человеческими ресурсами. Например: 
Парсер скриптов искусственного интеллекта: три-четыре месяца, два программиста. Парсер просматривает и компилирует скрипты AI в инструкции и простые логические цепочки, обрабатываемые во время выполнения программы. 
Риски: Опишите технические риски. Если никаких "рискованных действий" и последствий от них в данный момент не предвидится, обязательно так и напишите в документе. Под понятием "риск" мы понимаем любой аспект работы над проектом, который может повлечь за собой существенную (недели и месяцы) задержку работы над проектом. Учтите технологии, с которыми вы и ваша компания никогда не работали прежде, либо имеют мало опыта. Это может быть и 3D-моделирование, если вы впервые сталкиваетесь с ним. Запишите в список и любую задачу из списка основных, если вы чувствуете, что они могут повлечь какие-нибудь проблемы. Все неопробованные решения (трехмерные движки, программные утилиты, библиотеки, API, драйвера, и так далее) должны быть внесены в "группу риска", так как любая проблема с ними может вызвать замедление работ над проектом. Кроме того, ваши ожидания, возложенные на них, могут оказаться обманутыми. Сюда же входит и любая работа, выполняемая третьей стороной по контракту, так как это всегда большой риск. После составления списка рисков прикиньте, сколько времени займет "работа над ошибками", на сколько недель отодвинется дата релиза. Не забудьте о новых тратах (люди, программное обеспечение, и так далее), необходимых на решение этих проблем. Этот раздел документации - самый пессимистичный из всех, но зато он успокаивает читателя, создавая чувство уверенности в том, что проект полностью находится под вашим контролем, и ни одна, даже самая мелкая деталь, не укрылась от вашего взора. Кроме того, если начальство проигнорировало указанную вами проблему, в результате чего страдает проект, вы всегда можете сказать: "Помните? Я же вас предупреждал". 
Альтернативные пути: Это способы преодоления проблемных ситуаций, если таковые появятся. Список альтернативных подходов и способов, описывающих пути обхода "подводных камней", всегда оставляет у читателя чувство выбора. Сюда можно вписать и фичи, которые стоят дороже или отнимают больше времени при создании, но которые выглядят лучше (или наоборот - в альтернативные можно записать более дешевые варианты). В любом случае, не забудьте упомянуть о плюсах и минусах всего того, что вы предлагаете. 
Предполагаемые ресурсы: Перечислите все ресурсы, которые вам понадобятся: люди, "железо", программное обеспечение, и т.д. Для людей определите примерное время работы над проектом, выразите его в месяцах и годах. Не пишите пока цифры зарплат, это надо будет сделать позже. 
Предполагаемое расписание: Длительность производственного цикла, с указанием промежуточных задач, включая даты начала работ, время выпуска альфа-, бета-, и финальной версий. 
Правовой анализ (если требуется): Если в игре требуется использование чужих торговых марок, или она затрагивает сторонние авторские права, требующие выплат или отчислений, обязательно укажите их в документации. На данном этапе можно не заботиться об авторских правах на вашу собственную игру, ее название и логотип, так как в процессе работы они могут измениться. 
Стоимость и доходы от проекта: Этот документ должен быть составлен при участии финансового отдела и отдела сбыта. В нем указываются примерные расходы по созданию игры, основанные на технической оценке проекта. 
Стоимость ресурсов: Эта статья расходов рассчитывается на основе технического анализа проекта. Оплата труда работникам рассчитывается, исходя из оклада и премиальных, которые выделяются в финансовом отделе. Можно составить примерный список выплат. Также включите в статью расходов программное обеспечение и компьютеры, которые потребуется приобрести по ходу проекта. 
Дополнительные расходы: Эта статья содержит выплаты по авторским правам и прочие отчисления, связанные со сторонними контрактами, дополнительными исследованиями, и т.д. 
Рекомендованная розничная цена: Укажите предполагаемую цену до того, как ваша игра попадет в раздел уцененных товаров в магазине (конечно, лучше ей туда не попадать). Цена должна быть основана на анализе рынка сходных игр с учетом затрат на производство продукта. Как правило, дистрибьюторы стремятся занизить стоимость игры (даже если вы и так выставили крайне низкую цену). Помните, что чем выше розничная цена, тем ниже будут продажи, особенно на рынке популярного жанра, где конкуренция между игровыми проектами очень высока. 
Оценка прибыли: Статья доходов должна состоять из трех частей: пессимистичной оценки, ожидаемой оценки, и оптимистичной оценки прибыли. Оценка прибыли зависит от затрат на проект (которые вы уже учли ранее), и рассчитывается с учетом рекомендованной розничной цены. Доходы лучше всего представлять в виде графиков, желательно также указывать размер дополнительных расходов, вызванных теми или иными рисками, описанными в технической оценке проекта. Соответственно, итоговый график будет включать цифры как с учетом, так и без учета потерь.

Графическое оформление, концепт-арты: Если ваше описание идеи игры не включало раздела о графике, то план проекта должен обязательно составляться с учетом этой составляющей. Для разработки графики нанимаются профессиональные художники. Если же документ с идеей игры включал какие-то графические работы, созданные непрофессионально, в план проекта их лучше не включать, либо заменить другими. Графическое оформление- это то, что определяет настрой игры, придает целостность ее идее и наполняет ее смыслом. Считайте, что люди должны понять принцип игры, только посмотрев на ее оформление, и создавайте графику исходя из этого. Включите в документацию изображения юнитов, оружия, зданий в черно-белом исполнении и в цвете. Можно создать и "рисованный скриншот". Если вы создаете симулятор, обязательно приведите пример чертежа кокпита. Оформите ваш документ графикой из игры - это придаст ему неповторимость и произведет впечатление на читателя. 
Подача материала: Вся документация по плану проекта, включая переработанное описание идеи, должно быть распечатано на качественной бумаге и подшито в папку вместе с примерами графического оформления игры и концепт-артами. Помните, что этот документ будут читать серьезные бизнесмены - те самые люди из вашего офиса, которые носят дорогие костюмы, а не футболку и джинсы, как вы. Вы собираетесь предложить этим людям вложить в вашу идею большие деньги, так что пусть воплощение вашей идеи на бумаге выглядит достойно. Если вы планируете лично присутствовать на бизнес-встрече, не забудьте надеть ваш лучший костюм и галстук. Неплохо также будет подготовить презентацию и слайд-шоу.

Общие ошибки 
Перечислим ошибки, которые обычно допускают при создании плана проекта:

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

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

План проекта не вызывает заинтересованности. Определите, что именно не так в вашем проекте - возможно, он вторичен, либо слишком дорог, либо слишком сложен. Нужно учитывать все эти факторы до того, как вы напишете план проекта, а не после того, как вам было отказано.

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

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

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