I’m more into C++ and I want to know the benefits of using C++ in UE .
Balancing Blueprint and C++ | Unreal Engine 4.27 Documentation.
tl;dr:
C++ Class Advantages
- Faster runtime performance: Generally C++ logic is significantly quicker than Blueprint logic, for reasons described below.
- Explicit Design: When exposing variables or functions from C++ you have more control over exposing precisely what you want, so you can protect specific functions/variables and build a formal “API” for your class. This allows you to avoid creating overly large and hard to follow Blueprints.
- Broader Access: Functions and variables defined in C++ (and exposed correctly) can be accessed from all other systems, making it perfect for passing information between different systems. Also, C++ has more engine functionality exposed to it than Blueprints.
- More Data Control: C++ has access to more specific functionality when it comes to loading and saving data. This allows you to handle version changes and serialization in a very custom way.
- Network Replication: Replication support in Blueprints is straightforward and is designed to be used in smaller games or for unique one-off Actors. If you need tight control over replication bandwidth or timing you will need to use C++.
- Better For Math: Doing complicated math can be difficult and somewhat slow in Blueprints, so consider C++ for math-heavy operations.
- Easier to Diff/Merge: C++ code and data (as well as config and possibly custom solutions) is stored as text, which makes working in multiple branches simultaneously easier.
Blueprint Class Advantages
- Faster Creation: For most people creating a new Blueprint class and adding variables and functions is quicker than doing something similar in C++, so prototyping brand new systems is often faster in Blueprint.
- Faster Iteration: It is much quicker to modify Blueprint logic and preview inside the editor than it is to recompile the game, although hot reload can help. This is true for both mature and new systems so all “tweakable” values should be stored in assets if possible.
- Better For Flow: It can be complicated to visualize “game flow” in C++, so it is often better to implement that in Blueprints (or in custom systems like Behavior Trees that are designed for this). Delay and async nodes make it much easier to follow flow than using C++ delegates.
- Flexible Editing: Designers and artists without specific technical training can create and edit Blueprints, which makes Blueprints ideal for assets that need to be modified by more than just engineers.
- Easier Data Usage: Because storing data inside Blueprint classes is much simpler and safer than inside C++ classes; Blueprints are suitable for classes that closely mix Data and Logic.
1 Like
I can confirm all the points brought above, there are some disadvantages to C++ though, the biggest one is that if you’re not using live coding (or refusing to do so because of project breaking engine bugs), every time you make a change you have to recompile and reopen the editor, which is slooow
We also had all our project in BP (prototyping phase) and we had some performance issues, when we migrated to C++ we saw a pretty big performance uplift
I would also add another points for C++:
- Custom structs used on DataTables are more easily modified
- Looping through stuff is significantly easier than in blueprints, more so if you use breaks
- Custom functions on structs can be called in C++ (no functionality for blueprints, as the can’t be marked as UFUNCTION)
From experience, we had tons of problems when we had blueprint structs, adding a new variable or renaming one completely broke our tables, migrating the structures to C++ all those problems were gone, word of caution tho, if you modify a struct, you better not use live coding for that, as it may well corrupt your data table.
On the broader access to engine functions and variables, filtering arrays and doing array search is leagues easier in C++, in BP you’re compelled to use a for loop, in C++ you have various find functions and you can even use custom defined search functions as well
I would follow the recommendations on the documentation page that was linked, it’s pretty on point, Blueprints are not the enemy and they are there to help you, so use them to your advantage (default setting blueprints for example is pretty neat, you do everything in C++ and make a child BP class so you can change your defaults easily in the editor without needing to recompile)
The Architecture Notes in the previous link highlight a lot of the issues mentioned above, too:
- casting when it can be easily avoided
- ticking things that do not need it
- enums & structs (my personal pet peeve)
- looong loooops - Blueprint vs C++ Performance - YouTube
- cyclical references (used to be a nightmare before 4.18 or thereabouts)
- hard references (still a little nightmare)
a.k.a. common BP traps
I’ll add:
- misuse of Get All Actors of Class
- widget property binding
Avoid those.
1 Like