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

[Freezze 1,445]

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

i

Тим Райан (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, драйвера, и так далее) должны быть внесены в "группу риска", так как любая проблема с ними может вызвать замедление работ над проектом. Кроме того, ваши ожидания, возложенные на них, могут оказаться обманутыми. Сюда же входит и любая работа, выполняемая третьей стороной по контракту, так как это всегда большой риск. После составления списка рисков прикиньте, сколько времени займет "работа над ошибками", на сколько недель отодвинется дата релиза. Не забудьте о новых тратах (люди, программное обеспечение, и так далее), необходимых на решение этих проблем. Этот раздел документации - самый пессимистичный из всех, но зато он успокаивает читателя, создавая чувство уверенности в том, что проект полностью находится под вашим контролем, и ни одна, даже самая мелкая деталь, не укрылась от вашего взора. Кроме того, если начальство проигнорировало указанную вами проблему, в результате чего страдает проект, вы всегда можете сказать: "Помните? Я же вас предупреждал".

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

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

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

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

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

Стоимость ресурсов: Эта статья расходов рассчитывается на основе технического анализа проекта. Оплата труда работникам рассчитывается, исходя из оклада и премиальных, которые выделяются в финансовом отделе. Можно составить примерный список выплат. Также включите в статью расходов программное обеспечение и компьютеры, которые потребуется приобрести по ходу проекта.

Дополнительные расходы: Эта статья содержит выплаты по авторским правам и прочие отчисления, связанные со сторонними контрактами, дополнительными исследованиями, и т.д.

Рекомендованная розничная цена: Укажите предполагаемую цену до того, как ваша игра попадет в раздел уцененных товаров в магазине (конечно, лучше ей туда не попадать). Цена должна быть основана на анализе рынка сходных игр с учетом затрат на производство продукта. Как правило, дистрибьюторы стремятся занизить стоимость игры (даже если вы и так выставили крайне низкую цену). Помните, что чем выше розничная цена, тем ниже будут продажи, особенно на рынке популярного жанра, где конкуренция между игровыми проектами очень высока.

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

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

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

Общие ошибки

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

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

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

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

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

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

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

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

[Cкрыть]

Часть вторая - 1Нажмите здесь!

 

Основы написания функциональной и технической спецификации

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

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

Функциональная и Техническая спецификация

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

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

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

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

Функциональная спецификация (functional specification, оригинал толкования

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

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

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

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

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

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

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

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

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

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

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

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

Функциональная спецификация может состоять из следующих частей:

Принципы игры

Интерфейс пользователя

Графика и видео

Звуки и музыка

Сюжет (если требуется)

Описание уровней

Принципы игры

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

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

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

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

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

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

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

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

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

Интерфейс пользователя

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

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

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

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

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

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

Графика и видео

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

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

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

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

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

Графика внутриигрового мира: текстуры, фоны, объекты мира, и проч.

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

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

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

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

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

Звук и музыка

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

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

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

Интерфейс пользователя: нажатия на кнопки, открытие окон, реакция на команды

Спецэффекты: ведение огня, взрывы, звуки радара

Юниты/Персонажи: голос, переговоры по радио, звуки шагов.

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

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

Прочие звуки: ветер, звуки шагов, скрип пола.

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

Сопровождение событий: удача/успех/победа/смерть

Сопровождение оболочки игры: музыка для начального экрана игры, титров, концовки

Уровни игры: музыка для различных уровней игры, выбирается дизайнером

Особые ситуации: создается для передачи общего настроя при бое, опасности, и проч

Саундтреки для видео-вставок

Сюжет (если требуется)

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

Описание уровней

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

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

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

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

Общие ошибки

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

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

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

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

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

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

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

[Cкрыть]

Часть вторая - 2Нажмите здесь!

 

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

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

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

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

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

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

Принципы Игры

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

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

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

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

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

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

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

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

Хранение данных: Опишите, как данные хранятся, загружаются, обрабатываются, сохраняются и восстанавливаются.

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

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

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

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

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

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

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

Мультиплеер: Эта часть документа также очень важна. Создание игры должно быть рассмотрено с "многопользовательской" точки зрения. Эта подглава должна описать все изменения в игре и специфичные требования к проекту, задокументированные в функциональной спецификации.

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

Интерфейс пользователя

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

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

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

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

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

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

Графика и видео

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

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

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

Звук и музыка

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

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

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

Общие ошибки

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

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

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

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

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

Шаг 1. Эскиз и Дискуссия

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

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

Шаг 2: Детали и Бумажное воплощение

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

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

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

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

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

Шаг 3. Создание "сердца" уровня

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

Шаг 4: Добавление деталей

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

Шаг 5: Тест

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

Важные шаги при создании документации, и график работ

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

Фаза создания идеи

Документ: Идея Игры

Документ: План Игры

Фаза дизайна

Документ: Функциональная спецификация

Документ: Техническая спецификация

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

Фаза разработки

Создание графика работ

Технологическая демо-версия

Первый играбельный уровень

Документ: "Бумажный" вариант уровней

Альфа-версия - основной технологический процесс создания закончен

Фаза тестирования

Бета-версия - кандидат на релиз

Золотая мастер-копия - релиз-версия

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

Неизбежные изменения

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

[Cкрыть]

Источник:

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

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

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

Изменено 11.07.2014, 18:01:18 пользователем Freezze

[alexandrovis 114]

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