Советы при работе с Blueprint в Unreal Engine
Блюпринты-это данность, которую нужно принять. Даже если вы гуру C++ BP избежать не получится
Для нашей команды я написал небольшую инструкцию, чтобы у саунд дизайнеров, художников по материалам, и других участников процесса разработки было поверхностное понимание о BP и написании кода в них.
Решил поделиться и с вами
- Архитектура в BP классах
Перейдем к блюпринтам. Да, да же если ты гуру C++ без BP никуда. Увы. Будем деградировать.
Epicи не стали выдумывать новый язык. А просто обернули текстовое програирование в графическую оболочку (если прямо совсем просто). Да это немного другое, но функционал остался примерно тот же. Хотя есть и ограничения.
Блюпринты поддерживают наследование, как от C++ класов, так и от других BP при помощи контекстного меню при нажании ПКМ на BP файле, можно создать Child Blueprint
Так же родителя можно назначить уже в созданном BP
В зависимости от вида BP ему может быть доступны
Viewport, где можно скомпоновать и расположить компоненты этого класса
Event graph где располагаются евенты, вызываемые в различных условиях и режимах игры
И функции, макросы, переменные. Без которых код бы выглядел как сто раз скопированный кусок кода, обернутый в запутанную лапшу
- Нейминг в Blueprints
Правильное имя функций и переменных решает большое количество вопросов, и упрощает чтение кода, но все равно, про комментарии не стоит забывать. Всегда нужно понимать. Если сейчас эта графическая последовательность вам понятна, то не факт что через неделю вы сможете быстро понять, что делает та или иная функция. А в проекте может быть более одного разработчика, подумайте о том бедолаге, которому придется зайти в ваш BP и сказать.
Конечно, это не идеальное оформление, но кровотечение из глаз не вызывает, и это хорошо
А теперь очень важное требование!
Префиксы в именах переменных. Как я уже говорил, переменные бывают разные, и программисты давным-давно придумали как в них разбираться. И для удобства, стоит придерживаться хотя бы минимального плана.
Поехали:
Публичная переменная (Просто называем, так чтобы можно было понять ее назначение)
Приватная переменная (Префикс m_ПонятноеИмя)
Константа (CONST_ПонятноеИмя)
Локальная переменная (Local_ПонятноеИмя)
А теперь, для чего все это? Давайте прочтем часть кода
Сейчас можно сразу увидеть, какая переменная локальная, а значит ее больше ни в какой функции не будет. Какая константа, А значит ее значение в процессе выполнения кода не меняется. Это очень облегчает жизнь, как вам, так и окружающим. Поверьте на слово.
- Распутываем лапшу
Вот пример:
Это функция, которая манипулирует NPC задает ему его состояние, координату спавна и многое многое другое.
Как видите, у нее много входных значений
Если мы их все начнем тянуть от начала до конца, да же если мы это сделаем ровно, до конца. Код станет нечитаемым. Так как придется постоянно скакать к началу функции, и распутывать этот клубок.
Гораздо проще использовать ноду входной переменной
Это в разы упростит код, и сделает его читаемым, и так же желательно делать с любой переменной, старайтесь писать так, чтобы во вьюпорте вы всегда видели от начала до конца, от куда берется та или иная переменная
Кстати, тут есть что улучшить, Вместо MakeLiteralName можно и нужно использовать константу. Руки не дошли).
Если есть много повторяющегося, сложного кода, который можно объединить во что-то общее по логике, оберните его в функцию. И используйте в разных частях кода.
Делайте линии ровными. Кривосплетение линий очень трудно читать, их можно идеально выровнять при помощи кнопки Q.
А сами ноды можно выравнивать сочетанием Shift+W, Shift+S, Shift+A, Shift+D
Это базовые требования, но да же соблюдая только их, можно и нужно прийти к читаемому коду, и избавиться от бесконечной лапши.
- Виды переменных
Тема почти полностью была раскрыта в нейминге. Но пройдусь по верхам
Общие переменные. Их можно получить из референса класса, и использовать других классах.
Приватные переменные, можно использовать только в конкретном классе, к которому они принадлежат.
Локальные переменные, живут только внутри функций, когда код функции выполнен их значения возвращаются к дефолтным.
Есть и другие виды переменных, но хотя бы этого достаточно для азов.
- Категории
И еще один инструмен, позволяющий систематизировать и структурировать процесс
Категории. Категория может быть как у функции, так и переменной.
Создавать категории очень просто. Достаточно кликнуть на поле ввода, и ввести нужное название, подкатегорию можно создав, поставив вертикальную черту и написав название подкатегории
Рекомендую использовать в качестве имени категорий, название вашего проекта.
Это поможет в поиске нужного параметра.
Если вы думаете, что это распространяется только на оболочку BP то нет. Категории отображаются и в деталях референса на ваш блюпринт.
А так же в контекстном меню
Это сильно упрощает работу с переменными и функциями, то же обязательно к применению.
- Самые простые советы по оптимизации кода
Ну и пару советов по оптимизации. Капитан очевидность, так сказать.
Если надо несколько раз вызывать функцию, запишите результат в переменную
Мы берем массив Vector из функции SetSightTarget (помните, что я говорил про нейминг) и потом используем ее в других местах
Delay не панацея. Не используйте Delay в вычислениях. Он не для этого. Если вы делаете Delay 0.2 сек, то на вашей машине все будет в порядке. А у игрока может быть менее производительное железо, и за 0.2 секунды оно может не справится. Одно дело задать скорострельность автомата, а другое дело, дать коду подождать, пока появится значение переменной и так далее. Второе надо из кода стараться исключать.
Надеюсь это кому-то поможет сделать свой код чуточку удобнее для окружающий, и для себя самого.
И заходите в наш профиль, мы публикуем большое количество информации по игровой тематике и о нашей игре PreCtober.
Комментарий недоступен
Спасибо. На вопросы в начале нужно отвечать? Или это совет, что нужно раскрыть в целом?
чем локальная переменная отличается от приватной и от публичной?
После такого вопроса отправлять автора гуглить про мемори лики — ооооочень странно и неправильно.
Очень годная заметка, на мой взгляд, для тех кто начинает знакомство с движком обязательна к прочтению.
чтобы у саунд дизайнеров, художников по материалам, и других участников процесса разработки было поверхностное понимание о BP и написании кода в них.
Либо отдавать самые примитивные задачи, либы выделять тех артистов. То, о чем вы пишете, уже программирование, а не "поверхностное понимание".
Артисты последние в списке, а саунд дизайнеры первые))