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

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

Patrick Lencioni: The Advantage. Эта книга содержит всю необходимую информацию для организации командной работы.

Ken Birdwell: The Cabal: Valve’s Process of Creaing Half-Life. Лучшая статья о применении принципов командного геймдизайна, которую мне приходилось читать. http://www.gamasutra.com/view/feature/131815/ the_cabal_valves_design_process_.php.

Jesse Schell: Information Flow: The Secret to Studio Structure. Это была тема моего доклада на 2011 IGDA Leadership Summit. Она подробно раскрывает вопрос командной работы при разработке игр. http://www.design3.com/industry-insight/igda-leadershipforum-2011/item/2329-jesse-schell-keynote-information-flow-the-secret-tostudio-structure (https://www.youtube.com/watch?v=y92-vkyHKbY).

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

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

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

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

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

Хранение

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

Передача

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

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

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

Дизайн

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