If you’re primarily a C++ developer and you’re learning to use UE5, are there any guidelines for when to implement something in C++ or when to implement it using Blueprint?
Is Lyra a good example to follow in that regard?
You should do as much as possible (and as soon as possible) in c++.
Blueprints are basically a limited version of what you can do in c++ and managing or porting it to c++ can become a pain quite quickly. As an experienced c++ dev you will probably write logic faster in VS than in Blueprint. Blueprint is also not text based so if you are used to version control like Git you want to stick with c++.
There’s a but… Some systems like UMG (UI designer) and the bone animation system (anim blending, state machines etc) are easiest to edit in-editor using Blueprints and the editor panels. That is where you want to make a base class in c++ containing all of the base functionality and inherit from it in blueprints. For example I use blueprints only to create widget variations from my base classes, where I reserve blueprints completely for the UI designer.
3 Likes
I totally disagree. No matter how much c++ experience you have you will start with zero Unreal Engine code base experience and stumble around a lot.
You should get familiar with the engine by making Blueprints and only use c++ for the stuff that you can’t do in Blueprint.
Then move stuff into c++ as you get familiar with the engine.
As a c++ programmer you will need to get familiar with Blueprints anyway because you need to know what to expose to Blueprint and why so learning Blueprints is not a waste of time.
2 Likes
If you browse the few Blueprint exposed c++ libraries like Kismet and UGameplaystatics, read the official documentation on UPROPERTY / USTRUCT / UFUNCTION / UCLASS and delegates then that is all you need to see as an experienced programmer to see how Blueprints and C++ are related.
It’s also good to read about some common classes like the UObject, APawn, ACharacter, AActorComponent, APlayerController, UGameMode, AGameState, UGameInstance and the different subsystems on the docs. Unless you need every bit of info out of tutorials you can perfectly fine figure out most things by reading c++ and scanning using a tool like Agent Ransack.
I wrote this BP / C++ comparison list a while ago hoping it will save someone else some time.
1. Blueprints have limited access to anything written in c++, this is also true the other way around.
2. Blueprint maintenance can not be done with quick text operations as you are forced to work with nodes and editor panels.
3. Moving existing Blueprints to c++ takes time.
4. c++ file changes are tiny, can easily be compared, logged, merged and restored through version control. With Blueprints this is not the case as they are binary files.
5. Blueprint files can corrupt easily.
6. Large Blueprints, often the case with animation Blueprints save and compile very slowly.
7. Working with structs is easier in c++, as you have more control over its properties and default values. Through meta tags you can also specify property limits for Blueprints like min / max values and modifiability.
8. Blueprints do not show protected properties on the MyBlueprint tab.
9. Blueprints sometimes require a large amount of nodes which would be a oneliner in c++.
10. In Blueprints, distinguishing class members from local variables in the node system can be confusing. I personally store any Blueprint function parameter as local variable, suffixed with underscore to keep my sanity, but this is not required at all when working in c++ with visual studio.
1 Like
To be fair that is not a comparison it is a C++ Pros without the Cons.
Here is the Cons.
- c++ takes much longer to compile than Blueprint
- Many c++ changes require the engine to be restarted wasting time.
- c++ mistakes will crash the engine at the most inconvenient times.
- Quick prototyping is not possible with c++ due to the above.
- Tutorials and guides are few and far between compared to Blueprint.
This is highly dependent on who you are, what your role is and what you are doing.
As a C++ developer prior to working in Unreal, 1-3 aren’t cons so much as how C++ development just works. Is it a con to have to install/learn a new IDE for a different language or just part of working with that language? Another thing that I think balances this out a lot is that you can frankly write better code in C++ than in Blueprint. For all it’s power it still pretty limited. Pointers to structures and nested containers (TArray< TArray < > >) are just two of the tools you can pull out in C++ that can’t be done in blueprint (yes I know about the workarounds for nested containers) to write potentially better systems.
#4, while possibly true, quick prototyping and development are not the same thing. Its value is also highly dependent on the required turn around time. It’s one thing if I’m developing and iterating on something by myself. It’s something else entirely if my prototype has to be evaluated by a design group for any iteration feedback.
#5, but even those are too specific. They show you how to build something, not teach you anything about how things work. A tutorial might show you how to build A, but rarely leaves you with the skills to build B which might be similar. At some point every developer needs to lift their skills beyond tutorials to work from the documentation/source. I’m a wiz at building LEGO sets, but I couldn’t begin to build anything from scratch that looks that good.
In a team environment I can’t stress enough the problems with blueprints becoming bottlenecks because they can’t be edited by multiple people at the same time. Seda145 touched on this but it’s a real problem when you’re in the middle of work and require a blueprint that someone else is also in the middle of a task and can’t release it for sometime.
@Dissonant_Theory Ultimately I don’t think there are very good guidelines for this. The truth is probably somewhere in between Seda145’s and GarnerP57’s viewpoints. A lot of it depends on what you’re building, who you’re building it with and who you’re building it for.
I do most of my home development in C++. I have a lot of experience there and am much faster at development there. But I have plenty of things I use blueprint for other than UI: mission scripts (iteration time reason) and async/latent features (since blueprint does that easier than code).
At work I also tend to do most development in C++ for the same reason, but there’s much more exposed and done in blueprint because I’ll have to work with others that can modify those things and not C++. So a system I might have built entirely in C++ gets split up between C++ and blueprint.
When answering the question C++ or Blueprint you really want to take it system by system and not necessarily lay down rules across the entire project. Who has time to build it? Who needs to modify it? Who’s doing iteration reviews? What are the performance needs? etc, etc…
2 Likes
I’d like to add that if your c++ code is for gameplay, you can boot the game on its own process from the editor (standalone) then a crash or assert will not affect the editor.
For me, Blueprint is for prototyping and tweaking variables, and the real code is always C++.
2 Likes
I use blueprint when I’m about to implement something I don’t quite know how to approach for the best results, once I figured out the best method I then convert the BP to C++.