Das ist die Frage die jeder Unreal-Dev irgendwann trifft. Meistens um Monat zwei rum wenn jemand auf Discord sagt „echte Spiele nutzen C++" und du beginnst zu panicen dass dein All-Blueprint-Prototyp zum Scheitern verurteilt ist.

Ist er nicht.

Das meiste der Online-Debatte ist zwischen zwei Lagern: „Blueprints sind langsam, nutz C++" und „Blueprints sind fine, C++ ist Overkill". Beide haben teilweise recht. Keines ist die Frage die du stellen solltest.

Die eigentliche Frage ist: welches Tool passt zu diesem speziellen Code-Stück, gegeben allem anderen das du jonglierst?

Warum „C++ für Performance" irreführend ist

Du siehst das überall: „Nimm C++ für Performance, Blueprints fürs Prototyping." Behandelt die Wahl als einen einzigen Regler. In der Praxis sind Blueprints meist schneller zu entwickeln, und der Runtime-Unterschied ist oft egal.

Konkrete Zahlen aus meinem eigenen Profiling:

  • Eine Blueprint-Funktion mit simpler Arithmetik und ein paar Node-Calls: ~5–10× langsamer als äquivalentes C++. Pro Call.
  • Pro Call. Also eine Funktion 100× pro Frame aufgerufen: vielleicht 0,05 ms in Blueprint vs 0,005 ms in C++.
  • Für 99% der Spiel-Logik ist das unsichtbar. Für etwas das pro Pixel oder pro Partikel läuft zählt's. Fast nichts was du im ersten Jahr schreibst läuft pro Pixel.

Wo Blueprints tatsächlich langsam werden:

  • Enge Schleifen mit Tausenden Iterationen. Ein For Each Loop über ein 5000-Element-Array mit Per-Element-Mathe in Blueprint ist spürbar. Die gleiche Schleife in C++ ist gratis.
  • Cast-lastiger Code der große Assets lädt. Jeder Hard Cast zieht die gecastete Klasse vollständig in den Speicher. Kein Performance-Problem — ein Memory- und Load-Time-Problem.
  • Tick-lastige Logik auf vielen Actors. 200 Actors die jeweils ein nicht-triviales Tick in Blueprint laufen lassen summieren sich. Per-Frame-Logik nach C++ verschieben oder die Actors zu einem zentralen Manager.

Für die meiste Spiel-Logik — Abilities, Interactions, AI Behaviour Trees, UI — sind Blueprints völlig fine.

Wann Blueprints gewinnen — auch zur Laufzeit

Drei Fälle in denen ich tatsächlich zu Blueprint statt C++ greife, nicht trotz Performance sondern wegen:

  • Iterations-lastige Logik wo die Architektur noch nicht steht. Du wirst das Design diese Woche sechsmal ändern. Compile-Zeit in C++ killt die Schleife. Blueprints recompilen in 200 ms.
  • Designer-getriebener Content. Wenn dein Level Designer Trigger-Sequenzen verkabeln muss, fasst er Blueprints an, nicht deine C++-Klasse. Das Interface in Blueprint zu haben ist die richtige Entscheidung.
  • Alles One-Off oder spiel-spezifische. Ein einzigartiger Boss-Fight, eine Tutorial-spezifische Scripted Sequence — da gibt's keinen Wiederverwendbarkeits-Vorteil von C++, und Blueprint ist schneller zu schreiben.

Wann C++ wirklich unvermeidlich ist

Zwei echte Fälle:

  • Alles was die Engine nicht zu Blueprint exposed. Custom Render Passes, Low-Level-Networking, Custom AI Pawns, Integration mit einer Drittanbieter-C/C++-Library, Custom Niagara Modules. Die Engine hat Hooks dafür nur in C++.
  • Performance-sensitive Systeme die du gemessen hast. Beachte das Wort gemessen. Wenn du vermutest Blueprint sei langsam, profile erst (stat unit, stat game, Insights Trace). Oft ist die langsame Stelle nicht das was du dachtest.

Das Hybrid-Muster mit dem du dich nicht entscheiden musst

Das Muster zu dem die meisten professionellen Projekte konvergieren:

  • C++ für engine-nahe Base-Klassen, performance-kritische Utilities und alles was ein echtes Subsystem sein muss.
  • Blueprint für spiel-spezifische Subklassen, Gameplay-Logik, Content-Tuning.

Konkret: ein UMyGameplayAbility : UGameplayAbility in C++. Dutzende BP_Ability_Fireball, BP_Ability_Heal Blueprints die's erweitern. Die C++-Basis liefert die Infrastruktur (Cooldown-Handling, Networked Activation, Animation-Hooks). Jedes Blueprint beschreibt nur seine Ability.

Du kannst ein ganzes Spiel so bauen: dünne C++-Skelette, fettes Blueprint-Fleisch. Das C++ ändert sich nicht oft sobald es stabil ist. Die Blueprints ändern sich täglich.

Noch besser: die meisten Plugins (und gute Architektur) machen das C++ optional. Du kannst das gleiche Spiel zu 100% in Blueprint bauen, mit etwas schwererem Per-Call-Cost. Später kannst du den einen Hot Path identifizieren der C++ braucht, NUR den nach C++ heben und den Rest lassen.

Die Kosten von C++ die im Vergleich nicht stehen

Artikel-Vergleiche listen üblicherweise „C++ Pros: schnelleres Runtime, mehr API-Zugriff". Sie listen selten:

  • Compile-Zeiten. Jede C++-Änderung dauert 5–60 Sekunden zum Recompilen und Hot-Reloaden. Live Coding hilft, ist aber nicht kugelsicher. Blueprint: 200 ms.
  • Setup-Overhead. Visual Studio installieren, IntelliSense-Langsamkeit, Project-File-Regeneration, mit Live-Coding-Flakiness umgehen. Nichts davon existiert im Pure-Blueprint-Workflow.
  • Crash-Debugging. Ein Blueprint mit Bug zeigt dir einen roten Error. Ein C++-Crash schmeißt dich in einen Stack Trace und .pdb-Symbol-Lookup. Lohnt sich zu lernen, aber ein echter Zeitfresser.
  • Source-Control-Konflikte. Zwei Devs editieren dasselbe Blueprint = einer gewinnt, kein Merge. Gleiche C++-Datei = mergeable aber fehleranfällig. Beide haben Issues; einfach andere.

Wenn du solo bist und lernst, ist All-Blueprint eine völlig vertretbare Wahl für dein erstes Projekt — und ein Blueprint-only-Projekt zu shippen ist völlig möglich. Leute tun das.

Wann mit C++ anfangen

Praktische Antwort: in dem Moment in dem du auf etwas triffst was du in Blueprint nicht kannst. Nicht vorher.

Du wirst es merken weil entweder:

  • Ein Engine-Feature das du brauchst nicht als Blueprint-Node exposed ist, oder
  • Du profilest und einen spezifischen Hot Path findest der messbar langsam ist.

Dann erstellst du deine erste C++-Klasse, lernst UCLASS, UFUNCTION, UPROPERTY Macros, und los geht's. Du musst nichts konvertieren. Die existierenden Blueprints bleiben Blueprints. Die neue C++-Klasse fügt sich ein.

Typische Fehler

  • Auf C++ wechseln „für Performance" ohne zu profilen. Du wirst eine Woche damit verbringen ein Blueprint zu konvertieren das in 0,02 ms lief. Der eigentliche Hot Path war in einem ganz anderen System.
  • Als Anfänger ein volles C++-Projekt von Null bauen. Du wirst wochenlang mit Visual Studio und Live Coding kämpfen bevor du Spiel-Logik schreibst. Blueprint starten; C++ dazu wenn du gegen eine Wand läufst.
  • Ein einzelnes Feature über beide Sprachen verteilen ohne klare Grenze. „Hälfte des Inventars in C++, Hälfte in Blueprint" führt dazu dass du Types über die Grenze koordinierst jedes Mal wenn du ein Feld hinzufügst. Eine Grenze wählen und dabei bleiben.
  • Blueprint aus einer C++-Schleife aufrufen. Die Marshalling-Kosten sind real. Wenn du eine Blueprint-Funktion 10000-mal pro Frame aufrufst, dort wird der C++-Overhead tatsächlich sichtbar.

Die 30-Sekunden-Zusammenfassung

  • BP ist meist 5–10× langsamer pro Call als C++. Für 99% der Spiel-Logik irrelevant.
  • BP gewinnt bei Iterationsgeschwindigkeit, Designer-Freundlichkeit, One-Off-Content.
  • C++ gewinnt bei Engine-Erweiterung, gemessenen Hot Paths, echten Subsystemen.
  • Das Pro-Muster: C++ dünne Base-Klassen + Blueprint fette Subklassen.
  • Blueprint-only starten. C++ dazu wenn du gegen eine Wand läufst — nicht preemptiv.
  • Vor „Optimierung" nach C++ profilen.

Hier gibt's keinen Antwort-Schlüssel. Beide sind legitime Tools. Die Entscheidungen die du am meisten bereust sind nicht „ich habe Blueprint genommen" oder „ich habe C++ genommen" — es sind „ich habe mich auf eines festgelegt bevor ich die Form des Problems kannte".

Das ist die Post-Serie bis hierher — Welcome, Soft References, Async Loading, First Project Setup, Common Errors, Enhanced Input, Blueprint-vs-C++. Sechs Wochen Grundlagen. Nächsten Sonntag gehen wir zurück in reines Blueprint-Territorium: Blueprint Interfaces — hör auf alles zu casten. Das Muster das das Cast-Spaghetti-Problem fixt das wir immer wieder andeuten. Bis dann.

— Marco