Kitobni o'qish: «Профессия левел-дизайнер. Практическое руководство по созданию игровых миров»

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

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

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

Бен Бауэр работает в игровой индустрии с 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, где получал много положительных откликов; так я понял, что существует потребность в более практическом, основанном на реальном опыте руководстве по дизайну уровней, которое дополняло бы академические знания. Помимо публичного обмена данными, в профессиональном плане я всегда уделял большое внимание наставничеству и обучению всех желающих – от младших специалистов до директоров.⁵

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), если речь идет о знакомом бренде. Мне пришлось не только обучать местную команду в работе над движком, жанром и интеллектуальной собственностью, но и самому учиться мастерству руководства. После ⁶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 год. Я написал свою вторую статью «Маленькая библия Бена по реалистичному дизайну многопользовательских уровней». Я знаю, что это довольно громкое название, но так я хотел подвести итоги своему многопользовательскому прошлому. Статья не сразу, но через какое-то время получила признание во всей индустрии. Даже сегодня люди периодически упоминают о ней и о том, какое влияние она оказала на их карьеру левел-дизайнеров. Такой положительный отклик стал для меня одной из причин продолжать делиться своими знаниями о дизайне уровней и в итоге привел к написанию этой книги.⁷

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. Левел-дизайнер лэйаутов / сборщик уровня

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

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

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. Интерн / младший левел-дизайнер⁹

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

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

2.1.4.3. Обычный/средний левел-дизайнер¹⁰¹¹

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

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

2.1.4.4. Старший левел-дизайнер¹²

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

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

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

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

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

2.1.4.6. Ведущий левел-дизайнер¹⁴

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

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

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

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

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

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

2.2.1. Введение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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. Стадия документации

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3.1.9. Альфа

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

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

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

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

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

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

3.1.10. Бета

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

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

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

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

3.1.11. Завершение²⁵

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

Любое предложение, особенно со стороны директоров, должно быть одобрено производственным отделом с оценкой риска со стороны технических специалистов.

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

3.1.12. Период до «золота»

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

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

3.1.13. Заключительные слова

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

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

3.2. Темп работы и усилий

3.2.1. Введение

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

ИЛЛЮСТРАЦИЯ 3.1. Размер и продолжительность стадий показаны не в реальном масштабе! Схема призвана лишь дать представление о том, какие этапы следуют друг за другом и как они связаны между собой²⁸

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

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

3.2.2. Когда следует напрягаться и когда не следует

3.2.2.1. Предпосылки

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

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

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

3.2.2.2. Когда не следует напрягаться

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

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

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

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

3.2.2.3. Ответственность руководства

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

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

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

3.2.2.4. Когда напрягаться

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

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

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

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. Таблица, показывающая, с кем дизайнеры уровней сотрудничают на разных этапах разработки (тесно или иногда)³²

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

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

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

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

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

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

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

4.2.1. Введение

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

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

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

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

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

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

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

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

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

4.2.2.2. Все мы в одной лодке

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

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

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

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

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

4.2.2.3. Об эмпатии

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

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

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

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

4.2.2.4. О командной работе

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

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

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

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

4.2.3. Как работать с художниками

4.2.3.1. Художники окружения

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

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

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

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

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

Работа с другими 3D-художниками очень похожа на работу с художниками окружения.

4.2.3.2. Концепт-художники

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

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

4.2.4. Как работать с отделом нарратива

4.2.4.1. Нарративные дизайнеры

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

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

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

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

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

4.2.5. Как работать с тестировщиками

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

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

4.2.6. Как работать с другими левел-дизайнерами

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

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

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

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

• Нанимают ли компании только по хард-скиллам и насколько важны для них умение работать в команде и софт-скиллы?

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

4.2.7. Как работать с менеджерами

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

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

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

4.2.8. Как работать с гейм-дизайнерами

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

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

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

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

4.2.9. Как работать с программистами

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

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

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

4.2.10. Как работать с отделом аудио

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

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

5
Командная работа и инструменты лидера

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

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

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

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

5.1. Основные принципы лидерства

5.1.1. Введение

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

5.1.2. Делайте других лучше себя

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

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

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

5.1.3. Признавайте свои неудачи

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

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

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

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

5.1.4. Как действовать в стрессовой ситуации

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

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

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

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

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

5.2. Об обратной связи

5.2.1. Введение

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

5.2.2. Предоставление обратной связи

5.2.2.1. Обратная связь – это не личное мнение

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

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

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

5.2.2.2. Обратная связь в виде вопросов и описания проблем

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

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

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

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

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

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

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

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

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

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

5.2.2.3. Прямые указания

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

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

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

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

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

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

5.2.3. Получение обратной связи

5.2.3.1. Введение

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

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

5.2.3.2. Письменная обратная связь

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

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

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

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

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

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

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

5.2.3.3. Устная обратная связь

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

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

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

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

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

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

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

5.3. О принятии решений

5.3.1. Введение

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

5.3.2. Отсутствие решения

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

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

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

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

5.3.3. Какое-то решение

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

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

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

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

5.3.4. Правильное решение

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

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

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

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

5.3.5. О процессе

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

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

Здесь применимы все советы из предыдущих подразделов, «Решение» и «Правильное решение». Готовьтесь к худшему варианту, продумайте запасные планы, собирайте достаточно информации и не торопитесь. Отдавайте предпочтение опыту, а не просто мнению, привлекайте команду, всегда излагайте свои доводы, избегайте поспешных и необоснованных выводов и, наконец, никогда не надейтесь, что вам повезет. Если ни один из этих советов не помогает, то не остается ничего, кроме как прислушаться к своей интуиции. Чем больше вы будете в курсе того, что происходит в проекте и команде, тем больше вероятность, что вы быстро заметите проблемы. Следите за трендами и плохими тенденциями. Если вы можете определить потенциальную проблему заранее, составьте список возможных ответных действий. Если вы можете заранее предусмотреть пути решения на случай какой-то проблемы, разработайте их. Но не каждый вопрос требует, чтобы на него бросались во всеоружии! Иногда достаточно просто иметь в виду, что его стоит слегка направить в нужное русло, особенно если это проблема, связанная с командой и со взаимоотношениями внутри коллектива. Но темы, связанные с собственно производством, должны решаться быстро и четко.

ИЛЛЮСТРАЦИЯ 5.2. Конечно, правильное решение – это идеальный вариант, но какое-то решение лучше, чем никакого. Точно так же и действовать всегда лучше, чем реагировать, но хуже всего – бездействие

5.4. Эмоции как общий язык

5.4.1. Введение

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

5.4.2. Проблема

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

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

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

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

5.4.3. Решение и процесс

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

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

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

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

В первую очередь следует ориентироваться на эмоции игроков, потому что они – наши потребители. Что, по-вашему, должен чувствовать игрок? Как отделы могут помочь в достижении этого чувства?

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

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

5.4.4. Дополнительные советы

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

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

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

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

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

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

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

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

Эмоция должна быть понятной и выражаться понятным словом, особенно если речь идет о совместной работе команд из разных стран. Не все сразу поймут, что значит disquietude (беспокойство), consternation (оцепенение) или gaiety (веселье, живость).

5.5. «Триумвират практического построения мира»

5.5.1. Введение

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

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

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

5.5.2. Применение

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

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

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

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

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

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

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

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

5.6. «Десятый человек»

5.6.1. Введение

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

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

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

5.6.2. Истоки

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

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

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

5.6.3. Этап 1

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

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

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

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

5.6.4. Этап 2

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

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

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

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

5.6.5. Этап 3

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

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

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

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

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

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

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

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

ИЛЛЮСТРАЦИЯ 5.4. Три этапа метода «десятого человека»

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

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

Раздел III
Теория левел-дизайна

6
О видении, дирекшене, столпах и ДНК

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

6.1. Видение как отправная точка

6.1.1. Что такое видение?

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

6.1.2. Как создать видение?

6.1.2.1. Шаг за шагом

Для начала просто запишите, что вы думаете об игре или об уровне своими словами. Не беспокойтесь о длине. Просто перечислите все детали, которые вы считаете важными для продажи идеи, полезными для уникального торгового предложения (или USP) и которые вызывают восторг лично у вас. Ничего страшного, если первый набросок получится большим и трудночитаемым, но он должен содержать всю необходимую информацию.³⁹

Затем начните сокращать и упрощать предложения примерно до двух-трех в остатке, которые вы могли бы произнести вслух с обычной скоростью за 20–30 секунд. Такая длина – не жесткое правило, это скорее ориентир. Если описание по вашим ощущениям слишком длинное, сократите все, что не считаете совершенно необходимым. Я рекомендую использовать эмоциональные описания вместо простых. Если вам нужно перечислить какие-то аспекты, не называйте больше трех-четырех подряд. Более подробные описания можно будет сделать позже в питч-презентации или в проектной документации. В конце концов, чем больше аудитория (разработчики игры) сама заполнит пробелы, тем больше она сможет увлечься предстоящей работой. Чем больше идей вызывает ваше видение, тем лучше, даже если некоторые из них потом не совпадут с вашими планами. Творческие люди отчаянно стремятся заполнять пробелы, и их воодушевление в конечном счете принесет вам больше пользы. Главное здесь – баланс проб и ошибок, заранее имейте в виду, что вам придется много раз дорабатывать свое видение, прежде чем вы почувствуете, что готовы его представить.

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

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

В идеале этих четырех шагов будет достаточно. Вы начали с исходной версии, доработали/сократили ее, обогатили и в итоге скорректировали на основе обратной связи.

6.1.2.2. Создание идеи

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

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

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

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

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

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

6.1.3. Как использовать видение

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

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

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

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

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

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

6.2. Столпы как перестраховка

6.2.1. Введение

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

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

6.2.2. Как создавать и использовать столпы

6.2.2.1. Введение

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

6.2.2.2. Использование

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

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

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

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

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

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

6.2.2.3. Создание

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

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

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

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

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

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

6.2.2.4. Советы по созданию

Ниже приведен еще один список советов по созданию хороших столпов.

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

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

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

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

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

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

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

6.3. Дирекшен как руководство к действию⁴⁰

6.3.1. Введение

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

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

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

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

Можно утверждать, что дирекшен хороший, если он отвечает следующим требованиям:

• он позволяет получить стабильный продукт;

• он понятен, им легко воспользоваться;

• он заставляет всех работать над одной целью в одинаковом темпе;

• он вдохновляет и мотивирует разработчиков, даже если вас нет рядом;

• он заставляет каждого разработчика поверить в его ценность, поэтому разработчики используют все свои знания и способности для достижения цели;

• чем лучше дирекшен, тем реже его приходится корректировать.

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

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

6.3.2. Когда расписывать дирекшен

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

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

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

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

6.3.3. Как расписать дирекшен

6.3.3.1. Шаг 1. Начните с ошибок, которых следует избегать

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

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

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

Большинство пунктов, перечисленных в видео Open World Coop Level Design Guidelines («Рекомендации по дизайну уровней в открытом мире для кооперативной игры») на моем канале Bauer Design Solutions на YouTube, базируются на проблемах, которые я видел на ранних уровнях.

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

6.3.3.2. Шаг 2. Наблюдайте за командой

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

6.3.3.3. Шаг 3. Добавьте свое видение

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

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

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

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

6.3.3.4. Шаг 4. Найдите закономерности и заполните сетку

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

ИЛЛЮСТРАЦИЯ 6.1. Заполнение абстрактной «сетки дирекшена» в стиле судоку (простая сетка 4 × 4). Черным цветом обозначены пункты на основе практических наблюдений и выводов. Серым – пункты, составленные при логическом заполнении пробелов. Пустые клетки – места для пунктов, которые еще предстоит составить

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

Я называю этот процесс заполнением сетки, потому что он напоминает мне игру в судоку. Шаг 4 похож на логическую головоломку: при имеющихся нескольких заданных полях я должен заполнить недостающие, основываясь на своем опыте и знаниях.

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

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

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

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

6.3.3.5. Шаг 5. Перенос на бумагу

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

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

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

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

6.3.4. Как использовать дирекшен

Очевидно, сначала проводится презентация с объяснениями и примерами для более широкой аудитории, которую затрагивает дирекшен.

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

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

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

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

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

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

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

7
Абстрактный дизайн уровней

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

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

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

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

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

7.1. О теории

7.1.1. Введение

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

7.1.2. Создание теории

7.1.2.1. Введение

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

7.1.2.2. Шаг 1. Постановка проблемы

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

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

7.1.2.3. Шаг 2. Упрощение

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

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

7.1.2.4. Шаг 3. Закономерности

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

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

7.1.2.5. Шаг 4. Повторение

Описывая Шаг 2, я говорил, что абстрагироваться нужно постепенно, слой за слоем. Если на Шаге 3 вы не нашли то, что вам нужно, стоит повторить процесс, начиная с Шага 2, только с повышенным уровнем абстракции, а затем повторить Шаг 3 и т. д., пока нужное не найдется. Однако даже неудача может многое показать, как описывалось выше в примере для Шага 3. И напротив, если вы обнаружили нечто занимательное, стоит еще раз повторить шаги, вдруг вы поймете, что внешне разные проблемы связаны между собой на более высоком уровне абстракции, или же найдете дополнительные способы их решения.

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

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

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

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

7.1.3. Баланс между теорией и практикой

7.1.3.1. Введение

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

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

7.1.3.2. Когда и как пользоваться теорией

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

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

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

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

Итак, вопрос разработки теоретических положений сохраняет актуальность до стадии альфа-версии или немного после нее. Когда будут объединены все элементы игры, можно будет более реалистично и пристально взглянуть на реальный продукт. Это время проверки истинности теории, согласно которой все это вместе должно работать (или нет). Именно в это время нужно скорректировать все теоретические предположения и посмотреть, на что они еще могут повлиять. Многие крупные ААА-проекты настолько сложны, что последствия тех или иных теоретических допущений станут понятны всем только спустя несколько недель.

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

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

7.2. Успех игрока

7.2.1. Введение

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

7.2.2. Игрок и разработчик

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

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

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

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

7.2.3. Опции и выборы игрока

7.2.3.1. Введение

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

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

7.2.3.2. Заставьте игрока почувствовать себя умным

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

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

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

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

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

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

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

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

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

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

7.2.4. Честность, разочарование и сложность

7.2.4.1. Введение

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

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

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

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

7.2.4.2. О случайности и удаче

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

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

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

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

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

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

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

• Случайные кодовые комбинации для дверей всегда лучше фиксированных, чтобы игроки не могли найти этот код в Интернете.

• Случайное количество/расположение менее важных предметов служит для придания колорита, например случайное расположение некоторых ресурсов или денег/боеприпасов.

• Случайные художественные элементы, такие как свет, текстуры и шейдерные эффекты, допустимы, если они соответствуют художественной концепции.⁴⁷

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

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

7.2.4.3. Винить себя, а не игру

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

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

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

7.3. Абстракция: высокий уровень

7.3.1. Введение

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

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

7.3.2. Мышление на высоком уровне

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

ИЛЛЮСТРАЦИЯ 7.1. Композиция «Моны Лизы», основанная на золотом сечении

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

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

7.3.3. Начать с упрощения

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

Степень симметричности высокоуровневых лэйаутов во многом зависит от целей противников. Так, например, карты режима «захват флага» (CTF, captrure-the-flag) обычно симметричны, потому что у обеих команд одинаковые цели. В режиме «обезвреживание бомбы» варианты лэйаута для обеих команд асимметричны, потому что у команд совершенно разные цели. Одиночные игры по умолчанию довольно асимметричны, как и их лэйауты.

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

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

ИЛЛЮСТРАЦИЯ 7.2. (a) Классический абстрактный лэйаут режима «захват флага». (b) Классический абстрактный лэйаут для режима с раундами и точками интереса. (c) Классический абстрактный лэйаут однопользовательской игры с открытым миром с целевой локацией в максимальном упрощении

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

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

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

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

Я советую посетить мой YouTube-канал Bauer Design Solutions и посмотреть пример абстрагирования в видео под названием «Абстрактная деконструкция de_dust2» (The Abstract Deconstruction of de_dust2). В нем я шаг за шагом объясняю, как сделать исходную карту более абстрактной, пока не останется только базовый высокоуровневый лэйаут или, как я считаю, «суть» лэйаута. Затем я размышляю, чему можно научиться на примере этой высокоуровневой композиции маршрутов, и пытаюсь создать на ее основе несколько новых лэйаутов.

7.4. Абстракция: средний уровень

7.4.1. Введение

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

7.4.2. Заметайте свои следы

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

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

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

7.4.3. Основные нюансы лэйаутов

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

7.4.3.1. Количество вариантов

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

7.4.3.2. Частота вариантов

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

7.4.3.3. Правильное размещение вариантов

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

7.4.3.4. Ритм вариантов

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

7.4.4. Варианты как ключевой элемент

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

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

ИЛЛЮСТРАЦИЯ 7.3. (a) Количество вариантов: (слева) хорошее; (справа) слишком большое. (b) Частота вариантов: (слева) быстрая часть; (справа) медленная часть. (c) Ритм вариантов: (слева) повторяющийся; (справа) нерегулярный

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

7.4.5. Основы дополнительных путей

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

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

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

7.4.6. Особенности игровых режимов

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

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

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

7.4.7. Трехмерное мышление

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

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