Практика гейм-дизайна. Пошаговое руководство по созданию увлекательных видеоигр — страница 7 из 14

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


Главный гейм-дизайнер

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


Руководитель отдела гейм-дизайна

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


Часть 3Гейм-дизайнер в руководящей роли

Эта глава не о методиках гейм-дизайна; эта тема настолько обширна и индивидуальна для каждого дизайнера, что даже поверхностное ознакомление в главу едва уместится. Кроме того, у каждого свои критерии увлекательности, и вы как хороший гейм-дизайнер должны быть верны себе. Когда гейм-дизайнер работает по чужой «формуле» увлекательности, это редко приводит к успеху. Пожалуй, мой совет по выигрышным методикам дизайна такой: «Делай что знаешь, следуй своим инстинктам».

А в этой главе я хочу рассказать, как стать эффективным руководителем в команде гейм-дизайнеров. Это собрание моих личных многолетних наблюдений. Не считайте их окончательным вердиктом по данному вопросу или стандартом, обязательным для всех. Это просто подборка уроков, извлеченных мной из личной практики. Им можно следовать полностью или частично, игнорировать, делиться ими – решать вам.

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

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

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

Эффективный гейм-дизайн

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

Первое, что вы должны ощутить, – это уважение или смирение, как выразилась гейм-дизайнер Portal Ким Свифт. Вы могущественны и одновременно очень уязвимы: успех проекта в основном зависит от вас и не связан с вашим положением в иерархии студии.

И даже если ваше положение высоко, не злоупотребляйте этим. Уважайте другие отделы и их вклад в проект. Их набрали не для того, чтобы воплощать ваши идеи. Вам предстоит работать вместе, чтобы создать увлекательную игру. Трудитесь на них, как они трудятся на вас. Ничто так не расхолаживает команду, как самонадеянный и надутый гейм-дизайнер, который вываливает свое «ви́дение» на собраниях и в многочисленных документах, ожидая их воплощения в игре.

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

Это не значит, что гейм-дизайнер ответственен за все неприятности проекта: проекты проваливаются по многим причинам. Но сам характер вашей работы дает вам возможность влиять на хрупкие отношения между всеми отделами. Помните о подобных ситуациях, будьте чутки и внимательны, действуйте с прицелом заслужить прочное доверие и уважение команды. Как заслужить это уважение? Вот некоторые советы.

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



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

Принимайте решения. Художники и аниматоры, программисты и саунд-дизайнеры работают согласно выверенным планам и бюджетам. Они должны создавать ресурсы в предсказуемом темпе и регулярно отчитываться о своей работе. Ничто так не разочаровывает, как неспособность принять необходимое дизайнерское решение или раздача расплывчатых распоряжений.

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

Если необходимо ситуативное решение, примите его, задокументируйте (через электронную почту) и придерживайтесь его. Вам простят, если вы окажетесь правы не во всем или не сумеете ответить на любой вопрос, – но от вас ждут принятия решений по гейм-дизайну. Когда вы с этим не справляетесь, то вносите неопределенность и оставляете все в подвешенном состоянии. Лучше принять неверное решение, чем не принимать никакого. А вы будете делать неверные решения, как и все гейм-дизайнеры. Поэтому…

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

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

Частые правки дизайн-документа не означают, что он бесполезен. Вам нужна отправная точка, и первые версии дизайн-документа критически важны для формирования общего ви́дения игры и стратегии проекта. Тем не менее многие интерпретируют его по-разному, и в одно и то же предложение каждый отдел может вкладывать свой смысл. Программистам требуется дополнительно пояснять вещи, очевидные аниматорам.

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