Please, stop using Level Blueprints. Now.
Unreal Engine’s Blueprints Visual Scripting is probably the most famous UE feature and it’s good for starting learning programming, prototyping, data-driven development with all core mechanics written in C++ and just overriding properties in BPs, or implementing the Observer design pattern when the core implementations are written in C++, with additional BlueprintImplementableEvents, BlueprintNativeEvents or BlueprintAssignable delegates that can be overridden in BPs with some cosmetic implementations.
However, Blueprints are not so great in terms of performance or extending the default tools provided by UE, so you shouldn’t make an entire game with them unless you work on some very simple project and plan to release it on just one platform.
The major issues with Blueprints in general are:
- Object references
- Pure functions
- Bad performance in handling tick functions or big containers because of how Blueprints are compiled
- Classes, Structs or Enums created in BPs cannot be used in C++, but same things created in C++ can be used both in C++ and BPs
Here is a detailed UE documentation article about how BPs and C++ should be combined:
‼️ And it’s probably one of the most important articles in the whole UE docs. ‼️
Level Blueprints are just bad for almost everything
Among all Blueprint types, Level Blueprints have the worst design and have barely any advantages¹. They have very limited support for OOP concepts and their main problems are:
Weird inheritance support
Yes, Level Blueprints support some inheritance — you can create a base class that inherits from ALevelScriptActor both in BP and C++ and add some generic implementations that should be reusable in every Level Blueprint in the game. Then you can set that class in Project Settings->Engine->General Settings->Level Script Actor Class and it will be used as a default parent class of every Level Blueprint in the game.
However, you can set both BP and C++ classes as a default class, but if you want to reparent a specific Level Blueprint in File->Reparent Blueprint, only C++ classes will be allowed. Also, Level Blueprints don’t show you the class they currently inherit from like other Blueprints. Those issues might lead to potential problems with the binary asset after changing the parent class too carelessly.
No access to other Level Blueprints
By default, it’s not possible to access other Level Blueprints properties in the Level Blueprint Event Graph. It was done on purpose most likely because you need to load another level for that, which might have a huge impact on performance. Although you can write a BP node in C++ for that (it’s a latent node because big assets should be loaded asynchronously):
But still, you will have very limited access to Level Blueprint properties, because the ALevelScriptActor class has the MinimalAPI UCLASS specifier (unless you work with Interfaces).
What do those issues mean?
Because of the Level Blueprints design, many people don’t use any good programming principles in them at all. The DRY principle is commonly broken in Level Blueprints because many people copy-paste the same implementation into every Level instance. The fact that the polymorphism in Level Blueprints is very limited means that the KISS principle is also often broken and the implementations made there are usually painful to work with.
‼️ Also, keep in mind that Level assets are essential for other teams — artists, level designers, and so on. So you shouldn’t lock them often and block other people’s work. ‼️
So are Level Blueprints good for something?
The only thing they’re safe and useful for is testing your implementations in your test levels.
What should I use instead of Level Blueprints?
- Other classes from the Unreal Engine Gameplay Framework:
UGameInstance,AWorldSettings,AGameModeBase,AGameStateBase,APlayerState— the choice depends on what exactly you want to implement - Unreal Subsystems (preferably derived from
UWorldSubsystem) - External plugins like FlowGraph or Arcweave
[1]: This article was made from the UE 5.3 perspective. Theoretically, the issues mentioned there might be fixed in the future release, but it’s not very likely because ever since I can remember they have been present in UE.
Do you like my articles? Please consider supporting me. Thank you!
