📚 Hub Books: Онлайн-чтение книгДомашняяГеймдизайн - Джесси Шелл

Геймдизайн - Джесси Шелл

Шрифт:

-
+

Интервал:

-
+
1 ... 132 133 134 135 136 137 138 139 140 ... 167
Перейти на страницу:

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

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

Дополнительное чтение

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).

Глава 26 Команда общается посредством документации
Геймдизайн
Миф о геймдизайн-документе

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

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

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

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

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

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

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

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

Хранение

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

Передача

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

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

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

Геймдизайн

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

Дизайн

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

1 ... 132 133 134 135 136 137 138 139 140 ... 167
Перейти на страницу:

Комментарии

Обратите внимание, что комментарий должен быть не короче 20 символов. Покажите уважение к себе и другим пользователям!

Никто еще не прокомментировал. Хотите быть первым, кто выскажется?