Blueprint or C++ in Unreal: how I decide where each piece of logic belongs

One of the most common questions for anyone studying Unreal Engine is deciding when to use Blueprint and when to use C++.

The question sounds simple, but in practice it appears all the time.

Should I build the interaction system in Blueprint? Should I create the character in C++? Should the UI talk directly to the Character? Should the combat logic live inside an Ability? Is it worth turning this into a component? Am I overengineering the architecture?

I am still building my own answer to these questions, but I already have an initial practical rule.

Blueprint is not wrong

For a long time, I felt that using too much Blueprint was a sign of bad code.

But that is a limited view.

Blueprint is a central tool in Unreal Engine. It is great for prototyping, configuration, connecting visual elements, and enabling fast iteration.

The problem is not using Blueprint.

The problem is using Blueprint without criteria.

A Blueprint can become bad for the same reasons C++ code can become bad: too many responsibilities, coupling, duplication, and lack of clarity.

C++ does not solve everything by itself either

On the other side, moving everything to C++ is not automatically better.

C++ can make a system more robust, reusable, and performant, but it can also slow development down when it is used for things that need a lot of visual iteration.

One of Unreal’s strengths is precisely the combination:

C++ defines the base, structure, and rules;
Blueprint adjusts behavior, visuals, data, and variations.

The question should not be:

“Blueprint or C++?”

A better question is:

“Which part of this system needs to be structure, and which part needs to be configuration?”

My current practical rule

For now, I am using this split:

C++ for structure

I tend to prefer C++ when the logic:

defines central rules;
needs to be reused;
will be the base for several Blueprints;
requires more rigid organization;
involves important gameplay systems;
needs to be easier to test and maintain;
can grow with the project.

Examples:

base Actor for a door;
interaction component;
health system;
ability structure;
enemy base class;
main input flow;
stamina rules;
damage logic.

Blueprint for variation

I tend to prefer Blueprint when the logic:

needs fast iteration;
depends heavily on assets;
involves animation, effects, or sound;
configures values;
creates variations of a base class;
connects visual elements;
will be adjusted in the editor.

Examples:

a BP_Door with a specific mesh;
ability effects;
animation curve adjustments;
value configuration;
UI connections;
visual events;
enemy variations.

Example: a door

Imagine a door system.

One approach that makes sense to me is:

ADoor in C++;
exposed variables such as speed, initial state, and whether it is locked;
an OpenDoor function;
a CloseDoor function;
an interaction event or interface;
BP_Door inheriting from the C++ class;
mesh, sound, and effects configured in Blueprint.

This keeps the main rule organized in C++, while visuals and adjustments stay in Blueprint.

That creates a healthy separation.

C++ answers:

“What is a door in the system?”

Blueprint answers:

“How does this specific door appear and behave in the game?”

The risk of a giant Blueprint

The problem appears when a Blueprint starts doing everything.

For example:

receives input;
changes stamina;
plays animation;
applies damage;
updates UI;
plays sound;
decides cooldowns;
checks enemy state;
manages effects;
saves data.

At first, it works.

Later, it becomes a huge graph where any change can break something else.

When that happens, maybe the problem is not Blueprint itself. The problem is that the system has no separation of responsibilities.

The risk of overly rigid C++

The opposite mistake also exists.

Creating abstractions too early can make a project slow and difficult to experiment with.

Sometimes an idea is not mature enough yet to become a well-defined C++ class.

In those cases, Blueprint can be a good space to discover the behavior before turning it into structure.

One rule I want to follow is:

Understand the behavior first. Turn it into architecture later.

Not everything needs to be perfect from the beginning.

How I am trying to decide

When I create new logic, I try to answer a few questions:

Will this logic be reused?
Does it define a central rule of the game?
Does it need to be adjusted quickly in the editor?
Does it depend on visual assets?
Can it become a base for several objects?
Is it coupling too many systems?
Is it likely to grow?

If the logic defines structure, I think about C++.

If the logic defines variation, I think about Blueprint.

If I do not understand the system well enough yet, I may start in Blueprint and refactor later.

My current conclusion

Blueprint and C++ are not enemies.

The best use of Unreal seems to come from combining both.

C++ helps create solid foundations. Blueprint helps iterate, configure, and turn those foundations into something playable.

The challenge is not choosing a side. The challenge is defining responsibilities.

My current rule is simple:

C++ for structure. Blueprint for variation.

It is not an absolute rule, but it is a good starting point.

The next step is to apply this idea to a small system: create a base class in C++ and use Blueprint only to configure visuals, values, and feedback.