Полная версия
Профессия левел-дизайнер. Практическое руководство по созданию игровых миров
Чтобы завершить этот этап, игра проходит через несколько итераций на основе отзывов об альфа-версии. Отзывы эти поступают из различных внутренних, а иногда и внешних источников, а также от плейтестеров. Объем тестирования и исправлений постоянно увеличивается, чтобы устранить как можно больше ошибок, особенно связанных с прохождением. Особое внимание уделяется всему, что могло бы дать игре и уровням более низкий рейтинг или вызвать негативные отзывы. Дорабатывается и отлаживается все больше элементов контента и функций. Дополнительное внимание уделяется балансу, потому что после альфа-версии все компоненты находятся на своих местах, и с этого момента в идеале не должно быть масштабных изменений. К сожалению, нередко приходится вносить более значительные локальные изменения, потому что целиком оценить игру можно только после альфа-версии. Крупные ААА-продукты настолько сложны, что определенная обратная связь возможна только после того, как вы увидите общую картину.[23]
Еще один важный аспект бета-версии – производительность и соответствие требованиям внешних разработчиков. Например, бета-версия должна работать стабильно на всех платформах, с заданной частотой кадров, с выделенной для нее памятью, без вылетов и без долгих загрузок уровней. Соответствие требованиям третьих сторон, таких как Microsoft, Sony или Nintendo, требует от игр соблюдения определенных стандартов, таких как максимальное время загрузки уровней, минимальная частота кадров или качество онлайн-соединения. В этой книге мы не будем вдаваться в такие подробности, потому что это больше относится к продакшену, технологиям, контролю качества и менеджменту. Но левел-дизайнеры должны знать о возможных последствиях. Требования для конкретных платформ и их поколений меняются, так что важно оставаться в курсе событий.
На этапе подготовки к бета-версии удаление каких-то функций или больших сегментов уровней может привести к серьезным проблемам в продакшене. Часто бывает так, что исправить последствия удаления определенного элемента уже хорошо проработанной целостной игры труднее, чем оставить и, возможно, как-то замаскировать этот элемент, чтобы он не слишком выделялся. Другими словами, задумывайтесь о фичекате как можно раньше.[24]
3.1.11. Завершение[25]
Завершение – этап стадии бета-версии. На этом этапе количество творческих изменений уменьшается, и постепенно единственными, кто принимает решения о необходимости изменений или выполнения каких-то задач, становятся производственный и технический отделы. Цель этапа – получить готовый к выпуску продукт, так что текущие изменения становятся контрпродуктивными.
Любое предложение, особенно со стороны директоров, должно быть одобрено производственным отделом с оценкой риска со стороны технических специалистов.
Для левел-дизайнеров это значит, что у них становится все меньше задач, тогда как количество обнаруженных багов для исправления увеличивается из-за усиленного тестирования. Переход к этому этапу обычно осуществляется плавно, и в разных компаниях к нему относятся по-разному, но он необходим. Завершение может восприниматься болезненно, особенно если до сих пор появляются кое-какие замечательные идеи. Поэтому большинству креативных директоров важно постепенно отстраниться от проекта еще до его окончания. Отход от проекта со стороны большинства разработчиков ближе к бета-версии – это нормальное явление, и до конца его доводят лишь самые надежные и технически ориентированные коллеги, сосредоточенные исключительно на исправлении ошибок, чтобы не создавать новых проблем.[26]
3.1.12. Период до «золота»
Этап от бета-версии до финального «золотого мастера» – это, по сути, строгий вариант предыдущей стадии завершения. Любые предложения изменений на этом этапе должны проходить серьезную проверку и утверждаться заинтересованными лицами, ответственными за проект и за техническую поддержку, но приниматься в виде исключений. Как правило, такие изменения бывают связаны только с очевидными проблемами, возникающими в ходе плейтестов, нерискованными правками баланса или отзывами со стороны высшего руководства. Любой ценой следует избегать изменений, связанных с риском появления новых проблем или багов. Время внедрения новых функций или экспериментов с новыми идеями должно закончиться задолго до бета-версии. В противном случае будет сложно выпустить надежный продукт.
Поэтому обычно на этом этапе над уровнями работают только старшие левел-дизайнеры или технические левел-дизайнеры. Разумеется, основное внимание уделяется только багам, причем в зависимости от их количества и степени риска, даже не мелким. Процесс нарастает, пока у вас не закончится время. Ближе к концу исправляются только самые критические ошибки; главное – перестать суетиться и сосредоточиться на выходе игры. Часто многие разработчики вместе с этим уже параллельно работают над патчем первого дня.[27]
3.1.13. Заключительные слова
Имейте в виду, что я описал выше идеальный случай. В реальности ничего не происходит гладко, и каждая компания или команда, ответственная за отдельный проект, вырабатывает свою стратегию. Что касается сложных и длительных проектов, я могу лишь порекомендовать ориентироваться на стабильность, а не гнаться за высокоэффективными, но зачастую хлипкими и слишком рискованными идеями.
В любом случае все будет идти не так, как задумывалось, потому что идеальная предсказуемость невозможна. Нужно научиться справляться с неудачами и по мере необходимости вносить коррективы в свои планы, но не слишком часто. Баланс между стабильностью и гибкостью – это высокое искусство разработки игр.
3.2. Темп работы и усилий
3.2.1. Введение
Создание игры – дело не одного года или, по крайней мере, не одного месяца, и поэтому очень важно соблюдать определенный темп. Разработка игр – это своего рода марафон (или даже несколько марафонов), а не спринт.
ИЛЛЮСТРАЦИЯ 3.1. Размер и продолжительность стадий показаны не в реальном масштабе! Схема призвана лишь дать представление о том, какие этапы следуют друг за другом и как они связаны между собой[28]
К сожалению, не каждый уровень или даже не каждая игра, над которой вы будете работать, дойдет до выпуска, или «релиза». Понятно, что в таком случае разочарования неизбежны. Мне самому довелось поработать над некоторым количеством игр, которые так и не вышли. В других случаях очень большая часть моей работы была удалена и не дошла до окончательного варианта. Мне дважды пришлось пережить выгорание и столкнуться с огромным количеством негатива, разочарований и обид. Поэтому я хотел бы посвятить эту главу очень важной теме, на которую у меня имеется свой личный взгляд и, что еще важнее, по поводу которой я могу предложить свои личные решения.
Также важно отметить, что рассматриваемая далее тема не связана исключительно с левел-дизайном, а касается игровой разработки в целом. Тем не менее я считаю такие темы важными, и они, конечно же, затрагивают дизайнеров уровней, ведущих дизайнеров и директоров вроде меня. Еще стоит отметить, что я излагаю лишь личные взгляды и мнение и не являюсь профессиональным врачом или кем-то подобным.
3.2.2. Когда следует напрягаться и когда не следует
3.2.2.1. Предпосылки
Одно из ключевых различий между опытным и младшим разработчиком заключается в том, что опытный разработчик, как правило, лучше знает, когда стоит напрягаться, а когда нет. Опытные разработчики обычно понимают, когда дополнительные усилия будут напрасными, а когда окупятся, потому что они уже прошли через несколько производственных циклов. Чтобы было понятно, я не имею в виду длительные периоды переработок, или «кранча» (подробнее об этом написано ниже). Я имею в виду те случаи, когда приходится вкладывать дополнительные силы, концентрироваться, посвящать себя работе, сокращать перерывы и, возможно, задерживаться чуть дольше, чтобы закончить текущую задачу.[29]
Допустим, вам выпала невероятная возможность поработать над уровнем для нового игрового режима. Звучит соблазнительно, правда? И вот вы вкладываете всю душу в этот проект, чтобы показать всем, что вы замечательный специалист и полностью заслужили право работать в этой команде. Вы отдаетесь задаче на сто процентов, страстно спорите о режиме и уровне, выкраиваете несколько дополнительных часов, возможно, даже приходите в выходные и в целом очень привязываетесь к своей работе. А затем – сюрприз! – после нескольких месяцев упорной работы ваш уровень и весь игровой режим решают удалить. Конечно, вы расстраиваетесь. Да, звучит резко, но такое действительно случается. Может, это бывает не так масштабно и серьезно, но ни один разработчик не станет ждать, что каждая его идея доживет до финального продукта вообще без всяких изменений или исправлений.
Я не призываю к тому, чтобы работать без страсти, ответственности или привязанности к своему проекту. Конечно, такие качества нужны, ведь это неотъемлемая часть нашей профессии, и именно благодаря им она такая потрясающая. Но конечная цель любой профессиональной индустрии – это создание и выпуск готового продукта.
3.2.2.2. Когда не следует напрягаться
Распространенная ошибка новичков заключается в том, что они слишком рано начинают действовать, а потом слишком рано устают, теряют концентрацию, или слишком сильно расстраиваются, когда что-то идет не так. Если вы новичок в индустрии, то, конечно, хотите проявить себя, особенно если это работа мечты, и это совершенно нормально. Такой прилив энергии может быть очень воодушевляющим и приятным для более опытных разработчиков. В том числе поэтому мне самому очень нравится работать с джунами.
Многие компании, как правило, нанимают новичков в начале цикла разработки игры или на этапе препродакшена. И вот вы, новоявленные разработчики, хотите показать себя с лучшей стороны. Проблема только в том, что именно на этом этапе бывает больше всего экспериментов и предварительных предложений. Это значит, что многое впоследствии будет отброшено или сильно поменяется.
Повторю, не привязывайтесь слишком рано к каким-то конкретным продуктам, фичам, идеям или уровням. Наслаждайтесь возможностью поработать над самыми разными прототипами, идеями или концептами уровней. Возможно, следующий совет покажется слишком жестким, но вообще никогда не стоит слишком сильно привязываться к чему-либо, особенно на этом этапе. Конечно, вам могли понравиться какие-то элементы, которые решили удалить из игры, но важнее попытаться понять причины такого решения в целом. Не спешите с выводами, узнайте, почему не сработал тот или иной элемент, и воспользуйтесь этими знаниями при разработке последующего. Пост-мортем – это очень ценный инструмент, и даже если не проводится никаких официальных разборов, попробуйте провести свой собственный.[30]
Стоит отметить, что тема эта характерна не только для стадии препродакшена. Она легко может всплыть во время длительных периодов работы над альфой- или бета-версиями. Слишком долгие стадии, длящиеся девять и более месяцев, часто ведут к усталости, особенно если не взят нужный темп или если команда не работает слаженно. И это еще одна из причин, почему я рекомендую выделять промежуточные стадии, такие как этап «пре-альфы».
3.2.2.3. Ответственность руководства
Руководителям, директорам и менеджерам крайне важно объяснять своим подчиненным, какие элементы можно будет легко отбросить, какие являются лишь экспериментом или, скорее всего, сильно изменятся. Все сводится к управлению ожиданиями, иначе в долгосрочной перспективе люди потеряют веру в вас как в человека, принимающего решения. Если вы постоянно говорите что-то вроде: «Это окончательный вариант», – но продолжаете что-то менять, то это лишь усугубляет негатив и разочарование у ваших коллег-разработчиков.
Лучшие руководители, с которыми мне довелось работать, поддерживали прозрачность, признавали свои ошибки и четко объясняли свои ожидания. Они старались удалять ненужные наработки как можно раньше и проявляли искреннее сочувствие, если приходилось вносить серьезные правки. При этом порой ради общего блага приходилось кардинально менять мои лучшие уровни, но в итоге я ощущал себя нормально.
В другой раз две трети моего уровня сократили из-за некой сделки или из-за договоренности с очень высоким начальством. Конечно, я не могу вдаваться в подробности, но было больно и обидно, что я не знал об этом раньше. Или, по крайней мере, я рассчитывал, что мои лиды меня предупредят. К сожалению, я знаю много сеньор левел-дизайнеров, с которыми нечто подобное происходило слишком часто, и поэтому они переставали напрягаться или теряли страсть к разработке игр. Хороший лид и опытный менеджер подобные случаи сможет если не предотвратить, то хотя бы смягчить.
3.2.2.4. Когда напрягаться
Так когда же стоит напрягаться? По сути, каждый раз, когда намечен дедлайн или когда это очень важно для всей команды. Классические дедлайны – это любые ключевые точки, или «вехи», то есть крайние сроки таких этапов, как стадия альфа-версии, бета-версии, а иногда и пре-альфы, сборка для пресс-ивентов или предпроизводственного бенчмарка. Однако имейте в виду, что многие сборки, особенно для бенчмарков на этапе препродакшена или для ранних пресс-релизов, – это в значительной степени одноразовый продукт. Они, несомненно, важны, и все участники могут многому научиться на примере их подготовки, но обычно при этом большая часть работы над дизайном уровней в финальный продукт не уходит.[31]
Чтобы избежать слишком личной привязанности, я решил ограничиться «общекомандными достижениями». Потерять что-то всем коллективом не так печально, как лишиться только своих наработок. Особенно это верно, если у вас хорошая команда со здоровыми отношениями. Все основные «вехи» – это, конечно же, тоже достижения всего коллектива.
И, наконец, после сильных нагрузок не забывайте отдыхать. Если вы молоды и пьете много энергетиков, это не значит, что это будет работать вечно. Вы сами должны понимать, когда стоит перезарядить батарейки. Кому-то становится легче в одиночестве, кому-то нужна поддержка, а кому-то нужно путешествовать или обнимать своих кошек и собак. Все очень индивидуально, только обязательно отдыхайте и не торопитесь. Усталость и напряжение не проходят за пару дней. Без восполнения энергии вы не сможете сделать следующий рывок и выдохнетесь раньше срока.
3.2.3. О переработках или «кранчах»
Игровая индустрия имеет дурную славу из-за переработок, или так называемых кранчей. Если кратко, то вот мой совет: избегайте их любой ценой. Они, особенно длительные, не стоят того в подавляющем большинстве случаев, а порой и контрпродуктивны. Хорошо отдохнувший разработчик показывает себя на протяжении среднего восьмичасового рабочего дня эффективнее, чем тот, кто постоянно трудится по десять с лишним часов. Еще хуже это в социальном аспекте. Уставшие люди обычно более раздражительны или склонны вести себя не лучшим образом. В этот момент расплачиваться приходится команде, а не только отдельным людям.
ИЛЛЮСТРАЦИЯ 3.2. Упрощенный пример. Типичная кривая темпа джуниоров (верхняя) в сравнении с типичной кривой темпа сеньоров на пути к очередному майлстоуну
Тем не менее я сейчас собираюсь сказать нечто, возможно, спорное, но кранч может иметь смысл. При этом у него должна быть ясная цель, он должен быть командным усилием, ограниченным по времени, не принудительным. А еще его никогда нельзя закладывать в план. Он должен иметь четко заявленную цель (подобно описанной выше мотивации «напрягаться») и оставаться исключением, ни в коем случае не становясь нормой. Это должно быть командной работой, потому что мы создаем уровни вместе с другими отделами, и поддержка друг друга в такие сложные моменты очень важна. Ограничивать время переработок критически важно, чтобы ситуация не вышла из-под контроля. Особенно это важно для людей с семьями, которым нужно планировать свое время и уделять внимание близким.
Руководство, которое заранее ожидает кранчей или даже планирует их на ранних этапах, – это проклятие нашей индустрии. Переработки никогда не следует навязывать как команде, так и отдельным «избранным» специалистам, это касается и любого вида «мягкого давления» или давления со стороны коллег. Если вы по каким-то причинам не согласны на переработки, то это должно восприниматься нормально. Почти каждый аврал происходит из-за плохого менеджмента или плохого планирования, хотя каждая ситуация сложна по-своему. Но за предотвращение кризиса в большинстве случаев отвечают производственный отдел и менеджеры.
Я не буду подробно описывать юридические тонкости или правила компенсации за переработки, потому что они сильно отличаются в разных компаниях и странах, к тому же это не моя компетенция. Однако именно в игровой индустрии люди почти всегда работают с особым увлечением и страстью. И я прекрасно понимаю, что часто они готовы работать сверхурочно из энтузиазма, потому что сами хотят поскорее увидеть и выпустить готовую игру. Гордо относиться к своим достижениям – это нормально, и желание вложить дополнительные усилия и время – тоже. Но такое решение должно исходить от вас и от вашей команды, и, конечно же, вы не должны забывать про отдых. Особенно следует беречь себя в выходные дни. Никогда не устраивайте «кранчи» несколько дней подряд, потому что эффективность труда даже после двух-трех часов переработки резко ослабевает.
3.2.4. Поговорим о выгорании
Сразу оговорюсь, что я не психолог и не психотерапевт, поэтому, рассказывая о выгорании, я исхожу только из своего личного опыта, не более того. Однако тема психического здоровья слишком важна, чтобы ее игнорировать. Это касается не только нашей индустрии, но у нас наблюдается слишком много неблагоприятных случаев, потому что мы недостаточно говорим на эту тему. Поэтому я хотел бы поделиться личной историей и тем, что я из нее вынес.
За первые десять лет в разработке у меня было два случая выгорания, причем во времена, когда об этом мало говорили. Тогда это воспринималось скорее как признак слабости, что, конечно, только ухудшало ситуацию. Я неделями не мог физически прикоснуться к клавиатуре, испытывал серьезные проблемы со сном, или меня охватывала тревога, когда я просто приближал курсор мыши к иконке редактора – и это лишь некоторые симптомы. Для такого дизайнера уровней, как я, это было катастрофой, и я был готов уже уходить из индустрии.
К выгоранию меня привело, конечно, большое количество переработок. В течение нескольких месяцев я работал по десять-четырнадцать часов в день, в том числе и по воскресеньям. Но самым главным фактором стало отсутствие благодарности. Мне казалось, что я не нахожусь в надежной среде, где есть необходимые поддержка и защита. Мне казалось, что только я могу справиться с задачами, что я лучше всех их выполняю, а если я уставал, то это значит, что я всего лишь недостаточно силен. Так образовался замкнутый круг.
К счастью, позже у меня появились руководители и менеджеры, которые помогли внести нужные изменения. Я не верю, что несколько недель или даже месяцев отпуска – это лекарство от выгорания, потому что потом вы все равно вернетесь к прежней работе и привычкам. Важно изменить сам принцип работы и отношение к ней. При первом выгорании я сменил специализацию и команду левел-дизайнеров. При втором – переехал в другой город, в другую страну и студию, попытавшись найти лучший баланс между работой и личной жизнью.
Я знаю, что это может показаться спорным, но я не верю, что долгая работа на протяжении многих часов сама по себе приводит к выгоранию. Конечно, этот фактор может ускорить его и часто играет решающую роль. Однако распространенное мнение о том, что человек выгорает, потому что много работает, на мой взгляд, неверно. Конечно, все индивидуально, и эта тема чрезвычайно сложна, но при правильной и искренней поддержке многие люди способны работать долго и упорно, на протяжении многих часов, без всякого выгорания. Я, разумеется, вовсе не рекомендую так делать, но это возможно.
Ключевые факторы, предотвращающие выгорание людей в команде – это признательность, поддержка и защита в правильном сочетании. Я с гордостью могу заявить, что, насколько мне известно, после того как выгорел я, ни у кого в моей команде больше не было подобных случаев, несмотря на периодически возникающие нагрузки и кранчи. Мы, команда менеджеров, директоров и руководителей, следили за тем, чтобы работа специалистов ценилась, и изо всех сил их поддерживали. Мы много беседовали с ними, старались удовлетворять все их потребности и никогда не оставляли их наедине с собой. Мы заставляли их уходить домой, если они засиживались в офисе или брали на себя слишком много работы. Звучит немного натянуто и драматично, но иногда это необходимо. Для менеджеров психическое здоровье специалистов должно быть важнее продукта. В конце концов, не получится сделать отличный продукт, если все работники перегорят. Я считаю, что основная ответственность за предотвращение выгорания сотрудников лежит на их непосредственных руководителях и менеджерах. Именно они должны стать теми, кому разработчики могли бы довериться, с кем они смогут поговорить; именно они создают безопасную среду поддержки.
Если вы начали ощущать постоянную усталость, перестали получать удовольствие от работы, впали в депрессию или постоянно испытываете негативные эмоции, то я рекомендую вам обратиться за помощью. Возможно, еще рано беспокоиться, и пока ничего страшного не случилось, но очень важно для начала хотя бы поговорить об этом с кем-то. Найдите человека, которому вы доверяете. Отрицание – коварный путь, и мы по определению его не замечаем. Открыто говорить о проблемах психического здоровья – это не признак слабости! Не убеждайте себя, что нужно справляться с этим в одиночку. Я думал точно так же, и ничем хорошим это не закончилось.
3.2.5. О балансе между работой и личной жизнью
Я много писал о том, что не нужно заставлять себя работать слишком усердно или сверхурочно, а также затронул тему выгорания. Теперь хочу поделиться несколькими мыслями о другом важном, но более позитивном аспекте: здоровом балансе между работой и личной жизнью. Я пришел к этой истине сложным путем, но если вы посвятите всю жизнь только работе, то она превратится в ад, как только в ней наступит долгий темный период. А это обязательно произойдет, потому что ни одна работа не бывает идеальной – в любом производстве бывают сложности. Не хочу вас разочаровывать, но лучше заранее подготовиться к более сложным производственным циклам или этапам.
Все люди разные. У кого-то есть семья, кто-то живет один, кто-то интроверт, а кто-то экстраверт. Мы все по-разному заряжаем свои батарейки, и это совершенно нормально. Но моя главная рекомендация – найти баланс между работой и личной жизнью. В ловушку дисбаланса особенно склонны попадать молодые разработчики. Если они полностью увлечены своими мечтами, то могут забыть об этом жизненно важном принципе.
Да, было бы глупо отделываться общими фразами и советами о том, что нужно заниматься спортом или ходить на свидания, ведь все мы очень разные. Тем не менее я рекомендую вам в свободное время заниматься физической, творческой и общественной активностью. Это не значит, что все должны тут же побежать записываться в спортзал или в футбольный клуб, но улучшить ситуацию могут даже длительные прогулки. Более того, как показал кризис с COVID-19, даже самые замкнутые интроверты рано или поздно начинают скучать по общению. У каждого свой баланс, но он должен быть у всех. Слишком часто мы недооцениваем свое физическое и особенно психическое здоровье. В противном случае вы, как и я, будете платить тысячи долларов за физиотерапию и выгорать. Я жалею, что не прислушивался к себе в начале своей карьеры, и теперь хочу надеяться, что хорошо повлиял хотя бы на одного человека.
4
Дипломатия левел-дизайна
Как я уже говорил, один из трех основных компонентов в определении дизайнеров уровней – это умение быть дипломатом. Я прекрасно понимаю, что для большинства из тех, кто представляет себе левел-дизайнеров, это далеко не самое главное свойство. Так что в этой главе я хочу подробнее объяснить, почему быть хорошим дипломатом так важно. Далее в книге я подробно расскажу, как отточить свои базовые социальные навыки, чтобы стать по-настоящему хорошим дипломатом.