Разыскиваемый: хороший дизайн-документ.
В первую очередь необходимо определиться с тем, кого мы ищем и кто подозреваемые. Общим термином «дизайн-документ» называют иногда три достаточно разных вида документов и их всевозможные комбинации:
- Концепция;
- Функциональное описание игры;
- Технические спецификации;
- Технические спецификации;
Среди этих подозреваемых необходимо провести опознание.
Концепция создается в самом начале разработки игры, в период preproduction.
- Цель: дать четкое представление, что мы хотим получить и в чем заключается основная «фишка» игры. На этом этапе следует определиться, что представляет собой проект — симулятор жизни бактерии или космическая опера на пяти CD-дисках. Важно также помнить о том, что для будущих читателей это должно быть интересное чтиво;
- Для кого: для всех — разработчиков, издателя, продюсера. Концепция позволяет всем заинтересованным лицам постоянно фокусироваться на правильном понимании идеи игры;
- Содержит: основную идею. Соответственно, любая правка этого документа изменяет ее. Чем позже от начала разработки вносятся изменения, тем более значимые трансформации они вызывают во всем проекте;
- Кем создается: коллективным разумом разработчиков. Если издатель внесет свой вклад, это гарантирует маркетинговую состоятельность проекта;
- Особые приметы: небольшой объем, отвечающий на основные вопросы «что?» и «для кого?»;
Функциональное описание является детальной проработкой идеи игры и содержит, фактически, самое подробное описание конечного продукта с точки зрения игрока (!). Проще говоря, это значительно расширенное описание концепции.
- Цель: зафиксировать структурированное и согласованное описание всего того, что игрок может увидеть в игре и что, собственно, будет разрабатываться. Здесь, подключив некоторое воображение, можно «поиграть» в несуществующую пока игру. Насколько это будет интересно и цельно — во многом определяет судьбу проекта. Функциональное описание является основанием для составления плана разработки;
- Для кого: для всех — разработчиков, издателя, продюсера. В будущем «легким движением руки» из него может быть составлен мануал для пользователя;
- Содержит: игру «на бумаге». Описание всех элементов игры: принципы, интерфейс, персонажи, предметы, оружие, скиллы, физика, графика, звуковое наполнение, уровни, а также все концепт-арты к этим элементам (может быть в виде приложения, конечно). Изменения в этом документе существенно влияют на разработку, но они, как правило, неизбежны;
- Кем создается: главным дизайнером игры с участием заинтересованных лиц;
- Особые приметы: существенный объем (а кто сейчас делает простые игры?), рисунки, номенклатура, таблицы, формулы, чертежи;
Технические спецификации являются уже частью самой разработки проекта, описанием воплощения видения в код, графику и звук.
- Цель: отразить реализацию всех заложенных в концепции и функциональном описании положений, задокументировать принятые программные и творческие решения;
- Для кого: в первую очередь этот документ необходим самим разработчикам и художникам для выполнения конкретных работ. Некоторые части этой документации могут быть интересны и для издателя;
- Содержит: руководства к действию по кодированию тех или иных компонентов игры, моделированию и текстурированию персонажей и объектов. Создание и изменение этого документа идет непрерывно, отражая, собственно, сам ход разработки;
- Кем создается: главным программистом и главным художником при содействии коллектива;
- Особые приметы: существенный объем, распределенный в нескольких документах, диаграммы классов или переменных и функций, скетчи конкретных объектов;
Замечательная во всех отношениях статья, ссылка на которую была приведена выше, содержит одно спорное мнение, которое я не поддерживаю. Полные технические спецификации не могут и не должны быть частью дизайн документа, предоставляемого разработчиком при обсуждении контракта. Их создание может происходить во время всего цикла разработки до самого завершения проекта и является одним из видов работ. В чем я горячо согласен с автором статьи, так это в том, что игнорирование разработчиком таких спецификаций вызовет у него самого массу проблем.
После проведенного опознания, наше следствие обнаружило, что за всеми этими подозреваемыми стоит, как оказалось, одна очень влиятельная фигура, а именно - план разработки игры.
План разработки игры дает видение процесса воплощения идей в продукт и показывает, насколько эта дорога трудна.
- Цель: определить что, когда, кем и с помощью чего будет разработано, и во что это выливается в необходимых затратах;
- Для кого: для лиц, принимающих решения. Разработчику здесь уже видно, какая нужна команда для реализации этого проекта и как долго она будет трудиться. И, конечно, эта информация является одним их основных предметов обсуждения издателя и разработчика;
- Содержит: план разработки проекта: задачи, ресурсы, риски, календарный план;
- Кем создается: менеджером проекта (при участии ключевых лиц) в результате обсуждения возможностей и потребностей проекта;
- Особые приметы: небольшой объем с очень важной информацией. Слова «объемы работ», «недели», «месяцы», значки «$»;
Пора подвести некоторые итоги. В результате дедуктивного анализа наша следственная группа пришла к следующему выводу. Разыскиваемый и есть ничто иное, как «организованная совокупность» нужных документов, и содержит:
- Концепцию;
- Функциональное описание;
- Описание основных технических решений — основа для составления последующих технических спецификаций;
- План игры;
В своей работе мы достаточно успешно используем «джентльменский набор» шаблонов и примеров этих документов, которым я с удовольствием могу поделиться с вами. Взять его можно здесь: http://games.1c.ru/4_files/desdocpack.zip или http://art4art.kiev.ua/files/desdocpack.zip
Там вы найдете, собственно, разыскиваемого (desdocexample.doc) — изучайте на здоровье! Он немного небрит, слегка хромает, сверкает страшным глазом, но в целом подходит под наше понимание «хороший дизайн-документ». Спорная рыночная ценность самой игры, описанной в этом документе, не должна вас смущать.
Там же вы найдете и «отпечатки пальцев» — шаблон для создания дизайн-документов ваших замечательных игр (desdoctemplate.doc). Не стесняйтесь, это не будет плагиатом — нам просто удобнее будет читать. А индивидуальность — она не в форме, а в содержании.
И, конечно же, обратите внимание на примеры концепт-документа (не самый короткий и емкий в мире, зато бесплатно!) и плана разработки.
Источник: http://dtf.ru/articles/read.php?id=1491