Советы для начинающих (и не очень) разработчиков на Unreal Engine

Изначально эта статья была опубликована мной в блоге на Habr, на DTF, по какой то причине, я особо не присутствую и сейчас решил зайти сюда с этой статьей, я думаю, что здесь материал увидит еще больше людей и им он может быть полезен. У меня есть еще одна, дебютная статья про сборку мусора в Unreal Engine 4, она весьма техническая и я не уверен что ей тут найдется место, но приглашаю ознакомиться, как минимум если вы разраб на UE.

В основном эта статья будет полезна начинающим разработчикам, у которых уже есть небольшой опыт работы с движком (может пару месяцев или пол года). Если вы считаете себя мидл девелопером — то думаю, что вы тоже найдете для себя что-то полезное и нужное. Уверен, что и артистам, работающим с Unreal Engine, данная статья может быть полезна.

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

Эта статья — не туториал или гайд “как делать правильно”, я не даю каких то четких последовательностей действий, что бы добиться наилучшего результата. Я стараюсь поверхностно пройтись по, так как мне кажется, наиболее важным для новичков аспектам разработки на Unreal Engine. Моя цель — подсказать вам направления, в которых можно и нужно копнуть поглубже. Рассказать что есть и для чего это можно использовать. Почти для всех пунктов я привожу ссылки на более конкретные гайды и описательные статьи по темам. Они могут вам помочь.

Статья получилась весьма большая. Сначала это был маленький список тем, буквально 2-3 страницы, которые я активно пропагандировал несколько лет назад в компании, в которой я работаю. Тогда и сейчас я много времени уделял наставничеству начинающих разработчиков и вместе с этим сам многому научился. Недавно я случайно откопал эту заметку, решил раскачать ее в полноценную статью и поделиться ею с сообществом! Надеюсь что описанные мною вещи будут вам интересны и полезны. Желаю приятного чтения: -)

💡 Скорее всего, со временем вы почти забудете что на Blueprint можно делать полноценные игры.

Если вы делаете игру на Unreal Engine которую планируете поддерживать после релиза или в целом планируете долгую разработку (пол года и более), скорее всего вам потребуется писать на С++, как бы вам этого не хотелось.

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

Чтобы не закладывать себе бомбу замедленного действия и не тратить потому кучу времени на рефакторинг, не хвататься за голову, когда какой-то маленький кусочек функционала придется реализовать в С++ (например в целях оптимизации), следует придерживаться нескольких простых правил:

Это весьма просто и под силу даже самому зеленому джуну, главное верить в себя! В таком случае у вас не будет барьера что бы писать С++ тогда, когда это потребуется. Вам не нужно будет переносить основу ваших объектов и заниматься этим несколько часов (а может и дней) к ряду, вам просто нужно будет переносить отдельные куски логики, что займет совсем немного времени и моральных ресурсов.

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

Но есть и вещи которые делать в макаронах можно и в какой то степени нужно, в целях ускорения разработки:

Важный момент про UI! Дизайнить UMG виджеты в С++ вы не сможете, а делать игровой UI на Slate та еще плохая затея. Но не нужно унывать, есть замечательный мета-модификатор BindWidget. Если вы объявите переменную компонента (сабвиджета) вашего виджета с этим модификатором и в БП наследнике создадите элемент с таким же именем — то он будет положен в эту переменную и вы сможете легко и просто использовать ее в С++, без какого либо дополнительного кода по получению компонентов и т. п. Тут можно почитать про BindWidget.

Паттернов очень много, они предназначены для решения шаблонных задач, которых в программировании, на самом деле очень много, хоть мы все и говорим, что программирование — это творческое занятие! Зная о паттернах и следуя им вам будет проще понимать код, который написал с использованием паттернов, и ваш код будет более логичным, понятным и объяснимым. Вам не придется понимать, почему вы сделали именно так, а не иначе (на самом деле конечно придется, но в меньшей степени).

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

Про то какие паттерны существуют и как их использовать можно почитать тут.

Нет, я не призываю вас под каждую задачу тянуть библиотеку, как по слухам это любят делать в веб разработке. Однако же, когда перед вами стоит какая то задача стоит понимать, что скорее всего эту задачу или похожую кто то уже делал, это может быть разработчик движка (тогда ваше решение у вас под ногами), ваш коллега, или рандомный бородатый мужик живущий на маленьком острове посреди пролива Ла-Манш.

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

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

Цикл жизни каждого объекта должен начинаться с корректной инициализации, а заканчиваться остановкой его работы и удалением. Такой подход упростит вам написание кода и поможет избежать того, что мы называем undefined behaviour (это когда хрень какая то происходит).

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

Если объект использует какие то вещи, которые объекту нужно создать или получить из внешней среды — это нужно учесть во время инициализации. Чтобы в коде основной логики объекта не мешался поиск какого то актера на уровне, а просто использовались уже проинициализированные поля. Архитектура Unreal уже имеет функции у многих базовых классов, которые используются ими для инициализации и их можно переопределить:

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

Важно не только удалиться но и сделать это правильно: скинуть таймеры, разбиндить делегаты, удалить какие нибудь зависимые объекты, оповестить кого надо. Unreal Engine многое из этого сделает за вас благодаря GC и рефлексии, но возможно что то у него не получится, по этому не стоит пренебрегать четким заверением работы объекта.

Функции подходящие для завершения работы:

Но вы так же можете делать и свои функции которые корректно будут завершать работу в вашей ситуации.

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

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

Какие у этого решения плюсы:

https://docs. unrealengine. com/4.27/en-US/ProgrammingAndScripting/Subsystems/ — тут можно почитать про них страницу в документации. В документации нету UWorldSubsystem но она существует и в ней можно делать вещи, которые относятся к миру игры.

JSON желательно собирать и парсить при помощи структур и конвертации (FJsonObjectConverter) json в структуру и обратно. По структуре очень просто можно понять что хранится в json, не прибегая к прочтению кода парсинга. А так же это очень быстро, просто и эффективно.

Парсить жсоны руками — плохо, почему:

Если что-то плохо конвертируется в Json, например если в структуре есть TOptional или иные поля не поддерживающие рефлексию можно использовать ImportTextItem или ExportTextItem, это грубо говоря парсинг, написанный руками, но в некоторые моменты приходится писать свою логику для таких базовых вещей как парс JSON’ов.

Под взаимодействием объектов в рамках игры мы обычно понимаем вызов функций из одного объекта в другом. Или вызовы из одной группы объектов в другую (например разные игровые системы).

Для контроля взаимодействия наших объектов и систем есть два хороших решения:

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

💡 Возможно, в будущем я напишу статью о том, как можно весьма просто и удобно пользоваться делегатами и событиями в Unreal и брать от них все.

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

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

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

Blast radius — это понятие, описывающие ущерб в виде багов или неработоспособности системы вызванный внедрением нового функционала или переработкой старого.

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

Один из принципов SOLID, а именно принцип разделения интерфейсов (I) гласит:

“Создавайте узкоспециализированные интерфейсы, предназначенные для конкретного клиента. Клиенты не должны зависеть от интерфейсов, которые они не используют.”

Под клиентом тут понимается сущность, которая использует интерфейс, а не реализует его.

Подробнее про принципы SOLID можно почитать в этой статье. Или в цикле видео на канале Сергея Немчинского.

Если вы делаете не большую игру и уже пользуетесь всеми или большинством советов из этой статьи — то скорее всего она у вас не сильно лагает. Однако оптимизировать все равно скорее всего придется. На первом этапе вам потребуется понять что вообще в вашей игре вызывает лаги и фризы, для этого в Unreal Engine (и не только) полно инструментов.

Однако, перед тем как переходить коду или ассетам есть несколько простых вариантов, которые вам могут помочь если дело не так плохо — настройки проекта. Вряд ли конечно оно решит вашу проблему, но посетить их стоит.

В настройках проекта (Вкладка Project Settings) есть много всего, что может влиять на производительность. В основном оно живет в группе Engine или в плагинах, если вы их используйте. Посмотрите на ваши настройки, погуглите что они значат, вдруг после изменения какой то из них ситуация станет лучше. Можно копнуть глубже и погрузиться в конфиги, так тоже много чего интересного и полезного, не только для оптимизаций.

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

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

Есть инструменты многие прям внутри движка, позволяющие оценивать производительность в рантайме, есть сторонний софт:

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

Если говорить о тике — самые важные показатели: среднее и пиковое время обработки кадра. Среднее — это общая производительность, тот самый FPS, а пиковая — это фризы/лаги.

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

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

Самые распространенные оптимизации тика, которые могут вам помочь:

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

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

https://www. youtube. com/watch? v=CBP5bpwkO54

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

Жесткие связи могут вызывать две проблемы: лаги и долгие загрузки.

Все поля для ассетов, которые вы указываете как UMyAssetType* FieldName; являются жесткими. И при загрузке сущности хранящей в этом поле ссылку на тот или иной ассет произойдет так же загрузка указанного ассета, даже если он в данный момент не нужен.

Может доходить до того, что при открытии любого уровня движок грузит в ОЗУ всю игру, из-за чего, казалось бы, маленький уровень загружается 10-ки минут. А лаги у вас могут быть когда вы пытаетесь что либо заспавнить, например оружие которое может наносить урон противникам, в таком случае оно потянет за собой загрузку противников и все их зависимости. Все это будет происходить в рамках одного кадра, что сильно растянет его время и вызывает лаг/фриз.

💡 Давным давно я сам так делал и люто от этого страдал.

У этих 2-х проблем есть ультимативное решение! Используйте мягкие ссылки везде где это можно!

Для определения мягкой (не слабой) ссылки в UE есть специальные типы:

Однако при использовании мягких ссылок придется загружать ресурсы, на которые они указывают самостоятельно, это не сложно и можно делать как синхронно (на текущем кадре), так и асинхронно (за несколько кадров).

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

Синхронная загрузка представляет из себя вызов одной функции:

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

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

Можно включать кластеры GC, что бы GC проводил поиск мусора быстрее.

Если мусора много — можно вызывать GC чаще, в таком случае он будет удалять меньше объектов.

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

По сути оптимизация скелетный мешей — это тоже оптимизация тика, но весьма конкретного и тяжелого.

Вы можете использовать настройки на вкладке Details/Optimization, там их много, посмотрите на них, они реально работают. Например там можно не тикать когда игрок не видит или не проверять оверлапы при воспроизведении анимаций.

Еще вы можете следить за тем, что бы одинаковые склетал меши тикали вместе, так как их тики очень большие и глубокие. (Возвращаю вас к видосику про оптимизации Sea of thieves)

А еще вы можете их инстансить (ну почти)! Это прикольно, попробуйте.

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

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

Качественные материалы с полным сетом PBR текстур — весьма дорогие. На 0-1-2 лодах следует так же менять материалы на более легкие. С большой долей вероятности на далеких объектах можно порезать использование каких либо текстур (например шершавости), и заменить на скалярный параметр. На супер далеких лодах можно просто использовать солидные цвета если это не заметно.

Важно! Если вы используете Nanite мои советы для вас могут быть не сильно релевантны.

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

В анриале есть 2 инструмента которые могут в это: Actor Merging и HLOD.

Actor Merging — это инструмент движка, который позволяет вам вручную запекать ваши меши и актеры в один меш, материалы и текстуры он так же может запекать.

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

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

Следовательно у вас есть 2 пути оптимизации:

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

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

Важное замечание! В эдиторе стриминг уровней всегда блокирующий — то есть он загружает весь уровень за один кадр. Если вы будете проверять оптимизацию стриминга в эдиторе — скорее всего он у вас будет лагать всегда.

И еще одно! Это относится только в UE4, так как в UE5 это уже по другому работает.

Оптимизация текстур, а особенно материалов — очень глубокая тема. Мы рассмотрим несколько ее аспектов:

Как вы могли заметить я очень мало (почти ничего) сказал про сеть в Unreal Engine, это очень большая тема и я не придумал как можно раскрыть ее коротко, ведь статья правда получилась очень большой и без сети. Когда нибудь, я думаю что и про сеть статью напишу, а пока что могу предложить вам ознакомиться с штукой, которая называется Unreal Network Compendium, это достаточно старая, но до сих пор актуальная статья, которая, как мне кажется, полноценно описывает сеть в Unreal Engine.

Буду рад вашим отзывам и комментариям, если у вас есть какие то вопросы касательно тем, описанных в статье или вы с чем то не согласны — давайте обсудим!