Бенджамин Бауэр
Профессия левел-дизайнер
Практическое руководство по созданию игровых миров

В этой книге, написанной экспертом индустрии AAA-игр с более чем 20‐летним опытом, всесторонне освещаются практические навыки, которыми должны обладать все успешные левел-дизайнеры. Книга охватывает весь спектр темы: от практических производственных методов до мягких навыков или софт-скиллов (soft skills)[1], необходимых для успешной работы в игровой индустрии.

Книга начинается с описания теоретического и абстрактного подхода, задавая общий тон для дальнейшего усвоения жестких навыков или хард-скиллов (hard skills)[2] с практическими примерами. В последующих главах описывается множество практических методов, которые можно использовать на этапе концептирования, при создании лэйаутов, для написания скриптов и при работе с искусственным интеллектом. Книга включает в себя главы, посвященные таким важным темам, как социальные навыки, навыки коммуникации, построение мира, дизайн уровней, продакшен, а также тому, как получить работу в индустрии.[3][4]

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

Бен Бауэр работает в игровой индустрии с 2003 года. За свой 20-летний опыт Бен занимал руководящие должности в Ubisoft и Crytek, а в последней он работает и по сей день как левел-дизайн директор Hunt Showdown 1986.

Я посвящаю эту книгу своему отцу – он был для меня вдохновителем и кумиром.

Огромное спасибо и объятия моей жене Эдит, которая, пожалуй, больше меня радовалась тому, что эта книга наконец‐то увидела свет.

Благодарности

Я многому научился у многих людей; одни вдохновили меня, другие стали моими фантастическими коллегами, а некоторых я просто обязан поблагодарить за возможность оказаться там, где я нахожусь сейчас. Вот список этих людей:

Алекс Фелтон, Александр Паризо, Эндрю Уилсон, Авни Йерли, Кристиан Кэрриер, Дэвид Футман, Дэвид Гривел, Денни Борхес, Дерек Паттерсон, Эрик Фелтен и все остальные, кого я забыл, потому что в таких списках всегда забываешь важных людей, Франсуа Рой, Гордана Врбанк Дюке, Грегор Копка, Гвидо Куип, Ханно Хагедорн, Джек Мамайс, Кайл Котевич, Манфред Неруркар, Мартин Уолш, Мартин Неруркар, Мэтт Вест, Майкл Хаимзон, Навид Хавари, Пэт Инголдсби, Патрик Реддинг, Пол Добсон, Питер Геленсер, Филипп фон Пройшен, Рима Брек, Роджер Лю, Расс Флаэрти, Софи Карамигеас, Стен Хюблер, остальные члены старой команды NS: CO mod crew, Том Роллер и Уилл Бейтман.

Раздел I
Введение в книгу и в дизайн уровней

1
Введение в книгу

1.1. Предисловие

Все, о чем я написал в этой книге, основано на моем практическом опыте. Чтобы у вас не возникало никаких вопросов, сразу скажу, что я не академик и у меня нет ученой степени. Благодаря опыту я могу описывать все в деталях, ориентироваться на практику, делиться тем, что работает, а что нет. Я часто использую аналогии с кулинарией, поэтому эту книгу я бы сравнил с гастрономической книгой, написанной шеф-поваром, а не человеком, который только пробует блюда. Мне кажется, что именно такой подход в большей степени и делает ее уникальной, и он же мотивировал меня на это руководство. Но вместе с тем он же и ограничивает содержание, потому что мой опыт в основном связан с 3D-играми. Поэтому я сделаю так: если у меня в чем-то немного опыта, но упомянуть это важно, то описание будет кратким. Тем не менее я твердо уверен, что многие уроки из этой книги можно применить к другим жанрам, а больше о своем опыте я расскажу дальше.

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

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

Кстати говоря, среди моих коллег по этому ремеслу и в среде мод-сообществ есть немало тех, кто испытывал значительные трудности, сосредоточиваясь только на жестких навыках, так называемых хард-скиллах. Я и сам прошел через ряд проблем, потому что в начале 2000-х годов о мягких навыках (они же софт-скиллы), то есть навыках общения и коммуникации, мало писали или говорили. У каждого были свои ожидания, и иногда они сбывались, а иногда нет, поэтому я написал эту книгу не только для того, чтобы поговорить о дизайне уровней. Напротив, я твердо убежден, что книга о дизайне уровней должна включать в себя и другие аспекты, с которыми сталкивается большинство левел-дизайнеров. Особенно это касается навыков общения. В конце концов, эта книга предназначена для профессиональных дизайнеров уровней или тех, кто хочет ими стать, а в реальности создание уровней – это только половина дела, потому что разработка игр требует командной работы.

И все же в основе этой книги лежит теория дизайна уровней и особенно ее практическое применение, основанное на моем двадцатилетнем опыте работы дизайнером уровней, ведущим дизайнером и директором. Первое серьезное влияние на индустрию я оказал в 2004 году, когда опубликовал Ben’s Small Bible of Realistic Multiplayer Level Design («Маленькую библию Бена по реалистичному многопользовательскому дизайну уровней»). Я до сих пор поражаюсь, что эту статью продолжают обсуждать спустя почти 20 лет. Ведь это свидетельствует о том, что многие основные принципы дизайна уровней не теряют своей актуальности до сих пор. Я искренне надеюсь, что то же самое можно будет сказать и об этой книге. Позже я создал канал Bauer Design Solutions на YouTube, где получал много положительных откликов; так я понял, что существует потребность в более практическом, основанном на реальном опыте руководстве по дизайну уровней, которое дополняло бы академические знания. Помимо публичного обмена данными, в профессиональном плане я всегда уделял большое внимание наставничеству и обучению всех желающих – от младших специалистов до директоров.[5]

1.2. Обзор глав

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

1.2.1. Введение в книгу и в левел-дизайн

Первые две главы, «Введение в книгу» и «Что такое левел-дизайн, и кто такие дизайнеры уровней», призваны дать вам представление об этой книге и о том, что значит быть дизайнером уровней. Они помогают задать правильные ожидания от дальнейшего чтения, потому что мой опыт богат, но не охватывает всего. Так, например, я никогда не работал над RTS (стратегиями в реальном времени) или сайд-скроллерами, но об этом чуть позже. Также в этой главе говорится о том, что я считаю важным для дизайнеров уровней или что их определяет, потому что в индустрии нет реальных стандартов.

1.2.2. Производство

Следующие три главы, «Производство уровней», «Дипломатия левел-дизайна» и «Командная работа и инструменты лидера», посвящены в основном упомянутым ранее социальным навыкам. Здесь также дается обзор типичного цикла разработки левел-дизайна, поскольку он очень хорошо связан с аспектами дипломатии и лидерства.

1.2.3. Теория левел-дизайна

В эту категорию входят пять глав: «О видении, дирекшене, столпах и ДНК», «Абстрактный дизайн уровней», «Общая картина», «Высокоуровневые лэйауты» и «Соединительная ткань». По сути, она охватывает широкий спектр идей, концепций или абстрактных инструментов и мои методы разработки/анализа уровней или игр. Хотя у всего этого есть практическое применение, оно остается на более высоком теоретическом уровне.

1.2.4. Практика: с чего начать

Я решил разделить практический раздел книги на три части, начав с первых шагов работы над уровнями на «Стадии концептирования», а затем перейти к «Первым шагам» в редакторе. Я затрону важнейшие темы о том, как переходить от плана к реальным действиям или к документации, а также опишу несколько таких тем, как создание мира или бенчмарки.

1.2.5. Практика: лэйауты

Следующая практическая категория включает в себя две большие главы: «Укрытия, поток и ведение игрока» и «Типы сценариев и локаций». Здесь мы много поговорим о том, где размещать наши любимые ящики, как вести игрока по пространству или создавать захватывающие лэйауты для стелса. Многие считают лэйауты основой левел-дизайна, поэтому тут будет много графики и левелдизайнерского жаргона.

1.2.6. Практика: технические аспекты и гейм-дизайн

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

1.2.7. Заключительные темы

Под конец, в главе «Завершение и сдача проекта», рассказывается о том, как дизайнеры уровней заканчивают проект, потому что это один из самых важных, на редкость творческих, а иногда и самых сложных этапов. Я также добавил главу «Как стать левел-дизайнером», потому что это тема, о которой мне чаще всего задают вопросы после проведения презентаций для людей не из индустрии.

1.3. О себе

1.3.1. Как все началось

1.3.1.1. До Интернета

С тех пор как я прочитал «Властелина колец» Дж. Р. Р. Толкиена и впервые сыграл в настольную ролевую игру на свой десятый день рождения в 1990 году, я подсел на создание миров и игр. Сначала я сочинял ролевые игры, набирая их сценарии на старой печатной машинке. Но все изменилось, как только в моей жизни появился персональный компьютер. В 1994 году первой игрой, которую я купил на собственные деньги, стала Forgotten Realms: Unlimited Adventures от MicroMagic, которая, по сути, представляла собой редактор уровней AD&D (Advanced Dragon & Dungeons), позволяющий создавать собственные приключения и делиться ими с друзьями. Конечно, обмен подземельями на 3½-дюймовых дискетах был не очень расхожим, не говоря уже о моих тогдашних ограниченных дизайнерских способностях.

Тем не менее с увеличением популярности совместных игр по локальной сети и игры Duke Nukem 3D от 3D Realms мои уровни стали гораздо востребованнее. Чуть позже на мое восприятие левел-дизайна огромное влияние оказала игра Quake 1 от id Software. Не стоит забывать, что в Германии 1990-х годов к подобным играм относились очень критично, и это объясняет, почему игры вроде Doom от id Software появились в моей жизни так поздно.

1.3.1.2. Вступление в сообщество мододелов

Я уже не помню точно, в каком году у нас дома появился Интернет, но мои родители поняли, что я его нашел, когда получили огромный счет. Тем не менее они любили меня и понимали, так что все уладилось, и вскоре я присоединился к команде разработчиков модов для Quake 2 от id Software. Команда называлась Team Mirage, и нашим первым многопользовательским модом, а точнее, темой для общих бесед, стал Navy Fortress. Если я правильно помню, это была первая тактическая игра, в основе которой раунды с классами. Но не стоит полагаться на мою дырявую память в том, что происходило лет двадцать пять назад. Мод не был особо популярен, так как вышел уже под конец эры Quake 2, да и я на тот момент многого еще не знал. Мне только предстояло выпустить первые уровни, а тогда я, будучи подростком, лишь осваивался и делал первые шаги в левел-дизайне, и это было довольно трудно.

Однако следующий проект нашей команды под названием Navy Seals: Covert Operations оказался лучше. Это был многопользовательский тотальный мод для игры Quake 3 от id Software. Конечно, все мы, как хардкорные игроки в Quake, думали, что тактические моды для Quake 3 должны быть намного популярнее, чем для Half-Life 1 от Valve… Да, мы ошибались, но об этом в другой раз.

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

Еще я написал свою первую статью Art'n'Level Design, а практическая часть моего выпускного экзамена заключалась в воссоздании образцов искусства ХХ века в трехмерном виде с помощью движка Quake 3. Если говорить кратко, то после 11 сентября немцу (без опыта и университетского образования) было сложно найти работу в США, поэтому фанаты мода уговорили меня устроиться в Crytek на должность дизайнера уровней. В общем, я не был бы там, где я сейчас, без моих замечательных родителей, членов команды и фанатов.

1.3.2. Моя профессиональная карьера

1.3.2.1. Работа в Crytek

После изнурительного шестичасового собеседования в начале 2003 года я получил предложение стать младшим дизайнером уровней («джуниор-дизайнером») в Crytek и поработать над самой первой Far Cry. Параллельно с работой я посещал что-то вроде профессионального училища, чтобы стать дизайнером в полиграфии. Это немецкая фишка, я не буду утомлять вас всеми подробностями.

Работа над первой Far Cry в CryEngine стала для меня совершенно уникальным опытом, хотя она длилась всего около года. Поначалу переход от мультиплеера к одиночной игре казался мне сложным, но я быстро привык и сосредоточился в основном на внутренних уровнях, освещении, арте окружения, визуальных спецэффектах (VFX) и на размещении NPC – вражеских и дружественных неигровых персонажей под управлением искусственного интеллекта (AI). В итоге меня повысили до среднего (Intermediate) дизайнера уровней, и я даже получил награду не только за дизайн уровней, но и за арт. Перед следующим большим проектом я успел поработать над несколькими небольшими, такими как технологические демоверсии и многопользовательские пакеты.

Затем еще одним важным этапом для меня стала работа над игрой Crysis от Crytek. Сначала я разрабатывал интерьеры инопланетных кораблей, но затем переключился на второй и третий уровни с ландшафтом. Я создал два уровня, включая сам ландшафт, настройку персонажей, скриптинг и арт окружения. Кроме того, я тесно сотрудничал с программистами ИИ для разработки поведения человекоподобных противников и поэтому поработал практически над всеми возможными скриптами и сочетаниями боевых укрытий. В конце проекта я стал все больше вовлекаться в руководство младшими дизайнерами. У меня было мало опыта, но мне это ужасно нравилось. Сейчас, оглядываясь назад, я могу с уверенностью сказать, что за несколько лет разработки мое психическое здоровье сильно пострадало. Я работал больше года без перерыва, и из-за этого и других факторов я дважды «поймал» выгорание, от которого, к счастью, оправился. К окончанию проекта меня повысили до старшего левел-дизайнера.

После Crysis мне выпал шанс присоединиться к недавно основанной студии Crytek в Будапеште в качестве ведущего дизайнера уровней Crysis Warhead. Я определенно могу посоветовать переходить от позиции старшего (senior) специалиста к ведущему (lead), если речь идет о знакомом бренде. Мне пришлось не только обучать местную команду в работе над движком, жанром и интеллектуальной собственностью, но и самому учиться мастерству руководства. После [6]Crysis Warhead мы приступили к работе над начальной версией Ryse от Crytek. За годы работы в Будапеште многому научился в плане работы руководителем, а еще я узнал о том, чего делать не стоит.

1.3.2.2. Работа в Ubisoft

В середине 2011 года, когда разработка Ryse переместилась из Будапешта в штаб-квартиру Crytek во Франкфурте-на-Майне (Германия), я принял предложение о работе в Ubisoft Toronto над Splinter Cell Blacklist в качестве одного из директоров по дизайну уровней с упором на однопользовательскую кампанию. Это была отличная возможность сменить страну, город, континент и познакомиться с совершенно новой компанией и культурой – такое я могу порекомендовать всем, кто проработал в своей первой компании более девяти лет. Работа над блокбастером Splinter Cell стала для меня фантастическим опытом, и она определенно улучшила мои навыки в области стелса и игр от третьего лица. Все уровни, использованные для маркетинга после первичного показа, были созданы моей командой.

Затем последовало несколько необъявленных/невыпущенных проектов (защищенных соглашением о неразглашении), но в индустрии это не редкость. К счастью, я снова смог поработать над увидевшей свет игрой Far Cry Primal от Ubisoft. Я был директором по дизайну уровней, ответственным за «Большую охоту» (Great Hunts) – эпические бои в открытом мире против массивных, величественных существ. Проект разрабатывался совместно с ведущей студией в Монреале. Проектирование и разработка такого нового и уникального для франшизы контента, как «Большая охота», – это, несомненно, захватывающий опыт.

После этой игры вышла Far Cry 5, которая также разрабатывалась совместно с Ubisoft Montreal. Я исполнял обязанности помощника гейм-директора, руководящего другими директорами в команде из Торонто. Мы отвечали за разработку северной части открытого мира, а именно: арта, персонажей, миссий, рыбалки и нарративных элементов – примерно трети контента мира игры. Основные знания, которые я получил во время этой работы, касались лидерства и дипломатии.

В 2018 году Ubisoft открыла новую студию в Берлине. Я решил вернуться в Европу и присоединиться к студии в качестве контент-директора, отвечающего за арт и левел-дизайн. Во многом благодаря моим тесным связям с командами разработчиков Far Cry из Канады Ubisoft поручила нашей студии создавать контент для Far Cry 6. Нам дали уникальную возможность проектировать и разрабатывать дизайн «Специальных операций» – больших, детализированных и сложных миссий в открытом мире, отделенных от основного мира. Помимо руководства большей частью команды и разработки основного направления проекта, я занимался вопросами лидерства, формирования команды и студийными делами.

1.3.2.3. Переход в Plan a Collective

Я начал писать эту книгу в середине-конце 2021 года, ближе к выходу Far Cry 6. После десяти с лишним лет увлекательной работы в Ubisoft я решил, что пришло время перейти в инди-компанию Plan A, которую возглавляет мой старый друг.

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

1.3.3. Другие сторонние работы

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

2004 год. Я написал свою вторую статью «Маленькая библия Бена по реалистичному дизайну многопользовательских уровней». Я знаю, что это довольно громкое название, но так я хотел подвести итоги своему многопользовательскому прошлому. Статья не сразу, но через какое-то время получила признание во всей индустрии. Даже сегодня люди периодически упоминают о ней и о том, какое влияние она оказала на их карьеру левел-дизайнеров. Такой положительный отклик стал для меня одной из причин продолжать делиться своими знаниями о дизайне уровней и в итоге привел к написанию этой книги.[7]

2009 год. Я начал придумывать и разрабатывать свою собственную настольную ролевую систему под названием Dark III (это рабочее название). По сей день она служит для меня творческой отдушиной, когда тот или иной проект переходит в более «нетворческую» стадию, например завершения. Я продолжал работать над несколькими мирами и использовал наработки для создания различных методов построения мира, которые затем усовершенствовал в контексте профессиональной деятельности.

2010 год. Следуя ироничному принципу «Если ты разрабатывал столько шутеров, то ты должен знать, что такое настоящая перестрелка», я начал играть в страйкбол сначала в Венгрии, а затем, более активно, в Канаде. Занятие это быстро переросло в настоящее увлечение в 2014–2015 годах, когда мы с командой так сходили с ума по экипировке, что заменяли как можно больше «игровых» деталей одежды и снаряжения на настоящие. Разумеется, насколько это вообще можно было сделать в рамках закона. Конечно, даже длительные хардкорные «милсимы» (военные симуляции) или огромное количество боев в ограниченном пространстве (CQB) с приборами ночного видения, ИК-лазерами, реальной оптикой и тепловизионными прицелами никогда не будут похожи на настоящее. Тем не менее это было безумно весело, иногда утомительно, и заодно так можно было усвоить массу уроков и приобрести друзей на всю жизнь. В 2015 году я решил завести посвященный этой теме собственный YouTube-канал под названием Dark Gray Project. К сожалению, мне пришлось закрыть его, так как после переезда в Германию я больше не играю в страйкбол.

2014 год. Мне представилась уникальная возможность выступить в качестве докладчика на конференции Walt Disney Imagineering Ideation в Лос‐Анджелесе. Я был единственным представителем цифрового медиума и поделился своими мыслями об «игровых средах», которые могли бы помочь развивать новые парки.

2014 год. Благодаря впечатлению, которое я произвел в Disney, один из спикеров экспертной комиссии, Чад Оппенгейм, пригласил меня прочитать лекцию в Гарвардском университете для своего курса «Иммерсивный ландшафт: репрезентация посредством игровых технологий». Раз в год он приглашает одного разработчика игр выступить с докладом о своей работе, об усвоенных уроках и о вдохновении. Я провел несколько университетских презентаций, но пока что эта – самая запоминающаяся.

2016 год. Я завел еще один YouTube-канал под названием Bauer Design Solutions, где делился некоторыми мыслями о дизайне уровней и построении мира. По сути, он стал продолжением статей, потому что, снимая видео, я надеялся охватить более широкую и разную аудиторию. Видео были хорошо приняты аудиторией, и в конечном счете их успех привел к заключению контракта на написание книги. Однако мне следует извиниться, ведь в последние годы канал не слишком часто обновлялся, а пока я работал над книгой, обновления и вовсе прекратились. Тем не менее я, конечно же, планирую продолжить работу над ним в дальнейшем.

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

2
Что такое левел-дизайн и кто такие дизайнеры уровней

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

Однако эта глава должна помочь лучше понять, что означает эта роль в широком смысле и чего вам ожидать, если вы решите заняться «дизайном уровней» или чем-то подобным – независимо от фактического наименования должности.

2.1. Дизайнер уровней

2.1.1. Введение

В конце 1990-х и начале 2000-х годов мне было трудно ответить на следующие вопросы, особенно моим родителям или моей нынешней жене: «Что такое дизайнер уровней?», «Чем мы на самом деле занимаемся?» Основная проблема заключалась в том, что игровая индустрия, и, в частности, разработка крупнобюджетных блокбастеров, в Германии развита была мало.

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

2.1.2. Кто такой дизайнер уровней?

Если не вдаваться в широкий спектр вариаций и определения дизайна уровней, то для меня самое широкое определение левел-дизайнера звучит так: «Мы – строители миров. Мы – сборщики. Мы – дипломаты».

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

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

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

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

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

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

2.1.3. Варианты дизайнеров уровней

2.1.3.1. Введение

Когда я начал создавать уровни для тотальной конверсии Quake 3, я не просто делал лэйауты. Я также писал шейдеры, рисовал текстуры, создавал небольшие модели, проектировал архитектуру, писал скрипты, определял нарратив, добавлял звук, заботился об освещении и производительности – и это не все. Многое из этого уже даже не считается левел-дизайном, по крайней мере, в больших ААА-продуктах.

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

Упомянутое выше определение дизайнера уровней достаточно широко и предполагает широкий спектр вариантов. Поэтому я хотел бы немного углубиться и описать распространенные типы дизайнеров уровней. Учтите, что я использую здесь только те термины, с которыми более или менее знаком. Точные названия и детали могут сильно отличаться в разных компаниях, а иногда даже в разных студиях одной компании. Кроме того, имейте в виду, что приведенные ниже определения не полностью соответствуют реальным названиям. Я пользуюсь ими для разграничения специализации тех, кого часто называют «дизайнер уровней».

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

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

ИЛЛЮСТРАЦИЯ 2.1. Позиция специальностей показана лишь приблизительно, чтобы описать идею, потому что в реальности их интерпретация в разных студиях сильно различается

2.1.3.2. Левел-дизайнеры дженералисты

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

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

2.1.3.3. Левел-дизайнер лэйаутов / сборщик уровня

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

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

2.1.3.4. Дизайнеры миссий/квестов

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

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

2.1.3.5. Левел-дизайнеры скриптеры

Их можно сравнить с дизайнерами миссий или квестов, но, скажу по собственному опыту, они более универсальны в скриптах и зачастую менее ориентированы на нарратив. Их привлекают для разработки более сложных программных сценариев (скриптов), таких как большие скрипты персонажей, сложные миссии или запутанные задания. В зависимости от состава команды они, скорее всего, будут заниматься и планом уровня.

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

2.1.3.6. Левел-дизайнеры «без арта»

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

2.1.3.7. Технические левел-дизайнеры

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

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

2.1.3.8. Синематик-дизайнеры

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

2.1.4. Категории дизайнеров уровней по старшинству

2.1.4.1. Введение

Как и в случае с вариантами дизайнеров уровней, глобального отраслевого стандарта для уровней старшинства (грейдов) в левел-дизайне не существует. Однако ниже я опишу некоторые типичные категории, с которыми сталкивался до сих пор и которые должны вполне подходить. Во время собеседования стоит также уточнить порядок грейдов, принятый в компании, и какие у вас будут возможности для карьерного роста.

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

2.1.4.2. Интерн / младший левел-дизайнер[9]

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

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

2.1.4.3. Обычный/средний левел-дизайнер[10][11]

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

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

2.1.4.4. Старший левел-дизайнер[12]

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

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

2.1.4.5. Эксперт / главный левел-дизайнер[13]

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

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

2.1.4.6. Ведущий левел-дизайнер[14]

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

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

2.1.4.7. Директора по левел-дизайну

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

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

2.2. Дизайнеры уровней как эксперты

2.2.1. Введение

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

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

2.2.2. Эксперты в архитектуре

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

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

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

Часто не требуется полностью воссоздавать реалистичное пространство во всех деталях. Тем не менее важно создать правдоподобное окружение, которое вызывало бы отклик у игроков или хотя бы выглядело логичным. Например, в общественном мнении тюрьма в Гуантанамо скорее похожа на территорию ныне закрытого лагеря «X-Ray» с клетками под открытым небом, чем на современную тюрьму строгого режима.[15]

2.2.3. Эксперты в области ландшафтной архитектуры и градостроительства

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

Каков баланс между пространствами для передвижения, управления, отдыха, презентаций и производства? Где бы вы разместили церковь, стрип-клуб, продуктовый или цветочный магазин в маленьком сельском городке в Кентукки? А если сравнить с Лас-Вегасом или Чэнду? Чем отличается планировка портов в Сиэтле, Гаване и Венеции? Каковы основные элементы атомной электростанции и как они взаимосвязаны?

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

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

2.2.4. Эксперты в географии

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

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

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

2.2.5. Эксперты по биологии

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

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

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

2.2.6. Эксперты по химии, физике, инженерии, механике и т. д

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

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

Да, на большинство этих вопросов отвечают физические движки и другие игровые функции. И все же, на мой взгляд, они отличаются от типичных компонентов гейм-дизайна, поскольку определяют внешний вид и атмосферу вашего мира. Ключевую роль здесь играет последовательность (согласованность элементов), и я настоятельно советую вам держаться подальше от одноразовых, жестко прописанных моментов, которые нарушают ожидаемые игроками правила. Всегда странно, когда машины могут пробить стены домов, а танк останавливается, наткнувшись на ржавый уличный знак. К сожалению, мне довелось заскриптовать очень много падающих деревьев в игре, где не подразумевалось большой разрушаемой растительности. Сейчас я бы сказал, что это была очень странная задача. Конечно, игры всегда зависят от доступных технологий и временных ограничений, но современные игры дают нам гораздо больше возможностей для создания миров, где все работает согласованно. Более того, я вовсе не имею в виду, что в каждой игре должны быть разрушаемые деревья, просто в ней не должно быть непоследовательных исключений.

2.2.7. Эксперты по культуре, истории, геополитике и т. д

Социальные темы также играют ключевую роль в создании правдоподобной цивилизации и соответствующей среды. Каждый создающий мир дизайнер должен понимать, что связывает между собой жителей его мира. Речь идет о балансе между богатыми и бедными, о том, как банды района показывают свое присутствие, или о том, как местное население демонстрирует свою любовь или ненависть к заморским оккупантам. А также о том, с какой жадностью местная банда инопланетных жаб устраивает свои ежедневные чаепития.

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

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

2.2.8. Эксперты в области инструментов левел-дизайна

Конечно, владение редактором уровней – один из главных навыков любого левел-дизайнера. Иногда это общедоступный редактор, созданный специально для одного движка, например Unreal Engine от Epic или Sandbox от Crytek. Помимо этого, у многих собственных движков есть свои редакторы и инструменты, а иногда в качестве инструментов для дизайна уровней используются программы вроде Autodesk’s Maya или 3ds Max.[18]

Как несколько разработчиков могут эффективно и без проблем работать над одним и тем же уровнем одновременно? Насколько хорошо интегрировано в редактор программное обеспечение для контроля версий? Есть ли способы ускорения процесса загрузки? Насколько быстро и легко можно создать простой сценарий боя? Насколько разнообразны инструменты отладки? Насколько быстро можно протестировать уровень? Насколько стабилен и прост инструмент? Легко ли с его помощью писать сложные прототипы? Можно ли легко экспортировать части уровня в другую программу? Применяется ли этот инструмент лишь для дизайна уровней или же им пользуются и другие отделы? Насколько хороша техническая поддержка инструмента и каковы перспективы его развития?

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

2.2.9. Эксперты по скриптам

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

В чем разница между текстовыми, визуальными и 3D-скриптами? Как поддерживать чистоту скрипта? Что такое хорошие и что такое бесполезные комментарии? Какие функции хорошо работают по сети, а какие требуют дополнительных мер безопасности? Нужно ли добавлять дополнительные буферы или другие резервные скрипты, чтобы гарантировать, что все будет работать на 100 % как задумывалось, в любых обстоятельствах и на любой платформе? Насколько хорошо я должен писать скрипты, чтобы стать старшим левел-дизайнером?

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

2.2.10. Эксперты по лэйаутам и режиссуре

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

Как настроить поведение ИИ-штурмовика или ИИ-снайпера? Как сделать так, чтобы игрок не пропустил крутую анимацию? Какими безумными способами можно сочетать вингсьют и крюк-кошку? Как сделать аптечки более заметными в этом окружении? Стоит ли ожидать, что игроки будут знать команды активации грузовика, взрывчатки и погрузки в транспорт? Как улучшить маршрут игрока, не меняя количество укрытий? Можно ли снизить интенсивность освещения без ущерба для сложности и для ориентации в пространстве? Как игроки поймут, что это хорошее место для снайпера или для запуска дронов? Как еще использовать эти артовые ассеты в другом контексте, чтобы скрыть недостатки другого модульного арта?[19]

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

2.2.11. Эксперты по прогрессии и сложности

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

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

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

2.2.12. Эксперты в области искусства и технологий

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

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

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

2.2.13. Эксперты по креативности и увлекательности

Казалось бы, экспертами по креативности и увлекательности (от англ. fun) быть несложно, мы же, в конце концов, дизайнеры игр. Однако нет какой-то секретной методики, которая поможет вам в секунду стать суперкреативным и начать понимать, что нужно сделать, чтобы игра стала веселой и увлекательной. Тем не менее есть некоторые методы, которые по крайней мере позволяют делать игры не скучными. За всю историю создания игр уже исследовано немало творческих концепций и идей, помогающих повысить интерес к игре. Я часто полагаюсь на эти базовые принципы, потому что никто и никогда еще не предлагал какую-то отдельную теорию с ответами на все случаи жизни.

Какими методами пользуетесь вы, если вы «забуксовали» в плане творчества? Какие простые и быстрые методы позволят вам найти больше идей? Какими принципами вы руководствуетесь для создания прочной основы? Если игра или задание в ней становятся неинтересными, какие запасные решения вы обычно используете? К каким базовым идеям для игры, миссии или лэйаута вы прибегаете в самом крайнем случае? Какие у вас есть стандартные вопросы/шаблоны для нахождения правильных решений, если уровень кажется скучным и неинтересным?

У каждого из нас бывают моменты удач, но, к сожалению, это далеко не каждодневная норма. Я рекомендую постоянно искать закономерности, разрабатывать запасные идеи, думать о прочных основах, знать, чего следует избегать, и совершенствовать процессы. У нас нет включателя гениальности, благодаря которому мы творили бы двадцать четыре часа в сутки. Пусть некоторые и считают себя великими творцами, но такое ощущение длится недолго. Думаю, здесь как нельзя кстати подходит цитата Чака Клоуза: «Вдохновение – для любителей. Остальные просто приходят и приступают к работе. Если ждать, пока разойдутся тучи или пока вам в мозг ударит молния, ничего стоящего не выйдет. Все лучшие идеи рождаются в процессе работы; они рождаются в самой работе». Или, говоря проще: «Любители ждут вдохновения, дизайнеры идут работать».

2.2.14. Эксперты по тайм-менеджменту и организации труда

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

Сколько времени потребуется для завершения различных этапов вашего уровня от начала до конца? Что может пойти не так и какой запас прочности вам нужен? Какие у вас могут быть ограничения и когда и как о них стоит сообщить руководителям или менеджерам? Когда нужно приложить дополнительные усилия, а когда лучше отдохнуть и перезарядиться? Есть ли у вас список задач и как часто вы его обновляете? Как менеджер может эффективно поддерживать вас? Как менеджер может вам помочь? Как другие разработчики могут помочь вам и как вы можете помочь им?

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

2.2.15. Эксперты в дипломатии

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

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

Мне довелось работать со многими разработчиками, обладавшими серьезными профессиональными навыками, но с софт-скиллами у них были проблемы. Кто-то может опередить их в карьерном росте только благодаря дипломатии, и это кажется несправедливым. Но на самом деле это не совсем так, потому что софт-скиллы, особенно в контексте командной работы, будут становиться все важнее. Без социальных навыков вам будет сложно работать в любом коллективе, состоящем более чем из одного человека. По моему опыту, больше людей увольнялось из-за отсутствия мягких (soft skills), то есть социальных навыков, нежели жестких (hard skills), то есть технических и профессиональных. Поэтому и в этой книге я делаю на них дополнительный акцент.

Раздел II
Производство и социальные навыки

3
Производство уровней

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

3.1. Обзор производства уровней

3.1.1. Введение

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

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

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

3.1.2. Изначальная или питч-стадия

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

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

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

3.1.3. Стадия препродакшена

Цель стадии препродакшена – подготовка к производству (продакшену). На этом этапе разработчики должны завершить все основное планирование и подготовку документации. Как правило, это очень интенсивная фаза создания прототипов и тестирования ключевых моментов. Идеально, если на этом этапе появляется уверенность, что можно переходить к продакшену и что эксперименты и всякие неожиданности сведены к минимуму. Полученный на этом этапе опыт очень важен для менеджеров при составлении сметы производства. А еще на этой стадии полезно понаблюдать за отношениями внутри команды и прикинуть ее будущий состав.

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

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

3.1.4. Высокоуровневая стадия

В некоторых компаниях это называется «стадией чертежа» (от англ. Blueprint). В случае с линейной игрой на этой стадии прорабатываются высокоуровневая идея для каждого уровня, порядок уровней и их сочетание в игре. Если игра менее линейная, то нужно проработать основные миссии, а также набросать концепции второстепенных заданий. Если проект большой, то часто такую фазу разбивают на несколько частей, например по регионам игрового мира или различным этапам игры. Тем не менее должна существовать главная стадия, объединяющая все эти части.

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

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

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

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

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

Как правило, «высокоуровневый» этап, или этап «чертежа», происходит в начале стадии препродакшена или, в идеальном случае, перед ним. Собрать всех директоров и других важных людей в одном помещении на несколько недель бывает непросто, но это очень важно.

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

3.1.5. Стадия документации

Как правило, дизайнеры уровней подключаются к работе как раз на этом этапе, потому что раньше этим занимались в основном директора и ведущие. Как следует из названия, речь идет о написании документации для отдельных разрабатываемых уровней.[20]

Количество деталей, тип и содержание документации в разных компаниях и на разных проектах отличаются. Кроме того, документация зависит от ожиданий директоров и руководителей. Сильно различаются даже используемое программное обеспечение и стиль языка. Я начинал свою карьеру с написания огромных документов в программе Word и каракулей на бумаге. Позже это было несколько таблиц Excel и много презентаций PowerPoint с дополнительной поддержкой SketchUp, Photoshop и Visio. В последнее время некоторые компании больше работают в Confluence или даже непосредственно в инструментах отслеживания задач, таких как Jira. Методы составления и поддержания дизайнерской документации постоянно меняются и развиваются, но она наверняка всегда будет включать в себя карты, изображения и текст. Независимо от формата, типа или используемого программного обеспечения, документация по дизайну уровней преследует две ключевые цели.

Первая цель – «продать» свой уровень, сделать «питч-документ», ведь приступить к производству можно после получения одобрения. Как правило, информацию и сам питч вы даете в виде презентации. Она должна убедить всех заинтересованных в вашем уровне лиц: коллег, директоров и руководителей разных отделов. В больших проектах дизайнеры уровней работают, как правило, вместе с художниками по окружению/концептам и, возможно, с нарративными дизайнерами и гейм-дизайнерами. Прочитав или выслушав вашу презентацию, они все должны согласиться с тем, что ваш уровень стоит запускать в продакшен.

Вторая цель – сообщить о вашем уровне отделам по обеспечению и контролю качества (QA и QC соответственно). В идеале для проведения тестов они должны использовать задокументированное вами прохождение уровня, а не создавать собственные тесты и не фантазировать о том, как уровень может проходиться. Но еще это значит, что вам придется регулярно обновлять документацию в течение всего продакшена, и именно это [поддержание в актуальном состоянии] – самое сложное.

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

3.1.6. Производство

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

3.1.7. Скелетная стадия

Как следует из названия, на этом этапе в игровой движок внедряется «скелет» вашего уровня. Основное внимание при этом уделяется технической составляющей и подготовке к производству, но теперь это не чистая теория, а то, что уже происходит в игровом движке.

Во-первых, создается физическая основа уровня или мира, в первую очередь с учетом масштабов и расстояний. В открытом мире пространство для миссии должно быть определено, даже если это просто плоский рельеф с примерно установленной высотой и обозначенный каким-нибудь плейсхолдером. Для уровней без ландшафта это обычно просто достаточное количество плиток пола, лестниц и, возможно, нескольких стен, чтобы прикинуть масштаб разрабатываемого плана. Если уровень включает в себя более причудливые виды навигации, недоступные на этом этапе производства, то вполне подойдет телепортация или в крайнем случае даже чит на полет. Цель «скелета» состоит в том, чтобы оценить размеры и расстояние на самой ранней стадии продакшена. Начните проходить уровень и постарайтесь почувствовать пространство, чтобы ответить на основные вопросы сейчас, пока эту основу можно еще безболезненно поправить.[21]

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

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

В конце стадии скелета уровень (или миссия) должен быть доступен для прохождения, хотя он и может показаться бесцветным и безвкусным, что нормально. К тому же у остальных отделов теперь есть все необходимое для доработки пространства уровня.

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

3.1.8. Этап изначального замысла

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

На этой стадии добавляются реальные элементы геймплея по мере их реализации. Так, например, можно добавить важного персонажа, которого нужно убить, оставив плейсхолдер для предмета, который нужно уничтожить в определенном месте, или вы можете внедрить ранний прототип головоломки. Затем уровень заполняется примерным количеством NPC разных типов, вместе с их триггерами/переключателями. Под конец стадии у вас должны быть реализованы все основные элементы геймплея уровня, пусть и в сыром виде. Реализовывать альтернативные пути прохождения, второстепенные цели, экстремальные случаи, «защиту от дурака» или любые другие дополнительные идеи, возникающие в процессе разработки, пока не требуется.

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

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

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

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

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

3.1.9. Альфа

Цель альфа-версии – полнота контента. Это означает, что на уровне должно быть реализовано все, что было задумано. В понятие контента входит, например, размещение противников и патрулей, айдл-анимации, подсвечивание важных точек, точки обзора, укрытия, художественные ассеты, геймплейные фичи (хотя бы в виде временных кат-сцен) и элементы повествования. Альтернативные пути, второстепенные цели, более серьезные краевые случаи и, особенно, известные способы сломать прохождение – все это теперь должно быть учтено. По сути, уровень должен быть готов к внешнему тестированию.[22]

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

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

Имеет смысл провести первые тесты производительности, так как все основные требующие затрат производительности компоненты к этому времени должны быть внедрены.

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

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

3.1.10. Бета

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

Чтобы завершить этот этап, игра проходит через несколько итераций на основе отзывов об альфа-версии. Отзывы эти поступают из различных внутренних, а иногда и внешних источников, а также от плейтестеров. Объем тестирования и исправлений постоянно увеличивается, чтобы устранить как можно больше ошибок, особенно связанных с прохождением. Особое внимание уделяется всему, что могло бы дать игре и уровням более низкий рейтинг или вызвать негативные отзывы. Дорабатывается и отлаживается все больше элементов контента и функций. Дополнительное внимание уделяется балансу, потому что после альфа-версии все компоненты находятся на своих местах, и с этого момента в идеале не должно быть масштабных изменений. К сожалению, нередко приходится вносить более значительные локальные изменения, потому что целиком оценить игру можно только после альфа-версии. Крупные ААА-продукты настолько сложны, что определенная обратная связь возможна только после того, как вы увидите общую картину.[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
Дипломатия левел-дизайна

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

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

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

4.1. Дизайн уровней в центре производства

4.1.1. Введение

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

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

4.1.2. Отделы, с которыми работают левел-дизайнеры

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

В списке наименований у меня нет никакого приоритета. Основное различие между «Сотрудничают тесно» и «Сотрудничают иногда» заключается в том, что в первую группу входят те, с кем вы, скорее всего, работаете часто и регулярно, если не ежедневно. Во второй группе – те, с кем вы работаете нечасто, недолго, а может, и вовсе не работаете.

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

ТАБЛИЦА 4.1. Таблица, показывающая, с кем дизайнеры уровней сотрудничают на разных этапах разработки (тесно или иногда)[32]

На основе этой таблицы можно вывести более или менее четкие закономерности. По моему опыту работы в гибком цикле производства, левел-дизайнерам на протяжении всего цикла приходится много, почти ежедневно, работать с художниками окружения, сотрудниками отдела контроля качества и, конечно, с коллегами по дизайну уровней. На втором месте находятся нарративные дизайнеры и технические (левел-) дизайнеры. Никого не должны удивлять и ежедневные контакты с руководителями (ведущими специалистами или «лидами») и директорами, потому что их работа, по сути, заключается в том, чтобы следить за вашей работой. Люди, занимающиеся продакшеном или менеджментом, обычно также контактируют с левел-дизайнерами ежедневно, но я перевел их в категорию «иногда», потому что такие контакты чаще всего бывают только на утренних совещаниях, если вы работаете по системе «спринтов».

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

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

4.1.3. Заключение

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

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

4.2. Как работать с представителями разных отделов

4.2.1. Введение

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

4.2.2. Дипломатия разработчиков игр 101[33]

4.2.2.1. Не относитесь к людям так, как хотите, чтобы они относились к вам

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.

Примечания

1

Навыки коммуникации. – Прим. науч. ред.

Вернуться

2

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

Вернуться

3

Схемы уровней. – Прим. науч. ред.

Вернуться

4

Фрагменты игровой логики. – Прим. науч. ред.

Вернуться

5

Официально на русский язык статью не переводили. Существует практическое руководство, основанное на работе Бена Бауэра (https://www.progamer.ru/dev/mpleveldesign.htm). – Прим. ред.

Вернуться

6

В игровой индустрии уровни позиций для простоты часто используют без перевода: джуниор (или джун), сеньор и лид. – Прим. лит. ред.

Вернуться

7

Ранее статья уже упоминалась. Ее можно найти в свободном доступе, вбив в поиск оригинальное название Ben’s Small Bible of Realistic Multiplayer Level Design. – Прим. лит. ред.

Вернуться

8

Так можно назвать любые объекты с игровой логикой. – Прим. науч. ред.

Вернуться

9

Также его называют «джун» (от англ. Junior). – Прим. науч. ред.

Вернуться

10

В русскоязычной разработке у этой должности нет отдельного термина. Оставляют просто «левел-дизайнер». – Прим. науч. ред.

Вернуться

11

Также его называют «мидл» (от англ. Middle). – Прим. науч. ред.

Вернуться

12

Также его называют «сеньор» (от англ. Senior). – Прим. науч. ред.

Вернуться

13

Также его называют «принципал» (от англ. Principal). – Прим. науч. ред.

Вернуться

14

Также его называют «лид» (от англ. Lead). – Прим. науч. ред.

Вернуться

15

Лагерь «X-Ray» – это зона временного содержания заключенных на базе Гуантанамо. Лагерь закрыли в 2002 году. В 2014 году был снят одноименный фильм с Кристен Стюарт в главной роли.

Вернуться

16

Солидарен с автором. – Прим. науч. ред.

Вернуться

17

В этой книге для различных явлений, некоторых событий, боевых столкновений, встреч и прочего используется слово encounter. Среди русскоязычных разработчиков все это называется для краткости так же – энкаунтер. – Прим. лит. ред.

Вернуться

18

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

Вернуться

19

Костюм-крыло. – Прим. ред.

Вернуться

20

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

Вернуться

21

Временная болванка. – Прим. науч. ред.

Вернуться

22

Анимации персонажей в состоянии покоя. – Прим. науч. ред.

Вернуться

23

Игроки, разработчики или тестировщики, которых приглашают поиграть в конкретную версию игры. Для этого проводится плейтест (от англ. playtest) – игровая сессия с целью получения обратной связи. – Прим. науч. ред.

Вернуться

24

Фичекат (от англ. Feature Cut) – процесс удаления из игры функций или части контента. Как правило, к нему прибегают, чтобы уложиться в сроки. – Прим. науч. ред.

Вернуться

25

Во многих студиях этот этап называют постпроизводством или постпродакшеном (от англ. post-production). – Прим. науч. ред.

Вернуться

26

Ошибок (от англ. Bug). – Прим. науч. ред.

Вернуться

27

Первое обновление игры после запуска. Как правило, ориентировано на исправление самых важных ошибок. – Прим. науч. ред.

Вернуться

28

Веха сдачи или дата завершения того или иного этапа разработки. – Прим. ред.

Вернуться

29

Период ожесточенных переработок. Не всегда оплачиваемых. – Прим. ред.

Вернуться

30

Анализ и разбор ошибок. Как правило, этот термин используется в контексте провалившегося проекта или фичи. – Прим. ред.

Вернуться

31

Мероприятие для прессы. – Прим. ред.

Вернуться

32

Quality Assurance / Quality Control – обеспечение и контроль качества соответственно. Первые назначаются с момента постановки задачи и обладают большими полномочиями, вплоть до изменения рабочих процессов, чтобы не только ловить ошибки, но и предотвращать их повторение. Вторые, как правило, привлекаются постфактум, но все еще существенно разбираются в структуре проекта и могут детально расследовать причины тех или иных багов. – Прим. науч. ред.

Вернуться

33

101 используется на западе как обозначение вводных лекций, которые посвящены основе основ, самым важным знаниям по теме. – Прим. науч. ред.

Вернуться