Прошёл неделю тому назад я REPLACED. Очень был впечатлён визуальным стилем.

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

Сделал я вот такую систему:

Как я добился того, чтобы объекты реагировали на свет именно подсветкой края?

Правильно, написал свой шейдер для этого.

Логика работы шейдера такая: по альфа (прозрачности) выясняем какие пиксели картинки являются крайними, потом получаем текстуру 2Д освещения и соединяем информацию из текстуры освещения с найденными ранее пикселями.

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

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

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

1. Иерархия объектов на сцене.

Можно заметить, что объектов не так и много, но я могу развернуть, например, ПолиШейп объект и увидеть, что там внутри каждая ступенька, стенка, уголок спрятаны

Помимо просто визуального порядка и удобства работы это даёт нам возможность дополнительных манипуляций:

1. Можно перемещать, менять масштаб и дублировать сразу группы объектов
2. Можно деактивировать целые группы для большего удобства в работе
3. Можно задавать свойство статичности всем дочерним объектам одной галочкой

Что за статичность? Зачем?

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

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

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

Я вот сейчас это пишу и думаю: «А какого лешего я заговорил об оптимизации в середине цикла?».

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

P.S. Если вам код склеивания мешей в один таки нужен, пишите в комментарии, покажу)

Всем хороших игр!