Миф о Геймдизайн Документе

Многие начинающие геймдизайнеры и другие мечтатели имеют очень интересное представление о том, как работает процесс создания игры. Не имея ни единого представления о Правиле Цикла, они уверены в том, что для дизайна игры требуется гениальный геймдизайнер, который сидит в одиночестве перед клавиатурой и печатает свой гениальный Геймдизайн Документ (ГДД). Когда этот шедевр подойдет к завершению, нужно будет только передать его команде умелых художников и программистов, и ждать, пока они воплотят это революционное видение в жизнь. “Если бы только”, подумает расстроенный потенциальный геймдизайнер, “я мог узнать правильный формат ГДД, я бы тоже мог стать профессиональным геймдизайнером! У меня полно идей - но без этого волшебного шаблона я никогда не смогу делать игры”.

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

ВОЛШЕБНОГО ШАБЛОНА НЕ СУЩЕСТВУЕТ!

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

Для чего нужны документы

Дизайн документы выполняют два предназначения: памятьи коммуникация.

Память

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

Коммуникация

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

Типы игровых документов

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

Рис. 24.1

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

Design

1 Game Design Overview(Обзор дизайна игры).Документ, описывающий основные цели и особенности игры, который может занимать всего несколько страниц. Этот документ обычно пишется для начальства команды, чтобы те, не углубляясь в детали, могли понять, что представляет собой ваша игра, и для кого она предназначена. Обзорный документ может быть полезен и для всей остальной команды, потому что помогает им представить полную картину игры.

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

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

Engineering

1 Technical Design Document(Технический дизайн документ). Часто видеоигра включает в себя множество сложных систем, не имеющих ничего общего с механикой, но отвечающих за появление определенных элементов на экране, отправку информации по сетям и за другие исключительно технические моменты. Обычно никто вне команды программистов не думает об этих деталях, но если ваша инженерная команда состоит из более чем одного человека, будет полезно отмечать все эти моменты в одном документе, так, чтобы когда к команде присоединялись другие люди, они сразу понимали, что и как должно работать. Так же, как и Рабочий проект, этот документ редко дописывают до конца, но его написание крайне важно для того, чтобы держать под контролем всю программную составляющую игры.

2 Pipeline Overview. Большая часть сложностей, сопряженных с программированием игры, связана с правильной интеграцией элементов арта в игру. Существует множество “можно и нельзя”, которым должны следовать художники, если они хотят, чтобы их арт правильно отображался в игре. Этот документ обычно составляется инженерной командой специально для художников, и чем проще он написан, тем лучше.

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

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

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

Management

1 Game Budget(Бюджет игры). Как бы сильно нам ни хотелось просто “работать над проектом от начала до конца”, экономическая реальность игрового бизнеса редко позволяет нам это делать. Обычно от команды требуется определиться со стоимостью разработки еще до того, как они будут полностью понимать, нам чем им придется работать. Стоимость проекта зачастую определяется посредством документа: часто это таблица, предназначенная для систематизации рабочего процесса по созданию игры. Данная таблица заполняется оценками сроков, которые переводятся в доллары. Продюсер или проект менеджер не могут сами высчитать эти цифры, поэтому им нужно поработать отдельно с каждой частью команды, чтобы максимально точно провести расчеты. Часто этот документ пишется одним из первых, поскольку без него трудно будет получить финансирование проекта. Хороший проект менеджер должен работать с этим документом на протяжении всего проекта, чтобы быть уверенным в том, что проект не выходит за границы того бюджета, который был озвучен.

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

Writing

1 Story Bible(Библия истории). Можно подумать, что история в игре определяется исключительно писателями (если таковые имеются), которые работают над проектом, но часто бывает так, что каждый из членов команды вносит осмысленные изменения в сюжет. Разработчику движка может показаться, что определенный элемент истории будет слишком сложно реализовать в техническом плане, и в связи с этим он может внести предложение об изменении этого элемента. У художника может быть интересная визуальная идея для абсолютно новой части истории, которую писатель даже не мог себе представить. У геймдизайнера может появиться новая идея для концепта геймплея, которая может потребовать изменения истории. Библия истории, в которой четко описывается все, что возможно, и что невозможно в мире вашей игры, упрощает задачу для тех членов команды, которые хотят внести свой вклад в игру, и, в итоге, помогает создать сильный сюжет, который будет хорошо интегрирован с артом, технологией и геймплеем.

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

3 Game Turotial and Manual(Учебные пособия к игре). Видеоигры бывают сложными, и игрокам нужно как-то учиться в них играть. Внутриигровое обучение, интернет страницы и печатные учебные пособия - самые распространенные средства обучения. Текст этих пособий очень важен - если игроки не могут понять вашу игру, тогда как они смогут получать от нее удовольствие? Детали дизайна вашей игры скорее всего будут меняться, вплоть до последнего момента разработки, поэтому важно быть уверенным в том, что кто-то постоянно проверяет этот текст и вносит в него все актуальные правки.

Игроки

1 Game Walkthrough(Прохождение игры). Разработчики - не единственные, кто пишет документы об игре! Если игрокам нравится ваша игра, они будут писать свои собственные документы и выкладывать их для открытого чтения. Если вы будете изучать то, что ваши игроки пишут о вашей игре, вы сможете узнать в деталях, что им нравится, а что - нет, какие части игры слишком сложные, а какие слишком простые. Конечно, к тому времени, когда игроки напишут прохождение, уже, скорее всего, будет поздно что-то менять, но, по крайней мере, вам это может пригодиться в следующий раз!

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