Comments 10
Хорошим подходом будет создание объектов с помощью Blueprints. А когда требуются дополнительные возможности, преобразование их в C++.
Создаётся ощущение, что код на Си++ генерируется из Blueprints, поэтому возникает вопрос, не «смоет» ли модификация в Blueprints внесённые изменения в код Си++?
И обратно — изменения в Си++ как влияют на Blueprints?
Лично у меня опыта по UE4 не очень много, но я не согласен с автором статьи. Оптимальная эффективность, на мой взгляд, получается при комбинировании C++ и Blueprints:
всякие базовые классы, сложная логика и т.д. пишутся в коде, а конечные объекты с какой-то кастомизацией – на блюпринтах.
При этом, у Blueprints есть очень серьёзный недостаток: это бинарный формат. Соответственно, с ними не получится полноценно работать через системы контроля версий. Да, в UE4 есть встроенная тулза для диффа, но нет 3-стороннего мерджа.
Самый популярный способ работы в команде, насколько я понял, это использование блокировки файлов. Эта фича, например, встроена в Perforce. Где-то видел, что и гит можно научить так делать, но это убивает всю суть децентрализованного подхода гита.
Смысл в том, что VCS лочит файл, над которым работает кто-либо из команды, до совершения коммита. То есть, никто другой не сможет поменять файл, который уже находится в процессе изменения. Такой костыль позволяет избежать конфликтов и необходимости мерджить изменения в бинарных ассетах.
«смоет» ли модификация в Blueprints внесённые изменения в код Си++?
И обратно — изменения в Си++ как влияют на Blueprints?
Блюпринты и C++ между собой соотносятся просто как классы. Например, можно создать класс UMyObject в C++, а потом наследовать от него Blueprint-класс. Наоборот нельзя, насколько я знаю.
Но у UE4 есть встроенная "нативизация" блюпринтов – т.е., преобразование блюпринта в c++ код. Я ни разу не пользовался, но, насколько я понимаю, это необратимое изменение. Т.е., после этого у вас уже не будет изначального блюпринт-класса. Но всегда можно создать новый блюпринт, наследовав его от полученного C++ класса.
Перевод хороший, только впервые встречаю термин "нод" в мужскому роде. Обычно же "одна нода", "две ноды", "создать ноду", не?
А по UE4 интересно было бы почитать подробный разбор графического стека.
Хорошим подходом будет создание объектов с помощью Blueprints. А когда требуются дополнительные возможности, преобразование их в C++.
Вот прямо-таки вредный совет, на мой взгляд. Наоборот же, хорошим подходом будет создавать базовые классы в C++, а уже от них наследовать блюпринты.
Ну и нативизация блюпринтов, по слухам, генерирует не слишком качественный код (впрочем, опыта в этом у меня пока нет).
Туториал по Unreal Engine. Часть 1: знакомство с движком