Найти в Дзене

5 ошибок новичков в Unreal Engine, которые тормозят прогресс (и как выбраться из этого болота)

Классика жанра: открываешь BP, а там паутина узлов как у паука на стероидах. В итоге — сам не понимаешь, что где. Что делать: разбивай логику. Один BP — одна роль. Повторяющиеся вещи выноси в функции, компоненты и библиотеки функций. Через месяц скажешь себе спасибо. Самая частая причина: “Почему оно не работает?!!” — а где хоть один Print? Нигде. Что делать: Print String, Draw Debug, Breakpoints. Расставил пару принтов — и уже понятно, кто виноват и кого увольнять. Так же есть удобная фича в акторе в верхней части окна во вкладке Debug —> Blueprint Debugger и при запуске игры, у вас будет возможность посмотреть, какие дочерние объекты есть в классе и какие значения в их переменных они хранят Типичная картина: “Get Player Character → Cast → Cast → Cast”. Это крепко держит классы друг за друга и потом всё начинает рушиться. За подобную конструкцию, как выше в приличном сообществе очень сильно бьют. касты, да ещё и на тике, то есть то есть ссылка будет обновляться каждый кадр. так же да
Оглавление

1. Сваливать весь проект в один Blueprint

Классика жанра: открываешь BP, а там паутина узлов как у паука на стероидах. В итоге — сам не понимаешь, что где.

Что делать: разбивай логику. Один BP — одна роль. Повторяющиеся вещи выноси в функции, компоненты и библиотеки функций. Через месяц скажешь себе спасибо.

2. Полный игнор дебага

Самая частая причина: “Почему оно не работает?!!” — а где хоть один Print? Нигде.

Что делать:

Print String, Draw Debug, Breakpoints. Расставил пару принтов — и уже понятно, кто виноват и кого увольнять. Так же есть удобная фича в акторе в верхней части окна во вкладке Debug —> Blueprint Debugger и при запуске игры, у вас будет возможность посмотреть, какие дочерние объекты есть в классе и какие значения в их переменных они хранят

Сначала в блюпринте, который собираемся дебажить выбираем вкладку Debug и Blueprint Debugger(Можно это уже и после запуска проекта в эдиторе сделать)
Сначала в блюпринте, который собираемся дебажить выбираем вкладку Debug и Blueprint Debugger(Можно это уже и после запуска проекта в эдиторе сделать)
Далее запускаем проект в движке и смотрим вкладку, сверху можно выбрать один из дочерних объектов созданных из класса. ну и соответственно их переменные
Далее запускаем проект в движке и смотрим вкладку, сверху можно выбрать один из дочерних объектов созданных из класса. ну и соответственно их переменные

3. Касты на каждом шагу

Типичная картина: “Get Player Character → Cast → Cast → Cast”. Это крепко держит классы друг за друга и потом всё начинает рушиться.

-4

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

-5

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

Что делать:

— Интерфейсы. Создал BPI, прописать пару функций — и объекты общаются без кастов и лишних зависимостей.

-6

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

-7

Как видите, теперь нет компонентов нашего персонажа и размер стал намного меньше вместо 15 360 килобайт, всего 760 килобайт

Заметка**

Касты это не зло! иногда без них никак или проще всего, например кастить на кнопки в виджетах это не супер критично, так как кнопка сильно много нагрузки не несет, а вот кастить на персонажа из кнопки виджета, вот это смерть всей оптимизации.(Так делают многие горе туторщики на просторах ютуба). каст используй тогда, когда это необходимо и ещё, важно, все касты, на бегин плей и с сохранением ссылки, либо на другую часть кода, которая не вызывается регулярно! никаких Event tick ну либо делайте, если хотите получить смуту 2.0

4. Оптимизация “потом разберусь”

А потом — 12 FPS и слёзы. Особенно если тик включён у каждого камешка в сцене.

Что делать: меньше Tick’ов, больше событий и таймеров. Всё, что спавнится пачками — через пул. Большие массы объектов — через Instanced Mesh. Чем раньше это делать, тем меньше боли дальше.

1) В классе во вкладке Class Defaults есть галочка Start with tick enabled
что делает эта галочка, по сути она на констракшен этапе добавляет этот объект в менеджер тика, который во время исполнения по очереди исполняет все тики в списке. по идее, если вы не используете Event Tick, анрил эту часть оптимизирует, но я рекомендую для чистоты все равно отключать, если вы пользуетесь только таймерами без Event Tick. так как в менеджере тиков все равно присутствует этот класс.

-8

Если вы все же воспользовались тиком, то при желании вы можете ограничить его исполнение, в той же кладке ниже под галочкой включения есть Tick interval, если значение 0, то срабатывает каждый тик, если например 0.2 то тик превращается в некий таймер, который срабатывает раз в 0.2 секунды. но так делать не желательно

-9

2) К теме о таймерах, тоже двоякая ситуация, есть моменты когда эвен тик будет предпочтительнее, например при просчете анимации, зачем просчитывать её больше чем нужно для отображения? но например движение объекта, или самое частое, реген стамины нужно делать на таймерах, либо через дельта секунды(Разница между кадрами).

3) Instanced static mesh (ISM)

если у вас есть много одинаковых объектов, например камней, то зачем шейдеру просчитывать отдельно каждый камушек? (Шейдер это программа исполняемая видеокартой)это будет создавать хоть и небольшую,а иногда и большую нагрузку в потоке)) вместо этого вы группируете объекты и только тогда подаете в шейдер, таким образом не создается очереди в потоке. так что для большого количества одинаковых объектов используйте ISM

5. Копирование туториалов без понимания

Сделал, работает… и всё, магия. Пока не попробуешь поменять одну деталь — и всё разваливается.

Что делать: повторяй тутор не “один в один”, а через понимание. Воссоздай логику сам, задай себе пару вопросов “почему так?”, потом модифицируй. Мозг начнёт сам складывать картину движка.

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

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