Джесси Шелл - Геймдизайн [Как сознание определяет наше бытие] [litres]

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

Призма 101: Призма команды

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

• Эта команда подходит для этого проекта? Почему?

• Общение в команде происходит объективно?

• Члены команды понимают друг друга, есть ясность в общении?

• Комфортно ли членам команды друг с другом?

• В команде преобладают настроения всеобщего доверия и уважения?

• Эта команда способна сплотиться вокруг общих решений?

Дизайн и разработка игры – это сложные процессы. Если у вас достаточно большой проект, а вы не обладаете множеством талантов одновременно, вам никак не справиться без команды. Люди намного важнее идей, потому что, как сказал Эд Кэтмул из Pixar, «Если вы доверите реализацию хорошей идеи посредственной команде, они ее испортят. Если вы доверите посредственную идею хорошей команде, они ее исправят».

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

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

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-документы» стали популярным методом ведения дизайнерской документации.