How do you use blue print and C++ code in parallel when developing Unreal Engine 5 games?

How do you use blue print and C++ code in parallel when developing Unreal Engine 5 games?
I’m trying to develop a game with C++, but blue print is more convenient.
However, since C++ is faster in terms of speed, we are eventually changing the blue print to C++ and proceeding.
What would be effective in developing more?

Not sure I understand what you’re asking. I can give some tips on what I do to move stuff from blueprint to C++ a little easier.

All classes can be derived in C++. This means you can create custom C++ classes for everything you use (Tool/New C++ Class menu). In the editor, you can create Blueprints from all your custom C++ classes.

You’ll get inheritance like this.

Blueprint → My C++ class → Engine class (actor, pawn, character, component, etc.)

This means your blueprint has access to everything in your C++ class (if it’s indicated as blueprint accessible), but not the other way around.

So as you move stuff from Blueprints to your C++ class, you can just replace blueprint graphs or functions as C++ functions with UFUNCTION(BlueprintCallable) above it. You can even move your variables to C++ as UPROPERTY(EditAnywhere, BlueprintReadWrite). This way, your blueprints still have access to all the C++ variables and code.

If you want access to blueprint functions from C++, you declare something like this in your C++ class.

UFUNCTION(BlueprintNativeFunction)
void MyFunction(int param1);

In your .cpp file, you can add a default implementation. Note the method name is different, but you still call it with MyFunction(number);

void MyClass::MyFunction_Implementation(int param1)
{
// add code here.
}

And in your blueprint, you can implement that function. If you do implement it in a Blueprint, the blueprint implementation will be called instead. If BP does not implement it, the C++ implementation will be called when you call MyFunction(0); for example.

I used this in my game to update health widgets. All the damage logic is in C++, but to update the health widget, that’s handled in a blueprint, so I created a BlueprintNativeFunction that I could implement in a Blueprint and call from C++ to update the health widget.

You can also use delegates but that’s a whole other topic.

Anyhow, those are some of the techniques I use for moving stuff from Blueprint to C++.

1 Like

I build things in Blueprint, and if something ends up being impossible in Blueprint, or too slow, I make a new class in C++, and re-parent the Blueprint to have that class as its parent.

So, if I have a Blueprint derived from Pawn, and it starts getting too complex, I will make an AMyPawn C++ class that derives from APawn, and then re-parent the Blueprint to inherit from AMyPawn. Then I can start moving pieces of that blueprint into the C++, by declaring UPROPERTY and UFUNCTION for bits that are in the Blueprint, and then delete those same bits from the Blueprint itself.

It’s really not that different from re-factoring a big C++ class into two layers, except one of those layers are now the language of “Blueprint” so the “moving” of functionality requires also re-writing in C++ instead of node wiring, rather than just copy-pasting.

1 Like

Keep in mind that even though it may be faster theoretically you could easily waste a lot of development time for 1 µs improvement.

It is usually very few Blueprints that will benefit the project overall when being converted into C++.

1 Like

I use C++ mainly for plugins, things that may be reused accross multiple projects.
Then in Blueprint project specific overrides/event handlers are implemented, multiple plugins are tied together, the UI is done with UMG and audio-visual content is added.

Most plugins started as project-specific Blueprints and once they became stable enough they were refactored to c++.

1 Like

If you have a thousand of something, and you save 1 microsecond per thing per frame, that’s a millisecond per frame. That’s the difference between 91 fps and 100 fps.

Does this difference actually matter? That’s where a profiler comes in. Optimization is important, but it’s important to optimize the bits that actually matter, and whether your blueprints are in the “matters” category or not, only measurement will tell!

2 Likes