Продюсер игры Armored Warfare в Mail.Ru Group Ярослав Кравцов опубликовал на своём сайте адаптированный перевод лекции старшего разработчика студии Bethesda (The Elder Scrolls, Fallout) Джоэла Бёрджесса о том, как устроен процесс level-дизайна в компании.
Редакция рубрики «Рынок игр» публикует текст с разрешения автора.
В марте 2014 года на конференции
Games Developers Conference в рамках серии докладов Level Design in a Day Джоэл Бёрджесс прочёл лекцию про итерации в level-дизайне, которые использовались в разработке Fallout 3 и Skyrim. Эта лекция значительно повлияла на мои представления о разработке игр. И хоть прошло больше года с данного выступления, лекция по-прежнему актуальна. Особенно для многих разработчиков стран СНГ, которые по своим процессам отстают на много лет от практик таких опытных компаний, как Bethesda.
Как часто приходится слышать фразу «Нужно делать сразу в финальном качестве, так как потом у нас не будет времени вернуться к этому контенту». Доля правды в этом есть, но давайте посмотрим на другую точку зрения. Можете с ней не соглашаться, но прочтя этот текст вы сможете расширить свой кругозор, что никогда не бывает лишним.
Сначала я хотел сделать полный перевод
транскрипции лекции, которая есть в открытом доступе на сайте Джоэла. Однако, я так себе переводчик, поэтому лучше расскажу своими словами, плюс добавлю немного (много) отсебятины. Для любопытных это будет приглашением почитать оригинал, а для ленивых это будет лучше, чем ничего. И небольшой дисклеймер: хоть данная лекция базируется на принципах, по которым создавался Fallout 3 и Skyrim, но она не про разработку этих игр, а про видение Джоэлом процесса итераций. Лучшие практики, так сказать.
Немного о Джоэле. В разработку игр он пришел в 2001 году. С 2005 года работает в Bethesda Softworks, то есть уже 10 лет. Отвечал за level-дизайн в
The Elder Scrolls IV: Oblivion, Fallout 3 и The Elder Scrolls V: Skyrim, включая дополнения. По его профилю в Twitter не сложно догадаться, над каким следующим проектом Bethesda он работает. Также с 2010 года выступает на конференциях с лекциями по level-дизайну.
С итерациями в разработке мы все знакомимся достаточно быстро. Берём блестящую идею, реализуем, смотрим на результат, чешeм затылок и всё переделываем. Или, как минимум, отправляем её обратно в разработку со списком багов в придачу. А раз мы все проходим через процесс итераций, так давайте посмотрим, как этот процесс можно оптимизировать.
Итерации класса Шпион в Team Fortress 2
Начнём с самой простой итерации —
структурной. Составили план, сделали, получили финальный продукт.
Здравый смысл подсказывает, что так просто не бывает. Как минимум, для того, чтобы финальный результат был кому-нибудь интересен, нужно, чтобы была гарантия качества. А значит, прежде чем отдавать продукт наружу, нужно его поплейтестить, обработать результаты плейтеста, поплейтестить изменения и так далее. Такую итерацию назовем
качественной.
Казалось бы, вот он, идеальный путь создания хороших качественных игр. Вот только с ними одна загвоздка: при разработке таким способом срок выхода проекта будет «when it’s done». Хорошо так делать, когда вы бессмертны и имеете бесконечный запас денег. Но в реальном мире нужно уметь достигать качества в заданные сроки. А значит, нужно строить процесс, оптимизирующий итерации, чтобы получить максимально возможное качество к заданному сроку.
Примером результата такого процесса может служить Skyrim. Кто играл в эту игру, тот знает, как много в ней контента огромный открытый мир, пять больших городов, более 300 подземелий, более 140 точек интереса, 37 населенных пунктов. При этом над игрой работало всего семь level-дизайнеров. На этом моменте у продюсеров, читающих это, должна пойти слюна.
Конечно, не все могут просто так работать с такой эффективностью. Джоэл подмечает три отличия от других студий, которые помогли достигнуть таких результатов:
- К тому времени Bethesda была уже устоявшейся студией, со сформированными командами, пайплайнами для кода и арта, многочисленными тулзами.
- Минимальная текучка кадров позволила в начале проекта рассчитывать возможности команды. Сколько дизайнеров было в начале, столько будет и в конце. Никаких планов «мы наймем ещё 100 человек, и они нам всё сделают».
- Высокое качество жизни. Отсутствие кранчей. Понятное дело — пункт спорный. Как это геймдев и без кранчей? Но Джоэл уверен, что реалистичное планирование наперёд способно уберечь от внезапной работы в овертайме.
Обычно, когда мы хотим сделать уровень, то процесс создания разбиваем на этапы. Сначала напишем дизайн, затем набросаем болванку, после доведем её до приличного состояния и затем почистим от багов. Создавая уровень, мы идем от одного этапа к другому. Назовём такой подход
последовательными итерациями.
И если в игре должно быть несколько уровней, то каждый из них делаем также последовательно. Этот месяц фокусируемся на разработке уровня А, затем следующий месяц — уровень Б, а потом — уровень В.
Вот только в Bethesda другой подход.
Фокусировка разработки может идти не на уровнях, а на их этапах. Сначала делается первая стадия для всех уровней и пока она не будет завершена, ни один из уровней не перейдёт во вторую фазу.
Особая магия такого подхода состоит в том, что между последующими фазами одного уровня проходит некоторое время, пока дизайнер работает над фазами других уровней. За это время дизайнер успевает многое узнать про свой уровень и в начале следующей фазы иметь гораздо больше полезной информации, чем если бы он приступил к этой фазе сразу же после предыдущей.
За время между фазами дизайнер успевает набраться опыта, работая над другими уровнями, собрать обратную связь с плейтестов и получить отчёт от команды QA. Если бы паузы не было, то обратная связь от предыдущей фазы приходила посреди работы над текущей фазой и спутывала планы.
Также эти паузы позволяют дизайнеру отдохнуть от уровня и вернуться к нему со свежим взглядом.
Ещё такой подход позволяет справиться с ростом проекта. И это очень важный момент. Ведь в разработке всегда присутствует элемент хаоса, когда обнаруживается, что надо что-то сделать, что не было изначально запланировано. Чем более смелую игру вы делаете, тем больше у вас будет таких сюрпризов. А значит, будут моменты, когда обнаружится, что level-дизайнеру для продолжения работ над уровнем потребуется что-то от программистов или художников. Создание кода и арта также требует времени. И хорошо, что при таком подходе к итерациям у дизайнера уже запланировано время на ожидание.
На этом можно было бы закончить. Этой информации достаточно, чтобы повысить производительность, поднять качество и при этом остаться в рамках плана по времени и деньгам. Это как с примером, когда надо написать строку «1 А I 2 Б II 3 В III 4 Г IV 5 Д V 6 Е VI 7 Ё VII 8 Ж VIII 9 З IX» последовательно, символ за символом, и по очереди, сначала все арабские цифры, затем все буквы, затем все римские числа. На его примере видно, что лучше сначала закончить все задачи одного типа, прежде чем переключаться на задачи другого типа.
Мы поговорили о планировании разработки уровней. Но разве это единственная обязанность level-дизайнера? К примеру, в Bethesda level-дизайнер также пишет книги, диалоги, участвует в системных дизайнах вроде крафтинга, комбата или баланса, прототипирует фичи на внутреннем скриптовом языке, работает с программистами над внутренними инструментами, и выполняет много разных других задач, которые возникают по ходу разработки проекта.
У данного подхода два преимущества. Во-первых, студия может обходиться небольшим количеством разнопрофильных специалистов, вместо того, чтобы содержать огромный штат узкопрофильных разработчиков. Дизайнеров можно прокачивать, давая им задачи по теме, в которой они слабы. Например, если есть потребность заскриптовать прототип, то эта задача упадет на level-дизайнера, которому требуется улучшить навыки скриптования. Само собой, не требуя от него невозможного. Расширяя круг способностей дизайнера, можно сделать его более полезным для студии в долгосрочной перспективе.
Во-вторых, это позволяет level-дизайнерам оставаться продуктивными на протяжении всей разработки. Ведь в начале проекта level-дизайнеру особо не с чем работать. Нет ни кода, ни арта. Поэтому он может заниматься другими задачами. А ближе к концу проекта большинство систем готово, но зато неимоверно много работы для level-дизайнера.
Если бы речь шла о команде узкоспециализированных специалистов, то пришлось бы level-дизайнеров нанимать во время разработки проекта, так как в начале разработки им нечего было бы делать. И наоборот, пришлось сокращать штат других специалистов.
В Bethesda такой подход называют «Opportunity Time» (время возможностей). Когда в каждый момент времени у дизайнера есть ряд возможностей что-то улучшить в игре. Вопрос в том, что он выберет, чтобы максимально эффективно использовать это время. Для этого нужно понимать, какое сейчас время на проекте. Для этого представим разработку как набор этапов. Вроде примера с разбиением разработки уровня на составляющие, только в масштабах всего проекта.
Этапы слой за слоем формируют продукт
Нулевой этап – концепт
Это этап планирования. Ещё нет игры. Нет кода и арта, с которыми можно было бы работать. Зато можно работать над списком. Списком всех локаций и ивентов. Это как слот-машина, на одном барабане которой архитектурный сеттинг, на другом — тип геймплея, на третьем — место на глобальной карте и так далее. Дергаешь за ручку и получаешь новый пункт для списка локаций.
Так level-дизайнер получает на руки короткое задание сделать локацию Ветреный Пик: размер большой, использует сет нордических руин и населена драургами. Обычно это вся информация, что есть у level-дизайнера. Лишь изредка, когда локация делается под квест, появляются дополнительные уточнения.
Первый шаг для level-дизайнера — описать на вики (или где вы ведёте документацию), что он хотел бы сделать на своей локации. Коротко и ёмко, в один-три абзаца. Лаконичность требуется специально, чтобы не размывать фокус и сосредоточиться на тех вещах, которые выделят локацию среди остальных.
Также на этом этапе уделяется внимание истории. Это не обязательно та история, которая будет подаваться игроку через диалоги и тексты. Это история места, необходимая level-дизайнеру, в первую очередь, для внутренних нужд разработки. В ней он отвечает на вопросы:что это за сооружение, зачем оно построено и кем? Что случилось здесь в прошлом? Что произошло незадолго до прихода игрока? Даже если эта информация не подается игроку напрямую, она необходима для поддержания консистентности и понимания, какие ассеты понадобятся для рассказа этой истории через окружение (environmental storytelling).
К слову о списке ассетов. С одной стороны, не надо вдаваться в крайность и записывать каждую вариацию стены или пола. И вместо этого сосредоточиться только на тех объектах, которые составляют уникальность данной локации.
С другой стороны, список ассетов не должен быть слишком абстрактным. Например, если у вас есть идея о пазле, в котором игроку нужно позвонить в несколько колокольчиков, то не надо писать кратко «пазл с колокольчиками» в ассет-лист. Ведь колокольчиков потребуется несколько видов, они должны быть анимированы и озвучены — всё это надо расписать заранее, чтобы понимать, каков объём работы и какие специалисты потребуются.
Следует упомянуть не только то, что делается на этом этапе, но и то, что делать не следует. Ведь мы говорим об эффективном использовании времени, а как можно назвать эффективной ту работу, которую потом придется переделывать с нуля. Например, если имея минимум объектов, вы начнёте их расставлять, заполняя уровень, то потом, когда появятся новые объекты, вам придется удалить как минимум часть проделанной работы.
Так, на нулевом этапе дизайнер не запускает редактор. Даже если есть немного ассетов, с которыми можно работать. Потому что это будет впустую потраченным временем.
Также на этом этапе создается общая карта локации, без детализации. Внимание уделяется тому, какие сущности будут на карте и как они связаны друг с другом.
Типичная схема локации на нулевом этапе
Ещё на этом этапе не надо увлекаться раздуванием документации. Как, например, двенадцатистраничный документ, описывающий полчаса геймплея. Часть которого состоит из небольших предысторий, вроде истории о вражды между братьями, которые производят топливо, используемое ховеркрафтом, который появляется на секунду только в определенной сцене появления противников. Такие вещи хороши для флавора, но не на данном этапе. Если ты не можешь свести свою документацию к минимуму, значит, ты не понимаешь сути этапа. То, что ты любишь расписывать подобные детали — это твоё лично дело, не команды и не игрока.
Нулевой этап повторяется раз за разом, пока не будет покрыт весь предполагаемый контент. На это уходит несколько недель. При этом остальная часть команды тоже занята, а значит, к тому моменту, когда level-дизайнеры закончат свою работу, состояние проекта будет уже другим.
Первый этап – планировка
В Bethesda есть термин Kit (набор, конструктор) — это набор элементов одного сеттинга, из которых собирается локация в данном сеттинге. Как это выглядит, можно посмотреть на видео:
На нулевом этапе художники по окружению (environmental artists), работая в тесном контакте с level-дизайнерами, создают заготовки для этих конструкторов. В первую очередь от них требуется соблюсти габариты и пивоты (pivot points), чтобы где level-дизайнер поставил объект, там он и остался, когда превратится из болванки в финальную модель.
На первом этапе задача level-дизайнеров — собрать болванки всех локаций из тех конструкторов, что есть. Да, на этом этапе уровни будут выглядеть уныло, пусто, без освещения и деталей. Но зато уже будет понимание ритма, потока, которое задает пространство. А красота придёт позже, на следующих этапах.
К тому же проверка конструктора в деле. Художники получают первую обратную связь как по технической части, так и достаточно ли элементов. Лучше потратить время сейчас на добавление новых элементов, чем потом страдать от попыток впихнуть новый элемент в уже собранную локацию. Конечно, ожидание новых элементов конструктора тормозит level-дизайнера, давая ему время для других активностей.
Этот этап level-дизайнеры Bethesda используют для написания книг, которые пользователь может найти в игре. Поскольку данная активность является опциональной, только для тех игроков, кто хочет закопаться в историю игрового мира, то её будет невозможно делать на поздних этапах, когда вовсю давят сроки.
Также на этом этапе наводится порядок в тех сущностях, которые обычно не изменяются в течение разработки. Например, названия, расположение на карте, расстановка маркеров, настройки локаций.
В течение этого этапа также есть ряд вещей, которые level-дизайнеры сознательно не делают. Например, оптимизацию. Да, движок требователен к level-дизайнерам, которые должны расставлять на своих уровнях различные оптимизационные штуки. Но это следует делать не раньше, чем level-дизайнер получит обратную связь в течении этого этапа, что локация получилась цельной и больших переделок больше не потребует.
По той же причине, что на этом этапе локация может несколько раз пересобираться на основе обратной связи, на ней не делается навмеш (Navigation Mesh), необходимый для навигации AI
(искусственный интеллект — прим. ред.) по уровню. Как следствие, на уровнях не расставляются противники и прочие NPC. Разве что может быть несколько единичных штук для отладки. Но это кухня геймдизайнеров и программистов, level-дизайнеру сейчас ни к чему расставлять на своём уровне то, что не работает, а следовательно, не может быть проверено плейтестом.
По тем же причинам level-дизайнеры не занимаются освещением и расстановкой мелких объектов. Вместо этого level-дизайнеры занимаются арт-хаками, используя имеющиеся ассеты для создания иллюзии новых ассетов, которых нет в конструкторе. Например, когда нужен мост, то дизайнер берет стену и поворачивает её. Или, например, делает из шкафа стол.
Такой подход позволяет получать больше разнообразия при ограниченном количестве ассетов. И, как видно по скриншоту, многие из этих решений доживают до релиза. Конечно, на данном этапе не стоит увлекаться такими хаками, ведь этот этап не про наведение красоты, а про проверку конструкторов. Так что если дизайнер решил, что ему нужен стол, и проверил эту идею с помощью шкафа, то ему не стоит оставлять всё как есть. На этом моменте он должен пойти к художникам и сообщить о том, что ему нужен стол, и он твердо в этом уверен, так как проверил идею в игре.
Второй этап — геймплей
Работа на этом этапе — что-то вроде Vertical Slice. В том смысле, что к его концу игра будет выглядеть относительно законченной. На этом этапе ускоряется работа над кор-механиками, поскольку появляется возможность проверить их в разных локациях, энкаунтерах и типах оружия. Как во время работы над VS, знания и опыт, полученные на работе над одними уровнями, помогают в дальнейшем на других уровнях.
Основной фокус этого этапа — сражения с противниками (энкаунтеры). В первую очередь, чтобы почувствовать темп игры. Как много противников надо, какого типа, в каких количествах, как часто? Также это хорошее время, чтобы подумать о луте
(loot, термин для обозначения трофеев, найденных персонажами игроков на телах убитых монстров — прим. ред.). Где игрок найдет восстанавливающие здоровье зелья, где обнаружит секретный проход к сокровищам, а где наткнется на сундук, охраняемый боссом.
На этом этапе дизайнеры также работают над скриптовыми сценами. От диалога, который игрок может подслушать, до выбегающих в коридор противников при приближении игрока.
Для того, чтобы работать с энкаунтерами, необходимо создать навмеш. Его придется поддерживать на протяжении всех последующих этапов, поэтому лучше сейчас сделать его достаточно качественно, чтобы потом сэкономить время на его поддержке.
Как говорилось раньше, между последующими этапами одного уровня проходит достаточно времени, чтобы собрать обратную связь. Получив обратную связь с первого этапа, level-дизайнер обрабатывает её на втором этапе. А значит, вносит правки в расположение базовых элементов уровня. Поэтому тут нужно не напутать с последовательностью действий, создав навмеш там, где потом всё будет переделано.
Говоря о геймплее, нужно понимать, что он не только про то, чтобы тыкать в людей заостренным концом оружия. Если у вас есть план на небоевое действие, вроде пазлов или диалогов, то самое время сделать их хотя бы на уровне болванки, чтобы проверить свою идею в геймплее и узнать её влияние на темп игры.
Как ни странно, на этом этапе level-дизайнеры занимаются оптимизацией. Казалось бы, зачем? Ведь помещения на уровнях пока ещё пустые и проблемы с оптимизацией незаметны. А если заметны, то это потому, что код находится на ранних стадиях. Так какой же смысл тратить время на работу по оптимизации? А смысл в том, что раз дизайнер закончил менять расположение крупных элементов на своём уровне, то значит, он может заняться оптимизацией их видимости.
На что похожа оптимизация в Skyrim, можно посмотреть на этом видео:
Работа по оптимизации довольно утомительная, но её так или иначе придётся сделать. Так что лучше сделать её пораньше, чтобы на поздних этапах освободить время на задачи, которые делают игру лучше, а не просто запихивают под требуемый FPS.
Есть несколько вещей, которых нужно избегать на этом этапе. Во-первых, нужно подавить в себе желание удалить уровень и переделать его с нуля. Конечно, прошло достаточно времени и появились новые ассеты, а в голове полно новых идей, которые кажется проще сделать с чистого листа, чем пытаться вставить в имеющийся уровень. Но это лишь условный рефлекс, результатом которого будет просто другой уровень, который не обязательно окажется лучше предыдущего. Он просто будет другим. А значит, подобная переделка — лишь трата времени, бесполезная работа.
Также на этом этапе избегается работа по тщательному скриптованию. Как писалось выше, для проверки в геймплее хватит чернового качества. Но если вы потратите время и всё тщательно заскриптуете, то есть шанс, что после проверки плейтестом получите обратную связь о неуместности пазла и необходимости выкинуть всю проделанную работу.
На этом этапе level-дизайнеру будет приходить много обратной связи. Художники на его локациях будут отсматривать свои конструкции. Геймдизайнеры и программисты будут проверять свои фичи, бегая по его уровням. Возможны показы уровня на проекторе, когда целая группа лиц будет давать устные комментарии. А также уровень будет в обязательном порядке отсмотрен ведущим level-дизайнером и художником.
Ключевой момент в работе с обратой связью — не реагировать на неё. По крайней мере, не делать этого немедленно. Ведь это так легко — отвлечься на хорошее предложение, которое на самом деле очередное «как сделать по-другому», а не «как сделать лучше». Так что всю обратную связь надо записывать, каталогизировать, но реагировать лишь спустя достаточное время, чтобы накопить замечания, приоритизировать и определить, как какие пункты обрабатывать.
Этап третий — весь контент готов
На этом этапе задача level-дизайнера — убедиться, что на его уровне не осталось ничего упущенного, временного, сломаного и неучтённого. Конечно, level-дизайнер не может отвечать за производство арта, а следовательно, не в его силах нарисовать текстуру или обновить модель. Его задача — вести учёт всего, чего не хватает для его уровня. И если оказалось, что в расписании художников упущен какой-то контент, то начинать решать этот вопрос как можно раньше.
Конечно, расписание не резиновое, так что придется что-то отрезать или искать альтернативное решение. Чем дольше такие решения будут затягиваться, тем больше они выйдут боком.
К этому моменту у level-дизайнера есть геймлей, собранный в общих чертах, и обратная связь, полученная после второго этапа. Самое время обработать обратную связь и привести геймплей к законченному виду. Также на третьем этапе прошли проверку геймплеем системные дизайны. Теперь это не пачка витающих в воздухе идей, а вполне конкретные механики. А значит, вместе с ними приходит понимание, как их лучше использовать на своих уровнях. Лучше сейчас интегрировать их на свои уровни, чем пытаться вставить на более поздних этапах.
Каждый уровень на третьем этапе имеет свою особенность. Где-то level-дизайнеру требуется уделить больше времени скриптованию, чем всему остальному. Где-то его фокусом будет комбат. А где-то — окружение. Тут level-дизайнер должен понимать, что является главным на его уровне, чтобы правильно расставить приоритеты при планировании времени.
Как ни странно, но на этом этапе не уделяется время оптимизации. Это кажется странным, ведь ей столько внимания было уделено на предыдущем этапе. Дело в том, что на третьем этапе работа по оптимизации будет носить профилактический характер и особых результатов не даст.
Тут следует признаться, что на самом деле в Bethesda третий этап называется не Content Complete, а Ship With Shame («продавать со стыдом»). Потому что если что, в конце этого этапа игру можно выгружать в магазины. Контент есть, фичи есть, а значит технически всё на месте.
Конечно, готовый контент ещё не означает высокое качество игры. Третий этап в основном не про качество, а про уверенность. Уверенность, что все уровни будут готовы согласно плану. И, что более важно, уверенности в том, что можно повысить уровень качества за то время, что пройдет между концом третьего этапа и настоящим релизом. В отличие от последовательной разработки, когда часть уровней к этому моменту не будут существовать даже в виде дизайна на бумаге.
Третий этап — это ещё трамплин во «время возможностей». На нём самое время посмотреть, что в игре можно исправить. Если какие-то механики не работают достаточно хорошо, то нужно подумать, как дать им второй шанс. В Bethesda не любят выкидывать работу, поэтому заранее планируют время для так называемых
mulligan pass — возможности переделать нужный элемент ещё раз.
Никто не любит, когда их уровни вырезают из игры. Но порой приходится идти на такие меры. Потому что если выбирать — потратить усилия на доведение хорошего уровня до великолепного или подтянуть плохой уровень до среднего, — то, конечно же, выбор за первым вариантом. Наличие великолепных уровней более полезно в дальнейшей перспективе, чем наличие средних уровней.
Другой доступный инструмент — это «ударные команды» (Strike Team). Подобную практику используют многие студии. Это когда команда разнопрофильных специалистов фокусируется на решении определённой задачи. Например, «ударная команда» берёт фичу, которой уделялось недостаточно внимания, и доводит её до состояния, когда ей можно пользоваться и тестировать. Или чтобы «заполишить» контент, который расположен на видном месте. Также «ударная команда» может собраться вокруг дизайнера, чтобы помочь ему справиться со сложной или амбициозной задачей.
Конечно, самый простой способ решения проблем — это добавление рабочих часов, кранч. Но, как говорилось раньше, в Bethesda не любят кранчи и считают их последней мерой. Представьте, что ваш контент хотят отрезать. Вы приходите к своему лиду и говорите, что сможете решить проблему, поработав сверхурочно. Но как лид вам поверит, если вы и так работаете шесть дней в неделю и задерживаетесь по вечерам? Какие ещё дополнительные часы?
К тому же, даже если разрешить такой овертайм, то велик риск ментальных нарушений, снижения производительности, принятия плохих решений и большее количество производимых багов. Так что выгода от таких кранчей сомнительная.
Конечно, если вы работаете разумное количество часов, то короткий кранч может быть инструментом для заделывания дыр. Но это очень тупой инструмент, применив который, вы никого не впечатлите.
Бонусный этап — этап красоты
После того, как третий этап закончен, приходит бонусный этап наведения красоты и порядка. Команда художников переходит от создания нового контента к улучшению имеющегося. Оптимизация выходит на первый план. Дизайнеры и художники должны сделать всё необходимое со своей стороны. Чтобы если на уровне обнаруживается проседание производительности, то программисты знали, что это что-то в коде, а не потому что на уровень прошлым вечером залили новый контент.
На этом этапе над уровнем работают художники, добавляя мелкие объекты окружения, эффекты и настраивая освещение. А звуковой инженер делает свой проход по уровню. Level-дизайнер на этом этапе держит руки в стороне от своего уровня. Художники сделают работу по оформлению быстрее и лучше, освободив level-дизайнера для других задач.
Главная задача level-дизайнера — не убирать руки слишком далеко. Необходимо быть в контакте с художниками и помогать им, если есть затруднения. В том числе не относиться к художникам как к уборщикам, которые прибирают за level-дизайнером тот бардак, что он им оставил.
Пока идёт этап красоты, level-дизайнеры подготавливаются к следующему этапу.
Финальный этап
Финальный этап настаёт, когда игра на полном ходу приближается к релизу. Это шанс сделать так, чтобы игра была выпущена с максимально качественным контентом, который команда способна сделать. Так что задача этого этапа довольно очевидная — «полишить» всё.
Этот этап про то, чтобы акцентироваться на всём хорошем, что есть на уровне, и убрать или поправить всё плохое. Возможность уделить больше внимания поздней части игры. А если какая-то интересная комбинация врагов и оружия ещё не встречалась, то самое время её вставить в уровень, который вы сейчас «полишите».
Обратная связь от команды будет приходить волнами в течение всего этапа. Каждый раз давая level-дизайнеру понять, как игроки видят его уровень, что выделяет и на чём стоит сосредоточить усилия.
На этом этапе требуется навести порядок во всей внутренней кухне, которую не видит игрок, но которая важна для игры. Это и оптимизация, и финальная настройка навмешей, и правильные настройки в свойствах локации, и всё остальное, что требуется для полной функциональности на уровне.
Ещё одно маленькое признание. Этот этап не называется четвёртым, потому что четвёртый этап не обязательно будет финальным. На этом этапе проходят плейтесты, на которых решается, оставить уровень на дальнейшую доработку или он прошёл этап. Таким образом, какие-то уровни остаются неизменными до релиза сразу после четвёртого этапа, а какие-то уровни уходят на пятый, шестой, седьмой этапы и так далее. Иногда по причине, что контент не соответствует ожиданиям, но чаще всего потому, что виден потенциал, как ещё его можно улучшить.
Таким образом, первые этапы концепта, планирования, геймплея и готовности контента являются структурными итерациями. Во время них делается то, что должно быть сделано так или иначе. Ни один из шагов этого этапа нельзя пропустить. При этом тестирование и «полишинг» на этом этапе не требуются — для них есть следующие этапы, являющиеся качественной итерацией.
В этом главная идея процесса. «Время возможностей», при котором можно качественно улучшать игру, наступает на поздних стадиях проекта, поэтому нужно освободить время на этих этапах, перенеся часть работ на ранние стадии.
Перспектива
Немного мыслей о перспективах. Довольно легко увлечься чем-то определённым при работе над игрой, и не заметить, как большой кусок игры остался низкого качества. Подобные процессы, когда дизайнер отвечает за множество аспектов игры, постоянно между ними переключается и шаг за шагом участвует в продвижении разработки, позволяют дизайнеру сохранить равноправность элементов игры в своих глазах.
Каждый разработчик игр должен помнить, что не существует такого понятия, как полностью законченная игра. Не бывает такого разработчика, который после релиза не скажет, что в игре есть, что ещё улучшить или пофиксить.
Когда работаешь над играми, особенно такими большими, требующими три-четыре года разработки, то не нужно быть гением, чтобы прикинуть, сколько таких игр ты сможешь сделать за свою жизнь. Перспектива даёт понять, как лучше распределить своё здоровье, чтобы не слить его на одну-две игры, а делать их на протяжении всей своей жизни.
About the author
