This is the question every Unreal dev hits at some point. Usually around month two, when someone on Discord says "real games use C++" and you start panicking that your all-Blueprint prototype is doomed.

It's not.

Most of the debate online is between two camps: "Blueprints are slow, use C++" and "Blueprints are fine, C++ is overkill". Both are partially right. Neither is the question you should be asking.

The actual question is: which tool fits this specific piece of code, given everything else you're juggling?

Why "C++ for performance" is misleading

You'll see this everywhere: "Use C++ for performance, Blueprints for prototyping." It treats the choice as a single dial. In practice, Blueprints are usually faster to develop with, and the runtime difference often doesn't matter.

Concrete numbers from my own profiling:

  • A Blueprint function with simple arithmetic and a few node calls: ~5–10× slower than equivalent C++. Per call.
  • Per call. So a function called 100 times per frame: maybe 0.05 ms in Blueprint vs 0.005 ms in C++.
  • For 99% of game logic, that's invisible. For something running per-pixel or per-particle, it matters. Almost nothing you write in your first year runs per-pixel.

Where Blueprints actually do get slow:

  • Tight loops with thousands of iterations. A For Each Loop over a 5000-element array doing per-element math in Blueprint is noticeable. Same loop in C++ is free.
  • Cast-heavy code that loads big assets. Every hard cast pulls the casted class fully into memory. Not a performance issue — a memory and load-time issue.
  • Tick-heavy logic on many actors. 200 actors each running a non-trivial Tick in Blueprint adds up. Move the per-frame logic to C++ or move the actors to a centralised manager.

For most game logic — abilities, interactions, AI behaviour trees, UI — Blueprints are entirely fine.

When Blueprints win — even at runtime

Three cases where I genuinely reach for Blueprint over C++, not despite performance but because of it:

  • Iteration-heavy logic where the architecture isn't settled. You'll change the design six times this week. Compile time in C++ kills the loop. Blueprints recompile in 200 ms.
  • Designer-driven content. If your level designer needs to wire up trigger sequences, they'll touch Blueprints, not your C++ class. Putting the interface in Blueprint is the right call.
  • Anything one-off or game-specific. A unique boss fight, a tutorial-specific scripted sequence — there is no reusability benefit to C++ here, and Blueprint is faster to write.

When C++ is genuinely unavoidable

Two real cases:

  • Anything the engine doesn't expose to Blueprint. Custom render passes, low-level networking, custom AI pawns, integrating with a third-party C/C++ library, custom Niagara modules. The engine has hooks for these only in C++.
  • Performance-sensitive systems you've measured. Note the word measured. If you suspect Blueprint is slow, profile first (stat unit, stat game, Insights Trace). Often the slow part isn't what you thought.

The hybrid pattern that lets you avoid choosing

The pattern most professional projects converge on:

  • C++ for engine-adjacent base classes, performance-critical utilities, and anything that needs to be a true subsystem.
  • Blueprint for game-specific subclasses, gameplay logic, content tuning.

Concretely: a UMyGameplayAbility : UGameplayAbility in C++. Dozens of BP_Ability_Fireball, BP_Ability_Heal Blueprints extending it. The C++ base provides the infrastructure (cooldown handling, networked activation, animation hooks). Each Blueprint just describes its ability.

You can build a whole game this way: thin C++ skeletons, fat Blueprint flesh. The C++ doesn't change often once it's stable. The Blueprints change daily.

Even better: most plugins (and good architecture) make the C++ optional. You can build the same game 100% in Blueprint with a slightly heavier per-call cost. You can later identify the one hot path that needs C++, lift just that into C++, and leave the rest.

The cost of C++ you don't see in the comparison

Article-form comparisons usually list "C++ pros: faster runtime, more API access". They rarely list:

  • Compile times. Every C++ change you make takes 5–60 seconds to recompile and hot-reload. Live Coding helps but isn't bulletproof. Blueprint: 200 ms.
  • Setup overhead. Visual Studio install, IntelliSense slowness, project file regeneration, dealing with Live Coding flakiness. None of that exists in pure-Blueprint workflow.
  • Crash debugging. A Blueprint with a bug shows you a red error. A C++ crash drops you into a stack trace and .pdb symbol lookup. Worth learning, but a real time sink.
  • Source control conflicts. Two devs editing the same Blueprint = one wins, no merge. Same C++ file = mergeable but error-prone. Both have issues; just different ones.

If you're solo and learning, all-Blueprint is a perfectly defensible choice for your first project — and shipping a Blueprint-only project is entirely possible. People do it.

When to start using C++

Practical answer: the moment you hit something you can't do in Blueprint. Not before.

You'll know because either:

  • An engine feature you need isn't exposed as a Blueprint node, or
  • You profile and find a specific hot path that's measurably slow.

Then you create your first C++ class, learn UCLASS, UFUNCTION, UPROPERTY macros, and you're off. You don't have to convert anything. The existing Blueprints stay Blueprints. The new C++ class slots in.

Common pitfalls

  • Switching to C++ "for performance" without profiling. You'll spend a week converting a Blueprint that ran in 0.02 ms. The actual hot path was in a different system entirely.
  • Building a full C++ project from scratch as a beginner. You'll fight Visual Studio and Live Coding for weeks before you write game logic. Start Blueprint; add C++ when you hit a wall.
  • Splitting a single feature across both languages with no clear boundary. "Half of the inventory in C++, half in Blueprint" leads to coordinating types across the boundary every time you add a field. Pick a boundary and stick to it.
  • Calling Blueprint from a C++ tight loop. The marshalling cost is real. If you're calling a Blueprint function 10000 times per frame, that's where C++ overhead actually shows up.

The 30-second recap

  • BP is usually 5–10× slower per call than C++. For 99% of game logic, irrelevant.
  • BP wins on iteration speed, designer-friendliness, one-off content.
  • C++ wins on engine extension, measured hot paths, true subsystems.
  • The pro pattern: C++ thin base classes + Blueprint fat subclasses.
  • Start Blueprint-only. Add C++ when you hit a wall — not preemptively.
  • Profile before "optimising" anything to C++.

There's no answer key here. Both are legitimate tools. The decisions you regret most are not "I picked Blueprint" or "I picked C++" — they're "I committed to one before I knew the shape of the problem".

That's the post series so far — Welcome, Soft References, Async Loading, First Project Setup, Common Errors, Enhanced Input, Blueprint-vs-C++. Six weeks of foundations. Next Sunday we get back into pure Blueprint territory: Blueprint Interfaces — stop casting everything. The pattern that fixes the cast-spaghetti problem we keep hinting at. See you then.

— Marco