Корсарская химера и чем её готовят. Диалоги, квесты, оптимизации. Часть 1

И так, спустя тройку месяцев, finally новая статья о разработке моей пиратской игры! В ней я расскажу о том, какой же Unreal Engine кусок г… готовых наборов плагинов под все случаи жизни. Немного о доработанной диалоговой и квестовой системе. А так же традиционных чертовых оптимизациях.

Должен сказать, что чем дольше не делаешь статью о разработке, тем тяжелее её написать в дальнейшем. Идея то в чем изначально была: я за 3 недельки дошлифовываю базовые механики, снимаю видео доказательство работоспособности и прогре… заинтересовываю, как минимум, мододелов текущих версий корсаров. А что получилось на практике:

Я две недели сидел, интегрировал в неписей всякий функционал, по типу диалоговых систем, квестовых и диалоговых маркеров и т.д. Фиксил конченную производительность плагинов, которые я установил. Фиксил тонны багов. И попал на хайп трейн BG3 из-за чего выпал из потока на несколько недель.

В итоге только к сентябрю я вернулся, за недельку дошлифовал некоторые аспекты, и выпустил недавний(уже давний) видео-материал с прогулкой по городу и покатушках на корабле. У внимательных личностей мог встать… вопрос: а почему видос не соответствует заявленному? Где диалоговая система? Квестовая? ГДЕ ЭКШОН?! А я даже не знаю как и объяснить… Во всех этих системах есть то, к чему можно и нужно придираться, и из-за этого мне постоянно хочется что-то улучшить. Чтобы с меньшей вероятностью расстраиваться из-за критики, что мол сделал недостаточно и т.д.

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

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

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

В общем посидев и покумекав, я решил что лучше внедрить VAT-персонажей(vertex animation texture) в полноценный класс Character, и уже внутри него устраивать логику переключения между скелетной и статической сеткой. Но и здесь конечно не без подводных камней…

И так, вопрос: а как кака… кхм… как нам переключать эти разные версии то собственно говоря? Не особо прошаренные мне ответят: “Ну ты чо дурак? Там же есть специальный флажок Visible в блоке Rendering. У всех компонентов такая есть, дурачок. Хаха!”. Но я им отвечу:

Отключение видимости нам поможет если мы просто не хотим отрисовывать какой-то объект, тратить на него миллисекунды нашей драгоценной видеокарточки. Но это никак не поможет нам когда мы хотим оптимизировать CPU. Видите ли, скелетная сетка настолько капризная штука, что даже если выставить в ней заветное “Visibility Based Anim Tick Option - OnlyTickPoseWhenRendered” она, сука, все равно жрет процессор! Зачем? Да хер его знает чем руководствовались разрабы когда придумывали это говно!

Я честно говоря перепробовал всевозможные флажки, селекты, танцы с бубном, но скелет все равно продолжал откусывать кусочек производительности от CPU если верить профилировщику. В итоге я не нашел ничего лучше, чем просто очищать Skeletal Mesh Asset, и тогда на производительность он почти перестает влиять. Почему почти? Ооо, об этом я расскажу чуть позже.

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

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

Давайте посмотрим на количество компонентов, которые висят на нашем простом работяге Билли.

Шесть VAT компонтетов, один базовый скелет от Character класса, три компонента от ALS, и один Arrow который по факту нафиг не нужен, но к счастью он существует только в версии разработки. Если вы читали мою статью о новой архитектуре кораблей, то можете помнить о том, что я сказал:

Так вот, точно такая же ситуация и с нашими дорогими компонентами. Чем их больше на персонаже, тем дороже обойдется их перемещение по карте. А у меня, помимо VAT-компонентов под каждую часть одежды, есть еще и компоненты непосредственно от родительского класса AlsCharacter: OverlayStaticMesh, OverlaySkeletalMesh и их кастомная камера со своими приколюхами. И прям полностью от них отказываться не хочется, т.к. персонаж же может переключаться в скелетную сетку со всеми приколюхами от Als. Вот если бы можно было просто в блюпринте удалить эти компоненты, чтобы они не жрали процессор… А кто нам мешает?)

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

И в целом способ есть, и имя ему Skeletal Mesh Merger. Он позволяет прямо в редакторе выбрать несколько скелетных сеток и объединить их в одну.

Но разумеется не без ебучих проблем!

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

Вторая: цыганские фокусы с качеством итогового меша. В общем, как только вы его смержили - все замечательно. Стоит вам перезайти в UE, как все объединенные меши теряют примерно половину полимеров. Как так то?! Самое неприятно то, что после такой ошибки, запись вершинной анимации багуется и начинает выдавать артефакты. В итоге я не нашел решения лучше, чем экспортировать итоговый меш из анриала в fbx, сразу после того как его создал, и потом после перезапуска UE импортировать его обратно. Тогда вроде ничего не ломается.

Как оно было в оригинальных корсарах? Ты подходил к какому то NPC, нажимал левую кнопку мыши и начинал диалог с тем, кто стоит напротив тебя. Для того, чтобы понять в какой дом ты можешь войти, а в какой нет, приходилось обивать пороги всех зданий подряд. Т.е. не было никаких подсказок и адекватного целеуказателя. Разумеется своими руками я бы делать такую логику не стал, и поэтому воспользовался плагином Ultimate Interaction Manager или как его называю я - Ультимативный кусок тупого говна!

Так в чем же проблема этого плагина? А в том что он олицетворяет собой один большой баг! Начнем с малого. Что произойдет, если заспавнить персонажа игрока внутри области взаимодействия? - Ты получишь кучу ошибок. Тебе придется выйти из зоны взаимодействия, и войти в неё обратно, только тогда оно заведется. Ладно, не критично вроде, поправить можно.

Но вот вся критичность начинает проявляться на масштабах. Прикрепил я значит этот плагин ко всем моим NPC в размере 100 штук и увидел дроп фпс-а до однозначных значений!

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

Охеренная идея завязываться на тип объекта коллизии, который может принадлежать не только игроку! Браво! Что могло пойти не так? В итоге пришлось создавать отдельный канал коллизий, который бы отлавливал только игрока.

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

Так, ну на первую часть я думаю достаточно… Во второй части расскажу о:

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

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

#личныйопыт #девлог #unrealengine