Файл: В начале был дизайнер.pdf

360 больше возможностей быть вместе и общаться друг с другом, даже если это общение не связано с вашим проектом, ведь, чем больше члены вашей команды общаются (о чем угодно!), тем больше они узнают, можно ли друг другу доверять - именно поэтому так мало игровых студий предоставляют своим сотрудникам отдельные кабинеты - вместо этого их всех усаживают в просторные залы, где они просто обречены ежедневно общаться друг с другом лицом к лицу.
7 Честность. Так же, как комфорт зависит от уважения, а уважение зависит от доверия, доверие зависит от честности. Если вы каким-то образом получили репутацию нечестного человека в какой либо сфере, даже если она не связана с производством игр, другие будут бояться быть честными с вами, что нарушит командную коммуникацию. Геймдизайн иногда похож на политику, и вам наверняка иногда придется скрывать правду о некоторых вещах, но ваша команда всегда должна быть уверена в том, что они получают от вас правдивую информацию, иначе общение между членами вашей команды будет натянутым.
8 Приватность. Быть честным не всегда легко, потому что правда бывает болезненной. И несмотря на то, что мы все надеемся оставаться объективными в вопросах дизайна, иногда просто невозможно избежать проявления личной гордости и эго во время рабочего процесса. Говорить о таких вещах при всех бывает трудно, а, подчас, невозможно. Люди более склонны делиться своими переживаниями во время разговора с глазу на глаз, чем на людях. Старайтесь по возможности находить время для личных разговоров с каждым из членов дизайн команды - они с удовольствием поделятся с вами своими идеями и обсудят те проблемы, которые им неудобно обсуждать на людях. Эти разговоры с глазу на глаз также могут помочь вам расположить людей к себе и заслужить их доверие: больше доверия ведет к большему количеству честного общения, которое формирует больше доверия и т.д.
9 Единство. Во время процесса дизайна могут возникать многочисленные мнения и конфликты о том, что для игры правильно. Это вполне естественная ситуация.
Когда все заканчивается, команда обычно приходит к решению, которое устраивает всех. Помните: там, где есть два человека, может возникнуть несогласие. Если один из членов команды слишком сильно настаивает на определенном дизайн решении, вы должны относиться к нему с достаточным уважением, и работать с ним, пока не сможете прийти к осмысленному компромиссу. Спросите его, почему это решение настолько важное для него, и, возможно, благодаря его объяснению все остальные члены команды тоже поймут, почему оно настолько важное. Если с этим не получилось, лучше все просто спросить у этого человека: “Что мне нужно сделать, чтобы ты был в деле?”.
Возможно, у вас не получится сразу уладить вопрос с отличиями во мнении, но если чего-то и нельзя делать, так это игнорировать их. Так же, как один неработающий цилиндр может вдвое сократить производительность мотора и, в итоге, привести к поломке, так и один член команды, который не согласен с вашим дизайном, может ослабить всю команду или даже развалить ее. Последняя цель коммуникации - это единство.

361
Линза #89: Линза Команды
Чтобы убедиться в том, что ваша команда работает как хорошо налаженный механизм, спросите себя:
● Эта команда подходит для этого проекта? Почему?
● Командная коммуникация происходит объективно?
● Командная коммуникация происходит ясно?
● Членам команды удобно друг с другом?
● В команде преобладают настроения всеобщего доверия и уважения?
● Эта команда способна объединяться вокруг единых решений?
Дизайн и разработка игры - это сложные процессы. Если вы не имеете много талантов, а ваш проект не крошечный, вы не сможете сделать игру без команды. Люди намного важнее идей, потому что, как сказал Эд Кэтмул из Pixar, “Если вы дадите хорошую идею посредственной группе, они ее испортят. Если вы дадите посредственную идею хорошей группе, они ее исправят”.
Вы можете подумать, что все эти разговоры о командах не имеют ничего общего с дизайном - если другие люди в команде не хотят делать свою работу, то это не касается вас, как дизайнера. Отчасти, вы будет правы, но то, что происходит в команде, напрямую касается качества игры, над которой эта команда работает. Поскольку все, кто связан с игрой, имеют некоторое влияние на ее дизайн, вы должны объединить этих людей для достижения единой цели, если вы хотите, чтобы ваше замечательное видение игры когда-либо увидело свет.
Теперь, когда командная коммуникация налажена, кое-кому нужно начинать писать документы - и это будет темой нашей следующей главы.

362

363
Коммуникация
Даже если Бог и наградил вас феноменальной памятью, решениями по поводу дизайна вашей игры нужно делиться со всеми остальными людьми в команде. Документы
- это очень эффективный способ делать это. И эта коммуникация, как мы уже говорили в
Главе 23, не будет односторонней. Это будет диалог, потому что, как только ваши решения появляются на бумаге, кто-то находит в них ошибки или предлагает пути улучшения дизайна. Посредством документа можно привлечь к дизайну больше людей, что позволит вам быстрее находить и исправлять его слабости.
Типы игровых документов
Поскольку документы нужны для памяти и коммуникации, то дизайн документы, в частности, определены тем, что информацию нужно запомнить, и тем, что ее необходимо донести до остальных. Редко можно увидеть игру, где все необходимые предназначения выполняет один документ - обычно имеет смысл создать несколько различных видов документов. Есть три основных группы работников, которым необходимо помнить различные вещи, и уметь доносить их до своих коллег, и каждая из этих групп имеет свой собственный вид документов.
Рис. 24.1
На схеме вверху можно увидеть некоторые пути запоминания и коммуникации внутри геймдизайн-команды. Каждая стрелка могла бы быть документом или несколькими документами. Давайте подробнее рассмотрим каждую из групп, и узнаем, какие документы они могут создавать.
Design
1 Game Design Overview (Обзор дизайна игры). Документ, описывающий основные цели и особенности игры, который может занимать всего несколько страниц. Этот документ обычно пишется для начальства команды, чтобы те, не углубляясь в

364 детали, могли понять, что представляет собой ваша игра, и для кого она предназначена. Обзорный документ может быть полезен и для всей остальной команды, потому что помогает им представить полную картину игры.
2 Detailed Design Document (Рабочий проект). В этом документе детально описывается механика игры и ее интерфейс. Данный документ обычно выполняет две цели: позволяет дизайнеру помнить все мельчайшие идеи, которые приходят ему в голову, а также помогает ему передавать эти идеи программистам, которые должны писать по ним код, и художникам, которые должны заставить эти идеи хорошо выглядеть. Поскольку данный документ редко показывается людям, не связанным с проектом, он редко бывает упорядоченным. Достаточно того, что этот документ может разжечь дискуссию, и никому не даст забыть о важных деталях.
Это обычно самый длинный документ, который, кстати, редко кто доводит до ума.
На полпути к окончанию проекта, об этот документе часто забывают - к этому моменту сама игра содержит большинство важных деталей, а те, которых в игре еще нет, обычно распространяются между членами команды при помощи неформальных средств, таких как электронные письма или короткие записки.
3 Story Overview (Обзор истории). Во многих играх для написания основного повествования и диалогов нанимают профессиональных писателей. Эти писатели обычно работают удаленно, то есть находятся далеко от всей остальной команды.
Геймдизайнеру иногда бывает необходимо составить короткий документ, описывающий сеттинги, персонажей и действия, которые будут иметь место в игре. Бывает и такое, что писатели отвечают собственными интересными идеями, которые изменяют весь дизайн игры.
Engineering
1 Technical Design Document (Технический дизайн документ). Часто видеоигра включает в себя множество сложных систем, не имеющих ничего общего с механикой, но отвечающих за появление определенных элементов на экране, отправку информации по сетям и за другие исключительно технические моменты.
Обычно никто вне команды программистов не думает об этих деталях, но если ваша инженерная команда состоит из более чем одного человека, будет полезно отмечать все эти моменты в одном документе, так, чтобы когда к команде присоединялись другие люди, они сразу понимали, что и как должно работать.
Так же, как и Рабочий проект, этот документ редко дописывают до конца, но его написание крайне важно для того, чтобы держать под контролем всю программную составляющую игры.
2 Pipeline
Overview.
Большая часть сложностей, сопряженных с программированием игры, связана с правильной интеграцией элементов арта в игру. Существует множество “можно и нельзя”, которым должны следовать художники, если они хотят, чтобы их арт правильно отображался в игре. Этот документ обычно составляется инженерной командой специально для художников, и чем проще он написан, тем лучше.

365 3 System Limitations (Системные ограничения). Дизайнеры и художники часто не имеют ни малейшего представления о том, что возможно, а что невозможно в той системе, материал для которой они создают (или они просто притворяются). Для некоторых игр программисты создают специальные документы, в которых дают четкое представление о границах системы, которые нельзя пересекать - о количестве фигур, одновременно показанных на экране, количестве сообщений об обновлениях за секунду, количестве одновременных взрывов на экране и т.д.
Часто эта информация подается более детально, но если вы обозначите ее
(желательно, в письменном виде), это может впоследствии сохранить вам много времени, к тому же подобные документы могут положить начало дискуссиям, на которых часто находятся креативные решения, позволяющие выйти за эти границы.
4 Art Bible (Библия арта). Если несколько художников собираются работать над одной игрой, то для того, чтобы создать единый целостный вид этой игры, им нужна некая инструкция, по которой можно было бы следить за соблюдением этой целостности. Библия арта - это документ, который и является подобной инструкцией. Это могут быть листы с персонажами, примеры окружения, примеры использования цвета, примеры интерфейса, а также всё остальное, что определяет внешний вид каких-либо элементов игры.
5 Concept Art Overview (Обзор концепт-арта). В команде есть много людей, которые должны понимать, как будет выглядеть игра еще до того, как работа над проектом стартует. Это достигается посредством концепт-арта. Но одного арта недостаточно - лучше всего использовать его в дизайн документе, поэтому часто художники работают вместе с дизайнерами, чтобы определиться с набором изображений, по которому можно будет увидеть то, как весь арт будет выглядеть в контексте дизайна игры. Эти ранние изображения можно увидеть везде - в
Обзоре дизайна игры, в Рабочем проекте, или даже в технических документах, в которых они используются для того, чтобы лучше проиллюстрировать тот внешний вид игры, которого нужно достичь посредством технологий.
Management
1 Game Budget (Бюджет игры). Как бы сильно нам ни хотелось просто “работать над проектом от начала до конца”, экономическая реальность игрового бизнеса редко позволяет нам это делать. Обычно от команды требуется определиться со стоимостью разработки еще до того, как они будут полностью понимать, нам чем им придется работать. Стоимость проекта зачастую определяется посредством документа: часто это таблица, предназначенная для систематизации рабочего процесса по созданию игры. Данная таблица заполняется оценками сроков, которые переводятся в доллары. Продюсер или проект менеджер не могут сами высчитать эти цифры, поэтому им нужно поработать отдельно с каждой частью команды, чтобы максимально точно провести расчеты. Часто этот документ пишется одним из первых, поскольку без него трудно будет получить финансирование проекта. Хороший проект менеджер должен работать с этим