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

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

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

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

Функциональная спецификация (functional specification, оригинал толкования - http://webopedia.internet.com/TERM/f/functional_specification.html): 
Формальное описание программного продукта, которое используется в качестве плана при создании программы. В минимальном виде функциональная спецификация должна четко определить цель создания продукта (его функцию). В зависимости от используемого методологического подхода функциональная спецификация также может включать в себя описание подходов к реализации, таких как, например, способы деления программы на модули или взаимодействие между частями программы. Также функциональная спецификация часто описывает программное обеспечение с точки зрения пользователя, а именно - как выглядит интерфейс и каким образом пользователь может использовать программу для выполнения определенных действий.
Если говорить короче, то функциональное описание игры - это те элементы, которые войдут в игру, и то, что они в ней делают. Эта часть дизайн-документа всегда составляется как бы со стороны игрока, выражая точку зрения пользователя продукта. То, как элементы воплощены в игре и как они функционируют - это предмет описания в технической спецификации. Она отличается от функциональной спецификации своей направленностью, описывая игру с точки зрения ее системы, включая методы и способы реализации. Помните, что написание обеих спецификаций - важные шаги в производственном процессе, которые обязательно должны быть зафиксированы в графике выполнения работ по проекту.

Правила написания хорошей функциональной спецификации

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

Функциональная спецификация может состоять из следующих частей: 
Принципы игры 
Интерфейс пользователя 
Графика и видео 
Звуки и музыка 
Сюжет (если требуется) 
Описание уровней

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

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

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

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

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

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

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

Многопользовательский режим (если требуется): Если дизайн вашей игры подразумевает многопользовательский режим (deathmatch, кооперативный режим, hot-seat или другой), опишите их и уточните, сколько игроков этот режим должен поддерживать. Укажите, какие типы связи для мультиплеера должны использоваться - модем, LAN, Интернет, и т.д. Опишите, каким образом многопользовательский режим отличается от одиночной игры в плане процесса, персонажей/юнитов, AI и прочих игровых элементов.

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

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

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

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

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

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

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

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

Графика внутриигрового мира: текстуры, фоны, объекты мира, и проч. 
Элементы геймплея: анимация игрока и его оппонентов (спрайты и модели), оружие, графика для обозначения повреждений объектов и т.д.

Спецэффекты: взрывы, пятна крови, обломки разрушенных предметов, следы, трассеры выстрелов, вспышки света.

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

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

Видео: Это самый маленький раздел, относящийся к графике, если, конечно, вы не создаете игру, полностью основанную на "живых" съемках (вроде игр American Laser Games). Любое видео, задействованное в игре, должно быть описано здесь. Для него также потребуется сценарий, который создается на более поздней стадии проекта. Здесь же опишите общую цель видеороликов, их смысл, количество актеров и желательные декорации, даже если будете снимать их перед синим экраном.

Звук и музыка 
Общее описание: Подчеркните эстетическую ценность и техническую цель звукового и музыкального сопровождения игры. Опишите желаемые музыкальные темы и атмосферу, которую они должно создавать. Укажите игры или фильмы со схожим музыкальным оформлением. Опишите технические детали, такие как: частота дискретизации, ограничение по размеру файлов, формат музыки, и прочее. 
Звуковые эффекты: Укажите все звуковые эффекты вашей игры, объясните, где они должны быть использованы. Можно также указать названия конкретных файлов, но перед этим не забудьте проконсультироваться у ведущего программиста насчет правильного именования. Список файлов в дальнейшем будет служить хорошим подспорьем, если вам срочно придется что-нибудь найти или изменить. 
Не забудьте описать все игровые моменты, требующие звукового сопровождения. Соотнесите звук с описанием игровых элементов. Вот примерный список: 
Интерфейс пользователя: нажатия на кнопки, открытие окон, реакция на команды 
Спецэффекты: ведение огня, взрывы, звуки радара 
Юниты/Персонажи: голос, переговоры по радио, звуки шагов. 
Элементы геймплея: звуки при взаимодействии с объектами, предупреждения, фоновый звук 
Звуки игрового мира: пение птиц, крики животных, шум листвы, прибоя, и т.д. 
Прочие звуки: ветер, звуки шагов, скрип пола.

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

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

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

График введения новых объектов: График, описывающий, какие игровые объекты должны появляться по мере развития сюжета или перехода игрока на следующие уровни. Говоря об объектах, мы подразумеваем новые типы врагов, ловушки, оружие, здания и прочие игровые элементы. График обеспечивает поддержание интереса у игрока стимул к игре (например, поиск нового оружия), а также сбалансированное расположение элементов по уровням. 
График представляет собой список из элементов, которому в соответствие ставится время/уровень, на котором они появляются в игре. Иногда также требуется указывать момент, когда использование элемента в дальнейшем запрещено, дабы не нарушить логику уровней или всей игры.

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

Общие ошибки 
Перечислим общие ошибки, которых следует избегать:

Недостаточность описания: Ваша документация должна быть достаточно конкретной, чтобы донести функциональные особенности вашей игры до читателя. Избегайте размытых описаний и неясных терминов, если только это не необходимо. 
Материал написан в снисходительной форме:
 не надо указывать художникам, какие особенности использования 256-цветной палитры им следует учитывать, и также не надо объяснять программистам, как определять структуры данных. Каждый должен заниматься своим делом - описывайте лишь те факты, которые важны для видения игры. Углубляясь в специфические детали, вы будете только раздражать специалистов и напрасно отнимать у них время. Вы также потратите кучу времени на написание того, что они и так знают. Эти детали в любом случае будут включены в технической спецификации проекта.

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

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

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

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

Правила написания хорошей технической спецификации

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

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

Платформа и ОС: Укажите операционную систему и предпочтительную платформу реализации. Для различных платформ (PC/Mac) укажите системные требования, как минимальные, так и предпочтительные. Если игра распространяется на нестандартном носителе (картридж, например), укажите его.

Код, предоставленный сторонним разработчиком: Укажите источник и смысл использования стороннего кода в вашей игре. Сюда включаются драйвера, сторонние 3D API, библиотеки вроде DirectX, и проч. 
Объекты кода:
 Разделите весь код на части, обслуживающие различные игровые элементы. Дайте детальное описание для каждой части.

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

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

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

Искусственный Интеллект: Его часто считают одной из самых важных частей игры, его алгоритмы непомерно разрастаются, и искусственный интеллект приходится урезать из-за несоответствия проекту или потому, что команда просто не успевает его реализовать. Как правило, команда преисполнена энтузиазма по отношению к ИИ в начале проекта, но недостаток финансирования и времени отрезвляет сотрудников и напоминает о том, что это должна быть простая симуляция разума. А ее можно выразить при помощи скриптов, не вдаваясь в тонкости нейронных сетей, персептронов, и прочих сложностей. Помните об этом, когда описываете AI своей игры. Постарайтесь просто выполнить требования функциональной спецификации, избегая излишнего и часто ненужного реализма. Здесь в очередной раз надо упомянуть об основном правиле производства: если есть что-то, что работает, и оно стоит меньше всех других аналогов и занимает меньше времени на разработку, именно это стоит использовать. 
Конечно, из любого правила существуют исключения. Иногда целесообразно потратить больше времени на создание чего-то более сложного при условии, что это сохранит время в дальнейшем (например, дизайнерам при создании уровней). Кроме того, некие специфические утилиты, которые вы создали при работе над вашей игрой, могут послужить компании в других проектах. В любом случае, какое бы решение вы ни приняли, его лучше сначала обсудить с продюсером или начальником технического отдела. 
Четко следуйте указаниям, записанным в функциональной спецификации. Возможно, вам потребуется создание скриптового языка или описать искусственный интеллект при помощи набора переменных. Если в ней требуется включить модули AI непосредственно в код игры, так и сделайте. 
Искусственный интеллект в общем случае должен выполнять задачи поиска путей, определять цели, реагировать на действия игрока, а также принимать другие решения, командовать юнитами, или контролировать состояние игровых объектов с учетом каких-то факторов. 
Ни в коем случае не включайте в техническое описание тексты скриптов или алгоритмы ИИ. Это относится к стадии непосредственной работы над проектом. Просто будьте точны в определениях действий и поведения искусственного интеллекта. Укажите также факторы (возможно, статистические), которые влияют на него.

Мультиплеер: Эта часть документа также очень важна. Создание игры должно быть рассмотрено с "многопользовательской" точки зрения. Эта подглава должна описать все изменения в игре и специфичные требования к проекту, задокументированные в функциональной спецификации. 
Мультиплеер на РС (в отличие от консольных вариантов) подразумевает большое количество специфичных требований, которые должны быть обязательно приняты во внимание. Какие способы соединения компьютеров вы используете? Какая у вас архитектура - клиент-сервер или точка-точка? Каковы размеры пакетов и с какой скоростью они пересылаются? Какова структура пакета? Что делать для уменьшения лагов в сети? Какие запросы будут широковещательными, и какие посылать на определенные хосты? Сколько всего будет типов запросов и когда они используются?

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

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

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

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

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

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

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

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

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

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

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

Шаг 1. Эскиз и Дискуссия 
Дизайнер уровней придумывает схему уровня, который отвечает требованиям функциональной спецификации и содержит все необходимые игровые элементы (в соответствии с графиком введения новых объектов). Затем он создает небольшой эскиз и представляет его главному дизайнеру. Эскиз может быть выполнен в любой форме. Он не должен представлять все идеи, которые присущи данному уровню, так как все равно он подвергнется изменениям в процессе обсуждения. 
Преимущество создания и обсуждения эскизов перед детальной проработкой уровня состоит в том, что этим вы экономите время. Главный дизайнер, имея перед глазами рисунок, сможет в течение нескольких минут определить, войдет ли ваш уровень в игру, есть ли у него потенциал, и если да, то он укажет, какие поправки необходимо будет внести в игру. Полностью проработанный и задокументированный уровень требует дней работы, а возможно и несколько недель. Главному дизайнеру может не понравиться законченный вариант, над которым автор корпел неделю. Это особенно характерно для начала проекта, пока главный дизайнер определяет "политику" работы над уровнями, и в конце работ, когда оригинальные уровни отвергаются как несоответствующие духу уже почти готовой игры.

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

Шаг 3. Создание "сердца" уровня 
Дизайнеры должны определить ход игры на уровне. Они должны привести его в вид, наиболее полно выражающий идею, заложенную в описании. Дизайн уровня должен привлекать игрока, на нем должно быть интересно находиться и жить - иначе зачем еще было его создавать? Дизайнер должен в очередной раз обратиться к вышестоящему начальству, чтобы получить реакцию на свою работу. Главный дизайнер определит, есть ли у этого уровня достоинства или нет. Кстати, готовый уровень может вообще не соответствовать требованиям, предъявленным в документации на него, будьте к этому готовы. Вообще, вы удивитесь, сколько времени вам сохранит тесное общение с начальством - вы всегда будете знать, что делать в каждый конкретный момент времени, и какая судьба ожидает ваш уровень.

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

Шаг 5: Тест 
Попросите дизайнеров сыграть на готовых уровнях, и потом задокументировать все недостатки, ошибки, и пожелания по ним. Документация на этом этапе также играет важную роль. Очень легко упустить проблемы из вида, если вы не уделяете достаточного внимания их отслеживанию, так что составьте базу данных по всем встреченным багам на всех уровнях игры.

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

Фаза создания идеи 
Документ: Идея Игры 
Документ: План Игры

Фаза дизайна 
Документ: Функциональная спецификация 
Документ: Техническая спецификация 
Документ: Спецификация программных средств разработки (инструменты и утилиты)

Фаза разработки 
Создание графика работ 
Технологическая демо-версия 
Первый играбельный уровень 
Документ: "Бумажный" вариант уровней 
Альфа-версия - основной технологический процесс создания закончен

Фаза тестирования 
Бета-версия - кандидат на релиз 
Золотая мастер-копия - релиз-версия 
Возможно, вы сможете добавить сюда больше шагов, так как основной контроль над проектом, конечно же, не ограничивается перечисленными пунктами. Иногда менеджеры устанавливают отдельные "отрезки" времени на создание конкретных частей игры (кода или конкретных уровней). Те пункты, что мы привели здесь - самые общие и свойственны любому проекту.

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