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).

Итого, чем больше проект и чем “жирнее” в нем арт - тем больше инструментариев и редакторов он требует.