Команда общается посредством документации

 

Миф о геймдизайн‑документе

 

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

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

 

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

 

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

 

«Проблема ГДД заключается в том, что он устаревает уже тогда, когда вы только начинаете его писать. Проектная документация отражает вашу текущую теорию о том, что сделает вашу игру хорошей… но пока вы не увидите, как эти теории работают на практике, вы не можете знать наверняка. К сожалению, мы слишком часто относимся к формальным документам как к спецификациям, техническим заданиям или чертежам. Но это не так – они представляют собой простые теории. Хуже всего, когда одни воспринимают ваш документ как план, другие – как теории, а третьи – как чертеж вашей игры. Небольшие команды могут преодолеть эту проблему частым общением… но в больших командах дела обстоят гораздо сложнее».

 

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

 

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

 

Проектная документация выполняет два основных предназначения: хранение и передачу информации.

 

Хранение

 

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

 

Передача

 

Даже если Бог наградил вас феноменальной памятью, решениями по поводу дизайна вашей игры нужно делиться со всеми остальными людьми в команде. Документы – эффективный способ сделать это. И эта коммуникация, как мы уже говорили в главе 25 «Команда», не будет односторонней. Это станет диалогом: как только ваши решения появятся на бумаге, кто‑то найдет в них ошибки или предложит пути улучшения дизайна. При помощи документа можно привлечь к дизайну больше людей, что позволит вам быстрее находить и исправлять его слабые стороны. Доступ к этим документам необходим многим людям. Это объясняет, почему «Google‑документы» стали популярным методом ведения дизайнерской документации.

 

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

 

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

 

 

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

 

Дизайн

 

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

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

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

 

Технологии

 

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

5. Пайплайн‑документация (англ. Pipeline overview). Большая часть сложностей, сопряженных с разработкой игры, связана с правильной интеграцией графических элементов. Существует множество правил, которым должны следовать художники, если они хотят, чтобы их графика корректно отображался в игре. Обычно этот документ составляется инженерной командой специально для художников, и чем проще он написан, тем лучше.

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

 

Графика

 

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

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

 

Разработка

 

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

10. Список ресурсов (англ. Asset tracker). Независимо от того, в каком виде вы представите этот документ – простой таблицей или более формально, – он должен отслеживать, какое количество контента было создано и в каком состоянии находятся материалы, над которыми команда еще работает. Сюда относится код, графика, уровни, звуки, музыка и дизайн‑документы.

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

 

История

 

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

13. Сценарий (англ. Script). Если неигровые персонажи (от англ. Non‑Player Character, NPC) в вашей игре будут разговаривать, их диалоги должны быть где‑то прописаны! Для этого нужен сценарий, который может быть как отдельным документом, так и дополнением к ГДД. Очень важно, чтобы геймдизайнер лично проверял все диалоги: существует высокая вероятность того, что некоторые реплики могут противоречить правилам игры.

14. Учебные пособия к игре (англ. Game tutorial and manual). В сложных видеоиграх игрокам необходимо обучение. Интерактивные инструкции в самой игре, интернет‑форумы и печатные руководства – самые распространенные средства обучения. Крайне важно содержание этих обучающих материалов: игроки не смогут получить удовольствие от игры, которую не понимают. Скорее всего, детали дизайна вашей игры будут меняться вплоть до последнего момента разработки. Убедитесь, что кто‑то в вашей команде постоянно проверяет содержимое учебных пособий и поддерживает их в актуальном состоянии.

 

Аудитория

 

15. Прохождение игры (англ. Game walth‑through). Разработчики – не единственные, кто пишет документы об игре! Если игрокам нравится ваша игра, они будут писать собственные документы и выкладывать их в сеть. Изучая эти тексты, вы сможете в подробностях узнать, что им нравится, а что – нет, какие части игры слишком сложные, а какие слишком простые. Конечно, к тому времени, когда игроки напишут прохождение, скорее всего, будет уже поздно что‑то менять, но вы можете использовать полученную информацию в следующий раз!

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

 

Итак, откуда мне начинать?

 

Начинать просто. Так же просто, как приступить к созданию дизайна игры. Начните с документа, который станет кратким списком идей, пригодных для использования в вашей игре. По мере расширения списка в вашей голове начнут возникать вопросы по поводу дизайна – это очень важные вопросы! Записывайте их, чтобы не забыть! «Работа над собственным дизайном» в основном заключается в поиске ответов на эти вопросы, поэтому вам лучше помнить каждый из них. Всегда, когда отвечаете на какой‑либо вопрос и ответ вас устраивает, отметьте себе это решение и причину, по которой вы решили именно так. Постепенно ваш список идей, планов, вопросов и ответов будет увеличиваться и сам по себе начнет делиться на секции. Записывайте все, что вам нужно помнить, и все, что нужно донести до остальных членов команды. Сами того не замечая, вы получите полноценный дизайн‑документ – не тот, который основан на несуществующем волшебном шаблоне, а тот, который появится естественным образом вокруг уникального дизайна вашей уникальной игры.