Итеративные процессы в левел-дизайне на опыте Fallout 3 и Skyrim

• 06 июля, 2015
• 10 комментариев

В марте 2014 года, на конференции GDC, в рамках серии докладов Level Design in a Day, Joel Burgess прочел лекцию про итерации в левел-дизайне, которые использовались в разработке Fallout 3 и Skyrim. Эта лекция значительно повлияла на мои представления о разработке игр. И хоть прошло больше года с данного выступления, лекция по прежнему актуальна. Особенно для многих разработчиков стран СНГ, которые по своим процессам отстают на много лет от практик таких опытных компаний, как Bethesda.

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

Сначала я хотел сделать полный перевод транскрипции лекции, которая лежит в открытом доступе на сайте Джоэла. Однако, я так себе переводчик, поэтому лучше расскажу своими словами, плюс добавлю немного (много) отсебятины. Для любопытных — это будет приглашением почитать оригинал, а для ленивых – это будет лучше, чем ничего. И небольшой дисклеймер, что хоть данная лекция базируется на принципах, по которым создавался Fallout 3 и Skyrim, но она не про разработку этих игр, а про виденье Джоэлом процесса итераций. Лучшие практики, так сказать.

Немного о Джоэле. В разработку игр он пришел в 2001 году. С 2005 года работает в Bethesda Softworks, то есть уже 10 лет как. Отвечал за левел-дизайн в TES IV: Oblivion, Fallout 3 и TES V: Skyrim, включая дополнения. Судя по его твиттеру не сложно догадаться над каким следующим проектом Bethesda он работает. Также с 2010 года выступает на конференциях с лекциями по левел-дизайну.

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

Итерации класса Шпион в Team Fortress 2

Начнем с самой простой итерации — структурной. Составили план, сделали, получили финальный продукт.

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

Казалось бы, вот он, идеальный путь создания хороших качественных игр. Вот только с ними одна загвоздка: при разработке таким способом срок выхода проекта будет “when it’s done”. Хорошо так делать, когда вы бессмертны и имеете бесконечный запас денег. Но в реальном мире нужно уметь достигать качества в заданные сроки. А значит, нужно строить процесс, оптимизирующий итерации, чтобы получить максимально возможное качество к заданному сроку.

Примером результата такого процесса может служить Skyrim. Кто играл в эту игру, тот знает как много контента в этой игре: огромный открытый мир, 5 больших городов, 300+ подземелий, 140+ точек интереса, 37 населенных пунктов. При этом над игрой работало всего 7 левел-дизайнеров. На этом моменте у продюсеров, читающих это, должна пойти слюна.

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

1) К тому времени Bethesda была уже устоявшейся студией, со сформированными командами, пайплайнами для кода и арта, многочисленными тулзами.
2) Минимальная текучка кадров позволила в начале проекта рассчитывать возможности команды. Сколько дизайнеров было в начале, столько будет и в конце. Никаких планов «мы наймем ещё 100 человек, и они нам всё сделают».
3) Высокое качество жизни. Отсутствие кранчей. Понятное дело – пункт спорный. Как это геймдев и без кранчей? Но Джоэл уверен, что реалистичное планирование наперед способно уберечь от внезапной работы в овертайме.

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

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

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

Вот только в Bethesda другой подход.

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

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

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

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

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

На этом можно было бы закончить. Этой информации достаточно, чтобы повысить производительность, поднять качество и при этом остаться в рамках плана по времени и деньгам. Это как с примером, когда надо написать строку «1 А I 2 Б II 3 В III 4 Г IV 5 Д V 6 Е VI 7 Ё VII 8 Ж VIII 9 З IX» последовательно, символ за символом, и по очереди, сначала все арабские цифры, затем все буквы, затем все римские числа. На его примере видно, что лучше сначала закончить все задачи одного типа, прежде чем переключаться на задачи другого типа.

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

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

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

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

Этапы слой за слоем формируют продукт

Нулевой этап – Концепт

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

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

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

Также на этом этапе уделяется внимание истории. Это не обязательно та история, которая будет подаваться игроку через диалоги и тексты. Это история места, необходимая левел-дизайнеру, в первую очередь, для внутренних нужд разработки. В ней он отвечает на вопросы что это за сооружение, зачем оно построено и кем? Что случилось здесь в прошлом? Что произошло незадолго до прихода игрока? Даже если эта информация не подается игроку напрямую, она необходима для поддержания консистентности и понимания, какие ассеты понадобятся для рассказа этой истории через окружение (environmental storytelling).

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

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

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

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

Типичная схема локации на нулевом этапе

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

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

Первый этап – Планировка

В Bethesda есть такой термин Kit (набор, конструктор) — это набор элементов одного сеттинга, из которых собирается локация в данном сеттинге. Как это выглядит, можно посмотреть на этом видео:

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

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

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

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

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

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

По той же причине, что на этом этапе локация может несколько раз пересобираться на основе фидбека, на ней не делается навмеш (Navigation Mesh), необходимый для навигации AI по уровню. А как следствие, на уровнях не расставляются противники и прочие NPC. Разве что может быть несколько единичных штук для отладки. Но это кухня геймдизайнеров и программистов, левел-дизайнеру сейчас ни к чему расставлять на своём уровне то, что не работает, а следовательно не может быть проверено плейтестом.

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

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

Второй этап — геймплей

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

Основной фокус этого этапа — сражения с противниками (энкаунтеры). В первую очередь, чтобы почувствовать темп игры. Как много противников надо, какого типа, в каких количествах, как часто? Также это хорошее время, чтобы подумать о луте (loot). Где игрок найдет восстанавливающие здоровье зелья, где обнаружит секретный проход к сокровищам, а где наткнется на сундук, охраняемый боссом.

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

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

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

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

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

На что похожа оптимизация в Skyrim, можно посмотреть на этом видео:

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

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

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

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

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

Этап третий — Весь контент готов

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

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

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

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

Тут следует признаться, что на самом деле в Bethesda третий этап называется не Content Complete, а Ship With Shame (“продавать со стыдом”). Потому что если что, в конце этого этапа игру можно выгружать в магазины. Контент есть, фичи есть, а значит технически всё на месте.

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

Третий этап — это ещё трамплин во “время возможностей”. На нем самое время посмотреть что в игре можно исправить. Если какие-то механики не работают достаточно хорошо, то нужно подумать, как дать им второй шанс. В Bethesda не любят выкидывать работу, поэтому заранее планируют время для так называемых mulligan pass, возможности переделать нужный элемент ещё раз.

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

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

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

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

Бонусный этап — Этап красоты

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

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

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

Пока идет этап красоты, левел-дизайнеры подготавливаются к следующему этапу.

Финальный этап

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

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

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

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

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

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

Перспектива

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

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

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