Wenn du diesem Blog seit dem Start folgst — Projekt-Setup, Blueprint-Fehler, Input, Saves, Performance — hast du jetzt ein Projekt, das im Editor prima läuft. Es zu paketieren fühlt sich an, als sollte das ein einziger Klick sein. Ist es auch. Der Klick macht nur fünf verschiedene Dinge, und jedes davon kann still scheitern.

Die drei Fehler, die fast jeder beim ersten Build trifft: ein schwarzer Bildschirm beim Start, ein Cook der mittendrin mit einem kryptischen Pfad-Fehler stirbt, oder eine fertige .exe, die zehnmal größer ist als sie sein sollte. Keiner davon ist ein Engine-Bug. Alle sind mit Settings fixbar, die du schon offen hast.

Development, Shipping, und was sich wirklich ändert

Development und Shipping sind nicht nur Labels — sie ändern echtes Verhalten:

  • Shipping entfernt Debug-Tooling. Konsolen-Befehle, stat-Overlays und der meiste UE_LOG-Output werden rausgekompiliert. Print String-Nodes werden auch übersprungen — aber nur, wenn deren Development Only-Checkbox aktiv ist, was der Default ist, aber gut zu wissen ist.
  • Shipping ist schwerer zu reverse-engineeren. Blueprint-lastige Projekte sind hier stärker exponiert als C++-lastige, weil Blueprint-Bytecode leichter zu zerlegen ist. Pak-Verschlüsselung (Project Settings → Packaging → „Use Pak File") schließt den Großteil dieser Lücke.
  • Shipping läuft schneller. Keine Debug-Checks, keine Editor-only-Codepfade, optimierte Compiler-Flags.

Für deinen ersten Playtest-Build paketiere Development — du willst die Logs. Wechsle erst zu Shipping, wenn das Spiel tatsächlich durchgehend läuft, denn Shipping-Fehler sind viel schwerer zu debuggen (das Crash-Log, das dir sagen würde warum, ist eines der Dinge die entfernt wurden).

Der schwarze Bildschirm beim Start

Die häufigste „warum ist mein Package kaputt"-Frage überhaupt. Der Editor öffnet, was du zuletzt angeschaut hast. Ein paketierter Build hat kein solches Gedächtnis — ihm muss explizit gesagt werden, was zu laden ist.

Fix in Project Settings → Maps & Modes:

  • Game Default Map — das Level, das beim Start lädt.
  • Editor Startup Map — separates Setting, betrifft nur den Editor. Die zwei nicht verwechseln.

Wenn beide gesetzt sind und es trotzdem schwarz bleibt: prüfe die World Settings → GameMode Override des Levels selbst — ein leerer oder falsch konfigurierter GameMode lädt das Level, spawnt aber nichts hinein.

Cook-Fehler: den echten Pfad lesen

„Failed to cook" ist der Fehler, aber der interessante Text steht darüber — das konkrete Asset und der konkrete Grund. Drei Ursachen machen den Großteil dessen aus, was du sehen wirst:

  • Leerzeichen oder Nicht-ASCII-Zeichen im Projekt-Pfad. C:\Users\Max Müller\Mein Spiel\ kann den Cook-Prozess mittendrin brechen. Projekt vor dem Paketieren auf einen einfachen Pfad verschieben (C:\Projects\MyGame\).
  • Dateiname zu lang. Windows hat ein absolutes Pfadlimit, und tief verschachtelte Content-Ordner plus lange Asset-Namen können es erreichen. Ordnerstruktur verkürzen statt gegen das OS-Setting anzukämpfen.
  • Veraltete oder verschobene Klassen. Ein alter GameMode oder Blueprint wurde umbenannt oder gelöscht, aber irgendetwas referenziert noch dessen alten Pfad. Asset-Namen im Reference Viewer suchen und die hängende Referenz fixen oder entfernen.

Log von oben nach unten lesen — der erste Cook-Fehler ist meist der echte, und jeder Fehler danach ist oft nur ein Symptom des ersten.

Einen aufgeblähten Build verkleinern

Ein leeres UE5-Projekt paketiert bereits auf rund 320 MB — das ist der Engine-Boden, kein Fehler von dir. Was du kontrollieren kannst, ist alles obendrauf. Es ist üblich, dass ein mittelgroßes Anfänger-Projekt bei 8-15 GB landet, während der tatsächliche Spiel-Content näher an 1-2 GB liegt. Diese Lücke ist fast immer eines von diesen:

  • Ungenutzte Plugins noch aktiviert. Jedes aktivierte Plugin wird gecookt, egal ob genutzt oder nicht. Project Settings → Plugins → alles deaktivieren, was du nicht aktiv nutzt.
  • Marketplace/Fab-Megapacks, größtenteils ungenutzt. Du hast ein 4-GB-Umgebungspaket für eine einzige Felsformation importiert. Nur referenzierte Assets werden gecookt — aber „referenziert" schließt alles ein, was noch von einem Level, einem Blueprint oder einer DataTable gezogen wird, die du vergessen hast.
  • Unkomprimierte Source-Texturen. 4K-Texturen, die du im Spiel bei 256px anzeigst, cooken trotzdem in voller Auflösung, wenn du keine Max-Size in den LOD-Settings der Textur setzt.

Zwei Tools um die echten Übeltäter zu finden: Window → Developer Tools → Size Map zeigt, was was zieht, sortiert nach Festplattengröße — meist der schnellste Weg, das eine Asset zu finden, das 2 GB an Abhängigkeiten mit sich zieht. Reference Viewer auf einem bestimmten Asset zeigt genau, was noch darauf zeigt, was dir sagt ob Löschen sicher ist.

Nur cooken, was du referenzierst

Standardmäßig cookt Unreal alles, was von deinen Maps und deinen Primary Asset-Regeln erreichbar ist, nicht deinen gesamten Content-Ordner — aber „erreichbar" ist breiter als die meisten denken. Ein Test-Level, das du zu löschen vergessen hast und das noch eine Debug-Prop-Library referenziert, zieht diese ganze Library in den Build. Vor deinem ersten echten Shipping-Package: Test-Levels, Debug-only-Blueprints und alles unter einem _Sandbox- oder Test-Ordner löschen oder ausschließen.

Das Ergebnis testen

Nie annehmen, dass das Package funktioniert, nur weil es ohne Fehler gebaut hat. Die tatsächliche .exe standalone ausführen, nicht über den Editor:

  • Prüfen, ob sie zur richtigen Map startet, kein schwarzer Bildschirm.
  • Deinen Core-Loop einmal durchspielen — Save/Load, Hauptmenü, was auch immer der Spieler zuerst anfasst.
  • Log-Ordner (Saved/Logs/ im paketierten Build) auf Warnungen prüfen, die in PIE still verschluckt wurden, hier aber auftauchen.

Wenn es standalone funktioniert, die Dateigröße aber trotzdem falsch aussieht, ist das ein Size-Map-Problem, kein Cook-Problem — zurück zum vorherigen Abschnitt.

Typische Fehler

  • Beim ersten Versuch gleich Shipping paketieren. Du verlierst das Debug-Log genau dann, wenn du es am meisten brauchst. Erst Development, Shipping erst wenn's bewiesen läuft.
  • „Keine Fehler" als „funktioniert" werten. Ein Cook kann sauber durchlaufen und trotzdem einen schwarzen Bildschirm produzieren — das ist ein Maps-&-Modes-Problem, kein Cook-Problem, und der Cook-Schritt prüft das nicht.
  • Jedes Plugin „sicherheitshalber" aktiviert lassen. Jedes zusätzliche kostet Cook-Zeit und Build-Größe ohne Nutzen, wenn ungenutzt.
  • Nur in PIE testen. Play-in-Editor nutzt Editor-only-Codepfade und fängt paketierungs-spezifische Fehler nicht ab. Immer den Standalone-Build ausführen, bevor du es als fertig bezeichnest.
  • Den ersten Cook-Fehler ignorieren und zum letzten scrollen. Der letzte Fehler im Log ist häufig nur ein Folge-Symptom, nicht die Ursache.

Die 30-Sekunden-Zusammenfassung

  • Erst Development paketieren wegen der Logs; erst zu Shipping wechseln wenn der Build tatsächlich läuft.
  • Schwarzer Bildschirm = Maps & Modes → Game Default Map, kein Cook-Bug.
  • Cook-Fehler: zuerst auf Leerzeichen/Nicht-ASCII im Pfad und überlange Dateinamen prüfen.
  • Ein leeres Projekt liegt bei ~320 MB Baseline — alles deutlich darüber sind ungenutzte Plugins oder unreferenzierte Megapacks.
  • Size Map und Reference Viewer zeigen dir genau, was den Build aufbläht.
  • Immer die Standalone-.exe testen, nie nur PIE.

Das ist die komplette Anfänger-Journey von leerem Projekt bis zu einem Build, den du jemand anderem in die Hand drücken kannst — Setup, Blueprint-Muster, Game-Systeme, World-Building, Performance und jetzt Shipping. Als Nächstes: ein Blick darauf, was sich im neuesten Unreal-Engine-Release tatsächlich geändert hat und was davon für Anfänger relevant ist.

— Marco