Level design Ver 2.0
· Что такое дизайн уровней.
· Роль дизайнера уровней
· Predproduction: Концептуальность и функциональность.
· Препарация игрового уровня. Кратко.
· Не навреди. Базовые понятия технических ограничений.
· Продвинутый инструментарий.
· Масштабы и метрика
· Graybox прототипирование.
· Modular level design
· Фокус сражения и постановка геймплея
· Восприятие
· Повествование
· Что такое дизайн уровней.
· Роль дизайнера уровней
Разработка игр любого жанра это сложный и комплексный процесс из за самого понятия интерактивного искусства.
В корне разработки можно выделить три основных элемента:
Геймдизайн - будь то геймплей и игровые механики, вплоть до нарратива и сюжетного повестования.
Арт - вся визуальная часть.
Техническая часть - определяет всю реализацию игрового процесса и визуального отображения.
Ошибочно предполагать что все эти элементы могут быть созданные в отрыве друг от друга.
Каждый “безликий технический” скрипт влияет на восприятие игрового процесса и его стабильность.
Оттенок текстуры стены может повлиять на баланс уровня.
Грамотно выставленная композиция объектов может рассказать больше сюжета чем часовой монолог актера.
Так получилось, что Дизайнер уровней - специализация которая сочетает в себе все три основных элемента разработки из за чего сама его роль порой очень размыта или разбросана на сразу несколько отделов или специалистов.
Не важно как называция специализация разработчика - если на нем лежит ответственность создать контент который относится к разработке уровней и игрового мира то его можно назвать Дизайнером уровней.
Дизайнер уровней - это геймдизайнер. Он задает игровой процесс через геометрию.
Дизайнер уровней - это нарративный дизайнер. Палитрой объектов и окружением он рассказывает истории, кроме того он же может создавать квесты и события на уровнях.
Дизайнер уровней - это режиссер. Через освещение и композицию он задает темп повествования.
Дизайнер уровней - его первым будут пинать технические художники, так как любой качественно созданный ассет может “запорот” именно при его не грамотном использовании на этапе сборке уровня. Поэтому зачастую дизайнеры уровней сами по себе не плохие технические специалисты.
Дизайнер уровней в конце к концов художник.
Само понятие “Создание уровня” очень сильно масштабируется конкретно под особенности проекта.
В реалиях крупных проектов и огромных студий, создание уровней как правило распределенно на большое колличество специалистов.
Level Artist’ы работают с детализацией окружения.
Light Artist’ы освещают огромные объемы сцен по сложным техническим гайдлайнам начиная от ранних концептов и заканчивая работой в движке.
Environment Artist’ы моделируют и создают большое количество ассетов в паре с Level Artist’ами.
Весь этот огромный механизм разработки успешно работает еще благодаря техническим художникам создающие условия и функционал для создания уровней и контента.
В конце концов существуют даже специалисты по рассадке растительности.
Например при создании игры “Ведьмак 3” был художник отвечающий за создание лесов и полей.
Независимая разработка игр как правило не предпологает больших команд и сильной фрагментации задач. Поэтому роль дизайнера уровней в них незаметно воспроизводится либо Геймдизайнером либо художником.
Однако это ни в коем случае не означает более низкого качества проработки уровней.
Всегда решает скилл разработчика - а кем он себя позиционирует совершенно не важно.
· Predproduction: Концептуальность и функциональность.
Планирование разработки уровня можно абстрагировать до двух элементов.
Это Концепт и Механика.
Технические детали опускаем так как они касаются вообще всего предпродакшена контента и подготовки движка.
Концепт для создания уровня:
Это не только концепт арт по которому художники могут реализовать игровое окружение.
Важно утвердить то каким образом игрок будет исследовать и взаимодействовать с окружением, и то как окружение будет влиять на игрока.
Причем в случае сюжетных игр нет гарантий, что сценарий будет готов до начала производства уровня.
Может быть применим обратный процесс - например в “Готике” художники создавали сначала мир игры и лишь после сюжеты квестов.
Не только в плане концепт артов, но и заранее утверждали планировку игрового мира - где какая гора, где какая пещера, как далеко будет находится город и тп.
Это позволило сделать игровые квесты более сложными и комплексными, так как порой для описания цели квеста могло хватить лишь описания окружения.
В стиле “Сходи за горбатый холм что к северу от проклятого пня, найди там рощу и слева от рощи будет камень. За камнем вход в пещеру”.
Т.е условия квеста не были прописаны на интерфейсе, не было никаких прямых указателей и стрелочек - сам игровой мир был родоначальником квестов и историй.
Если не касаться основных и крупных квестов подобное сложнее встретить в том же “Skyrim” или “Ведьмаке”, так как дизайнеры квестов не могли до конца опираться на данные проектирования уровней ибо из за огромной сложности этих проектов у них почти до самого релиза происходили крупные изменения в структуре уровней.
Из за этого в повествовании порой были упрощения в виде “Иди в деревню с таким то названием” вместо подробного описания тропинок который бы привели игрока к этой самой деревне.
Интертекстуальность уровней и событий на них порой задается сюжетом - The Witcher.
Либо же самим окружением - Gothic.
В создании диалога между “ Сюжет - мир - геймплей ” важно не пропускать и художественный элемент предпродакшена - концепт арт.
Его задача не построить геймплей, отнюдь.
Важность скетчей проявляется в понимании самих разработчиков то какую атмосферу они хотят создать.
Протестировать композиционные решения, целостность визуальной идеи и цветовую палтиру.
Впрочем не стоит упускать возможность как можно раньше обращаться к референс ам.
Зачастую они не просто хранят в себе интересные элементы идей, но и могут в целом вдохновить и подтолкнуть к интересным решениям.
Сильно облегчает процесс прототипирования уровня (грейбоксинг) наличие схемы.
Кроме того схема позволяет на ранних этапах продумать игровые события, расставить важные игровые элементы такие как точка появления игрока, оружие и враги.
Схемы задают масштаб, позволяют прикинуть расстояния между объектами и расставить эти самые объекты. На них заранее можно продумать и проанализировать траекторию игроков, противников и NPC.
Показать разбор собственных схем локаций (Nival)
Порекомендовать книгу Predroduction Blueprint
· Препарация игрового уровня. Кратко.
(Показать какой либо мультиплеерный уровень Unreal tornament)
“Врач, не разбирающийся в строении человеческого тела, способен только навредить своему пациенту, то и дизайнер, не смыслящий в анатомии игрового пространства, никогда не сможет построить полноценный уровень.” (Михаил Кадиков, Crytek)
Сравнивая современные и старые игры нельзя не заметить то как возросло количество деталей на уровне.
И пусть технический аспект заметно вырос, все равно старые и новые (хорошие) игры доставляют нам порции отменного геймплея и атмосферы.
Суть в том, что изнутри уровни не поменялись.
И это самое “нутро” можно опять же разделить на три части.
Structure /MainForm/ - “силуэт” уровня, а точнее его основная геометрическая структура.
Самый важный аспект при создании интересного геймплея и передачи читаемости конкретной локации это ее форма.
Например на данном скриншоте есть огромное количество деталей, игровых объектов окружающего мира тут не так уж и много. В основном небольшие укрытия, но все равно они не настолько значительны что бы зачитывая в основную структуру уровня.
Если сбросить всю детализацию и оставить только основную геометрию в конкретном кадре то получится вот это:
Т.е “Земля” (Terrain), блоки зданий и забор который отрезает путь.
Причем не только мелкие укрытия в виде машин являются конкретно в этой игре всего лишь деталями. Но и мост на горизонте, не более чем композиционный арт объект.
(в играх типа Metal Gear вероятно машины все таки будут учитываться вместе с базовой геометрией из за особенностей геймплея)
Несмотря на свою примитивность и простоту - базовая структура уровня является первоочередным инструментом дизайнера уровней.
Она, а не детали - задает игровой процесс и влияет на баланс.
Под базовую геометрию попадают все важные формы влияющие и задающие структуру.
Визуальная детализация.
Пропсы, освещение, декали и материалы и т.д относятся и детализации и наполнению игрового пространства до финального результата.
Однако не стоит думать что детали задают лишь визуальное настроение сцены, они выполняют так же и функциональную роль для восприятия игрока.
Детали это объекты с помощью которых сцена режиссируется, подчеркивается навигация и функциональность.
Конечно самый простой пример это использование мелких деталей в виде укрытий, например машины.
К деталям можно отнести известные всем геймерам красные бочки которые дизайнеры уровней любезно расставляют под ногами всех противников.
Кусты в отличии от деревьев тоже засчитываются в детали, но они позволяют игроку прятаться либо спрятать противника.
Это явные примеры функциональности деталей.
Но например если оттенок стены сольется с оттенком камуфляжа противника - это опять же функционал детализации. Баг это или фича решать геймдизайнерам - но факт остается фактом, даже такая деталь может повлиять на игровой процесс.
Техническая часть
Это то, что игрок не видит.
Триггеры, зоны, порталы освещения и сами объекты освещения.
Навигационный меш для AI, порталы оклюзии, пробы света, пробы отражения, различные хэлперы и якоря.
Тут очень много различных страшных терминов и еще страшнее это выглядит в редакторе уровней.
Все технически аспекты зависят от типа проекта, архитектуры его реализации и конечно же движка. Подробно на этой части останавливаться не стоит, хоть она крайне важна в работе дизайнера. Без этого вы можете лишь придумать и набросать на бумаге уровень - что бы сделать его живым необходимо курить техническую документацию движков и гайдлайны проекта.
Продолжить показ технической части уровней UT4
· Не навреди. Базовые понятия технических ограничений.
Логично предположить что уровни построены из определенного количества объектов расположенных в пространстве.
Когда 3D artist готовит ассет, он создает его как правило в “вакууме”.
Т.е если стоит задача сделать ящик, он делает ящик.
Готовит к нему текстуры, зачастую ему надо сделать модель с несколькими уровнями пониженной детализации (LOD) и Collision Mesh (упрощенная геометрия для обработки физических столкновений)
(исключение мобайл, некоторый VR или просто особый пайплайн в студии)
Это дает свободу дизайнеру уровней расставить эти ящики так как ему угодно исходя из его идеи того для чего эти ящики на уровне.
Так же такие ящики могут иметь более сложную физику, а не просто стоять статически.
Вроде бы, все просто. Но не для видеокарты и движка.
Если говорить упрощенно, то видеокарта должна рисовать каждый отдельный объект и графически процесс (туман, эффекты, отражения и т.п).
Это называется Drawcall - т.е вызов отрисовки.
Движок используя свой алгоритм считает сколько объектов находится в кадре.
Процессор, взяв информацию об этих объектах и подготовив их дает команду видекарте:
Нарисуй ящик #1
Нарисуй ящик #2
Нарисуй ящик #3
Etc
Нарисуй дерево #100500
Все, кадр готов.
Запрашиваю информацию о новом кадре.
Нарисуй….
Представьте сколько объектов находится в одном кадре. Пусть даже если некоторые объекты являются группой 3D моделей и считаются 1 объектом.
(Например можно смоделировать не 1 ящик, а сразу группу ящиков. Они должны быть цельным мешем, у них должен быть 1 общий материал с общей текстурой. Такой подход напрямую отражается на уровне интерактивности, так как подвинуть 1 отдельный ящик уже не получится)
В среднем, забегая вперед объектов в сцене бывает от 800 до 4000 в консольных и ПК играх.
Но желательно для PC и консолей не превышать 1500 отрисовок, для мобайла выше 100.
Представим у нас в кадре 3000 объектов.
Что бы построить 1 кадр нужно ЦП получить информацию > Дать команду видеокарте > Видеокарта это все рисует > Происходит сборка кадра = и все это должно успеть произойти желательно 60 раз в секунду.
И это только просчет графики.
Отдельным конвейером просчитываются различные движковые процессы / скрипты / игровая логика / обновление и сохранение данных / физика / AI / сетевая синхронизация и т.п
60 раз в секунду Карл! (Твое лицо, когда ты топовый процессор и старая видеокарта не успевает обработать твои данные)
Не навреди - по сути своей Drawcalls это главное ограничение дизайнера уровней с технической точки зрения.
Конечно есть еще аспекты связанные с освещением, физическими объектами и Aplha overdraw. Однако это более узкие темы, они зависят от типа проекта и его архитектуры.
Переборщить с поликаунтом сам дизайнер не может, “это задача” 3D Artist.
Сделать плохие шейдера и не подготовить префабы “задача” лежит на Technical artist.
А вот масштаб уровня и количество объектов на нем это и есть основной технически показатель при создании уровней.
И уже с ними дизайнер уровней может напортачить убив крутую оптимизацию ассетов/скриптов и шейдеров (если она была крутая конечно)
Далее я немного опишу остальные технические аспекты, однако именно благодаря ограничениям порой рождались гениальные решения которые совмещали в себе компромисс технических и дизайнерских проблем.
[Не FPS`ом единым]
60 кадров в секунду зачастую консоли не тянут при должной детализации, киберспортсмены вообще играют от 120 fps на высокочастотных мониторах.
А основной рынок и вообще самая крупная аудитория геймеров - это консольные геймеры.
У них в как правило 30 Fps.
В кино есть разные стандарты, но все мы наслышаны о стандартре в 24 кадра.
Сейчас я не буду говорить о весьма холиварной теме количества кадров для комфортного игрового процесса.
На самом деле, количество кадров в секунду не является прямым показателем плавности изображения.
14 милисекунд, отличный показатель отрисовки 1 кадра > в итоге будет больше 60fps.
16 милисекунд, тоже хороший показатель - 60 кадров в секунду
18 и выше уже не могут гарантировать отработку в 60 кадров в секунду.
Однако, если уровень имеет технические проблемы - то даже на мощном железе которое будет выдавать фактические 60 кадров в секунду игровой процесс может восприниматься не плавно.
Плавной игра будет если каждый кадр будет исполнятся примерно одинаковое количество милисекунд.
Если же кадры будут идти 16 MS, а потом некоторые кадры уйдут в 25 MS то показатель FPS все равно будет 60.
Но, будут практически не заметные микро-рывки которые практические не уловимы на глаз - но само восприятие будет несколько не комфортным.
Кроме того, скачки 45-60 FPS уже более грубо скажутся на восприятии. Стабильные 30 кадров гораздо лучше воспринимаются чем рывки 45-50-60.
Дизайнер уровней может мониторить процесс отрисовки его уровня с помощью различных дебаггеров и профайлеров что бы выявить проблемные места которые нужно оптимизировать.
(пример Unity Profiler и Unity Frame debugger)
И теперь мы подходим к окончанию главы о технических основах которые нужно знать дизайнеру уровней.
Это первичная оптимизация.
https://www.youtube.com/watch?v=QVag9DM2sRU&
https://youtu.be/QVag9DM2sRU
Batching:
Сшитие объектов в 1 Drawcall. Кроме самой геометрии сшиваются и текстуры в 1 атлас в 1 общий материал.
Этот процесс бывает как и ручной, так и на уровне движка.
Ручной процесс как правило происходит на этапе создания графического ассета.
Т.е моделируется не 1 бочка/ящик - а уже сгруппированные объекты в 1ом меше.
Такие объекты как правило статические, но могут фейковым образом разрушатся
(В серии игр Battelfield заборы ломаются одним цельным куском, по сути модель забора исчезает. Момент разрушения маскируется партикл-эффектом (частицы пыли/осколки) и может подгрузиться простая разрушенная модель. Например фундамент здания)
Static Batching:
Батчинг происходит на уровне движка. Дизайнер сам отмечает какие объекты являются статическими.
После движок предрасчитывает данные что позволяет рендрить различные группы объектов в 1 Drawcall.
Как правило статический батчинг включает в себя с разу и Static Lightmap. Это дешевый способ отрисовки освещения - по сути оно запекается в текстуры.
Что бы отработал Static Batching нужно выполнить определенные технически условия заложенные движком или его функционалом. Это и ограничение на количество полигонов, 1 текстурный атлас и т.п
Dynamic Batching:
Сшитие геометрии происходит прямо в процессе отрисовки кадра.
Требования к объектам у движка более высокие и далеко не все получится сбачтчить.
Кроме того сам факт работы динамического батчера как правило дополнительно нагружает систему.
Ручной Static Batching:
Хоть ручное сшитие объектов как правило происходит на ранних этапах, но весьма актуально и на поздних.
Такие расширения как Mesh Baker для Unity позволяют оптимизировать отрисовку проблемных мест в сцене уже после того как она была собрана.
Level Of Detail (LOD):
Технология стара как мир, по сути это подразделение объекта на разные типы детализации в зависимости от дальности объекта.
Некоторые движки позволяют автоматически генерировать LOD, вставляя на дальний уровень например не Low poly объект - а обычный плейн (Bildboard) который всегда направлен на камеру.
Кроме того на разные уровни детализации выгодно так же назначать разный материал которые используют шейдеры разной тяжести. Чем дальше уровень, тем легче шейдер.
Это приводит заодно к тому, что ломается Batching.
Т.е например у вас есть 2 дерева, без LOD они вероятно легко бы сбатчились в 1 Drawcall.
Но с LOD деревья могут различаться друг от друга, одно может быть LOD0, другое LOD3.
Из за чего их геометрия и материал не будут совпадать и Batching не отработает.
Но, все равно в целом это выгоднее. Кроме того Dynamic Batching как правило без проблем переваривает дальние уровни. Т.е все деревья LOD3 могут иметь возможность отрисоватся в небольшое количество отрисовок.
Occlusion culling:
Процесс который в реальном времени отрезает объекты которые не видно в кадре.
Т.е если объект стоит ЗА другим, или вовсе не попадает в кадр.
Технология лихо сбрасывает поликаунт, но ломает батчинг и сам по себе процесс расчета видимости объектов не такой быстрый. Поэтому в мобильных играх он практически не применим ибо может занять 5ms.
Baked Light:
Запекание освещения тоже стоит упомянуть, хоть оно и идет в ряд с статическим батчингом.
Расчет освещения в реальном времени - это тоже N количество Drawcall на построение освещения и теней.
Поэтому по возможности свет лучше запечь.
Reflection probe - запекает в себе статическое отражение.
А Light probe запекает в себе шейдинг на сверические гармоники, что позволяет затенять динамические объекты.
· Продвинутый инструментарий.
Вручную расставлять коробки, мусор, деревья и прочие модельки не самый приятный процесс.
Особенно если вы делаете какой нибудь огромный Division.
Однако в таких крупных проектах специально для художников создают инструментарий под конкретные задачи создания уровней.
https://www.youtube.com/watch?v=JrAD-2oAul8&
https://youtu.be/JrAD-2oAul8
Различные кисточки, автогенерация и рандомизация, автоматизация огромного количества рутинных процессов такие как блендинг текстур и создание эрозии ландшафта - именно именно для этого и создаются инструментарии.
Работа с ними это основной производственный процесс Level Artist`а.
Однако художники совместно с техническими художниками зачастую напрямую участвуют в
их разработке.
Вся сложность состоит в том, что создать универсальный и гибкий инструмент сложно. Кроме конечно базовых вещей таких как “кисточки” покраски ладншафта или раскидывания объектов.
Хотя последнее в Unity из коробки по сути отсутствует, та система ландшафта и растительности что есть сейчас не только морально устарела, но и крайне не оптимизирована.
Но, на мой сугубо личный взгляд лучше найти сторонний плагин, или сделать его самому, или разработать свой пайплайн расстановки арта (например через Houdini).
Итого, чем больше проект и чем “жирнее” в нем арт - тем больше инструментариев и редакторов он требует.
Показать GeoPainter и Cloner
· Масштабы и метрика
У всего есть правила, художники создают по техническим гайдлайнам в которых как правило указан масштаб объекта. И это не только нужно под требования движка или злого технического артиста - перфекциониста.
Идея в том что Дизайн уровней это геймдизайн с артом.
И масштабы нужны не только для соблюдения визуального соотношения размеров но и для стандартизации и баланса игровых механик.
Обычно обсуждая дизайн уровней масштабы и метрики выносят в отдельные темы. Но на мой взгляд из за того что масштабы зачастую напрямую влияют на метрику, а метрика в свою очередь на баланс и игровой процесс то все же стоит переварить эти две темы одновременно.
Если говорить про масштаб то тут все вроде как просто.
У нас есть размер модели персонажа и двери не должны быть меньше ее, если это конечно не идея уровня.
Но вот в Stalker, ящик который размером гораздо больше чем единственная дверь в помещение вероятно аномальный или его сюда выбросом занесло.
Ну или это дизайнер уровней проглядел (хотя давайте все же верить в глубокую проработку мира и то что ящик попал сюда с помощью аномалии)
И в игре с намеком на фотореалистичность это сильно бросается в глаза.
Однако если игра имеет стилизованную графику и какой то особенный “Лор” то это можно не заметить.
В WOW лестницы имеют какие то исполинские размеры. С одной стороны у игры очень крутой стилизованный визуал, да и возможно это подземелье раньше принадлежало каким нибудь великанам…. но все же восприятие уровня относительно персонажей как то разнится не так ли?
Но не стоит делать все “реалистично”, реалистично не значит весело!
Порой довольно нетривилальное восприятие масштаба позволяет сделать уровень узнаваемым и интересным.
Гораздо болезненнее если просчет или недосмотр в плане масштабов повлияет на игровой процесс чем на восприятие масштаба.
Для этого геймдизайнеры и технические артисты создают некий свод правил - гайдлайны которому должны придерживайся как художники так и геймдизайнеры.
Например по стандарту необходимо утвердить заранее:
· Какая высота у среднестатистического персонажа и главного героя
· Утвердить высоту камеры и диапазон ее максимальной высоты (это касается и FPS игры так как порой высота камеры игрока отличается от высоты головы главного героя (подойдите в упор к NPC в Stalker к примеру)
· Утвердить максимальную высоту и дальность прыжка
· Утвердить расстояние на котором персонаж может “Зацепится” за обрыв и тп
· Утвердить высоту персонажа в состоянии “Сидя” и в положении “за укрытием”
· Утвердить максимальную скорость бега/ходьбы (обычно измеряется в Движковых юнитах/Время)
· Утвердить на каком расстоянии слышны звуки (дальность звука шагов ГГ для противника и противников для ГГ)
И еще огромное количество переменных которые вкупе своем создают - игровые правила.
Данные метрики это инструмент дизайнера позволяющий ему выстраивать геймплей и учитывать огромное количество нюансов создавая при этом интересные игровые события и условия.
К примеру в Crysis прямо в редакторе уровней дизайнер видел радиус активности AI противников.
Spawn Point имели модельку “персонажа” что бы можно было сразу понять высоту и тд и тп.
Но, дизайнеру так же было необходимо учесть размеры самих противников ибо для их маневрирования им нужно пространство.
Если же игрок сможет “забится” в узкое место куда не доберется противник, но игрок при этом сможет атаковать - то это баг.
Игнорирование стандартов или просчет их использовании может привести к тому что невозможно будет создать правильную кривую сложности уровня.
Невозможно будет его сбалансировать, не только сделать его заметно легче там где это не надо. Но и наоборот сделать его абсолютно не проходимым.
Например если дальность прыжка игрока будет меньше чем обрыв который создал дизайнер то игрок никогда его не перепрыгнет.
Выстраивание подобных механик это одна из основных задач на этапе Грейбоксинга (GrayBox) - прототипирование уровня на геометрических примитивах.
Шанс ошибки дизайнера можно гораздо уменьшить если встроить в редактор шпаргалки и визуальные помощники которые изначально показывают свой масштаб или радиус.
Показать грейбоксинг в UT4
· От Грейбокса к модулям
Graybox - принцип раннего прототипирования уровня, и “серой коробкой” он называется из за того что по факту это примитивная геометрия графических текстур.
Конечно как уже описывалось выше в грейбоксах могут быть технические текстуры для упрощения выстраивания метрики.
Однако кроме построения базовой геометрии на ранних прототипах так же выстраивают первичный (драфтовый) свет и цвета материалов.
Обсуждение того как строится грейбокс можно бы занять много времени, однако из за того что прежде этого уже обсудили понятие “метрики” все становится гораздо проще для понимания.
В первую очередь опять же надо осознавать для прототип уровня зависит от типа игры.
К примеру Грейбоксинг для той же Uncharted это больше процесс создания геометрии способной режиссировать игровой процесс.
Художникам концепция Graybox может быть знакома, так как зачастую технику набрасывая черновой геометрии используют для концепт арта. Разница в том что кроме основной идеи выраженной через геометрию и силуэт, игровой грейбоксинг заточен для создания непосредственно игрового процесса.
Причем факт балансировки тоже напрямую относится к понятию “игровой процесс” и поэтому прототипирование мультиплеерных карт критически важно.
Идеальный пайплайн когда задачи концепт художников и дизайнеров уровней совмещены.
В таком случае кроме игровых задач грейбокс так же позволяет выполнить художественный предпродакшен.
Но есть еще одна важная роль грейбоксов - предпродакшен контента.
При создании игрового процесса и поиска художественного исполнения создаются ТЗ на Анимацию/Текстуры/Материалы и шейдеры/Модели и тп
Важно помнить что хороший прототип уровня можно сделать лишь постоянно его тестируя, из за чего после каждого плейтеста в него вносятся правки.
Если начать создавать уровень сразу с графической части то любая правка уровня будет очень болезненно отражается на скорости исполнения и в конце концов может просто превратить уровень в мешанину заодно превратив пайплайн и рабочий процесс в ад.
Поэтому грейбоксы желательно создавать в виде примитивного контента.
· Modular level design
Модульный принцип создания уровеней очень распространен из за своей оптимальности и применимости на любом типе проекта.
Даже если вы делаете мобильную игру с большим количеством технических ограничений никто вам не помешает “сшить” (сбатчить) уровни еще на этапе их сборки в каком либо 3D редакторе.
Сам принцип пришел в игры из реального мира, ведь по факту нас окружают огромное количество постоянно повторяющихся объектов.
Причем дизайнеры уровней имеют в своем арсенале не только работы модулей в виде 3D моделей.
Но и различные “декали”, инстансы материалов, шейдеры и т.п что в купе наборами 3D модулями разной детализации позволяют создать очень детализированное окружение из ограниченого контента.
Дизайнеру уровней не придется заказывать различные уникальные типы объектов если у него на руках будет “конструктор” из которого он может собрать себе этот самый уникальный объект.
Это ускоряет процесс производства игры в целом, позволяет 3D художникам фокусировать внимание на конкретных моделях и кроме того по сути развязывает руки дизайнерам уровней.
Важно понимать что сам по себе процесс производства модульного набора моделей не может возникнуть сам по себе. И я опять ссылаюсь на главу выше - только на этапе предпродакшена, создании грейбокса и концепта уровня можно понять то какой графический контент необходимо для реализации!
Понятие “модуля” не ограничивается лишь “хард-сурфейс” и искусственными объектами.
Модулями вполне можно (и нужно) создавать природное окружение.
А что если к процессу создания модулей и сборки уровня максимально тесно привлечь технических дизайнеров и программистов?
Из темы “Продвинутый инструментарий” мы видели магию где в пару кликов можно “сделать красиво”.
И технические дизайнеры создают инструментарий который по своему (не сложному) алгоритму просто оперирует модульным контентом заодно автоматически настраивая какие либо технические параметры объектов.
Это дает огромный буст в скорости художника по уровням что в купе с грамотно созданным модульным контентом позволяет добиваться самого настоящего “Next gen AAA реалистичнее чем в жизни”
https://dtf.ru/4320-star-wars-battlefront-i-iskusstvo-fotogrammetrii
Взгляните на бешеную детализацию этого уровня.
В этой великолепной по исполнению локации “Эндор” из Star Wars Battlefront модульная библиотека состоит меньше чем из десятка объектов.
Однако с модулями все же можно напортачить.
В первую очередь это касается каких либо технических проблем, например зачастую некоторые аспекты уровня оптимальнее сделать единой геометрией так как это будет наиболее экономнее в плане поликаунта и Drawcalls. Для решения этих задач необходимо использовать различные динамические батчеры и т.п. Либо “шить” вручную, что может затянуть процесс оптимизации.
Желание слишком часть реюзать одни и те же модули (даже в случае богатой библиотеки модулей) приведет что уровень будет выглядеть однотонным с явными и режущими глаз повторяющимися элементами.
Причём порой это не совсем заметно даже, но все равно вызывает некий дискомфорт при восприятии целостности картинки.
(не самый удачный скриншот)
Например в Hardline так часто “налепили” луж что выглядит все крайне шумно и не аккуратно.
Кроме того некоторые лужи лежат на наклонной плоскости подъема на мост и не стекают…
Из этого можно сделать вывод что наличие ВОЗМОЖНОСТИ создать деталь не означает что ее нужно лепить если это повредит целостности и балансу восприятие картинки.
Последняя проблема модулей может заключаться в том что уровни приобретут очень “правильную” форму.
Связанно это с тем что у модули расставляются по сетке, для того что бы они совпали и могли быть состыкованы.
Привязка к сетке порой приводит к эффекту излишней искусственности окружения.
Конечно это не всегда плохо….в Halo многие уровни ощущаются очень “рубленными” и это ощущается как фишка.
И в конце стоит вспомнить Mario, где облако и куст это один и тот же спрайт разного цвета.
(А в Skyrim “Стол” это утопленный в пол шкаф…)