Nach den letzten zwei Posts zu Soft References und Async Loading kamen ein paar Nachrichten: „Cool, aber ich habe den Editor gerade zum ersten Mal aufgemacht — wo fange ich überhaupt an?" Berechtigt. Schritt zurück.

Dieser Post ist das was ich vor meinem ersten UE-Projekt gerne gelesen hätte. Geht nicht um Gameplay oder Optik — es sind die dreißig Minuten Setup die entscheiden ob du in sechs Monaten glücklich mit dem Projekt bist oder ob du es heimlich umschreibst.

Wähl ein Projekt-Template — aber vertrau ihm nicht

Wenn du ein neues Projekt erstellst gibt Unreal dir ein Template: Third Person, First Person, Top Down, Blank. Nimm das was deinem Spiel am nächsten kommt. Im Zweifel Third Person — da ist am meisten echtes Zeug schon verkabelt (Input, Kamera, Character Movement).

Zwei wichtige Schalter im New-Project-Fenster:

  • Starter Content: AUS. Du wirst die Würfel-Plattform-Demo nie nutzen, sie bläht das Projekt um ~200 MB auf und schleppt Referenzen ein die du später wegräumen darfst.
  • Raytracing: AUS außer du hast einen konkreten Grund. Ist schwer und die meisten seiner Features (Lumen, Nanite) sind in UE5 sowieso standardmäßig an.

Nimm Blueprint als Projekttyp auch wenn du irgendwann C++ schreiben willst. C++ kannst du jederzeit später dazustecken — und es kann sein dass du es monatelang nicht brauchst. Blueprint-only zu starten hält deine Iteration kurz.

Die Ordner-Struktur die wirklich skaliert

Sei hier nicht clever. Nimm die Konvention die alle anderen auch nutzen:

CB0

Zwei Regeln:

  • Kategorisiere nach Zweck, nicht nach Asset-Typ. Content/Materials/Player/M_PlayerSkin ist falsch. Content/Characters/Player/M_PlayerSkin ist richtig. Wenn du den Player löschst, geht alles Dazugehörige mit weg.
  • Nutze einen _Developers/<deinname>/ Ordner für Wegwerf-Sachen. Alles da drin ist implizit „WIP, noch nicht fürs Projekt". Auch als Solo-Dev sinnvoll — dort kommen Test-Maps und Einmal-Blueprints rein die du noch nicht festgelegt hast zu behalten.

Naming-Konventionen

Unreal hat eine Community-Standard-Naming-Konvention. Nutz sie:

  • BP_ Blueprint-Klasse (z.B. BP_PlayerCharacter)
  • M_ Material
  • MI_ Material Instance
  • T_ Textur
  • S_ Skeletal Mesh, oder SM_ Static Mesh
  • A_ Sound (Audio)
  • Anim_ Animation Blueprint oder Sequence
  • WBP_ Widget Blueprint (UMG)
  • DA_ Data Asset
  • DT_ Data Table
  • E_ Enum
  • L_ Level / Map
  • NS_ Niagara System

Sieht zwei Tage lang pedantisch aus, dann rettet's dir jeden weiteren Tag den Hintern. Die Suchleiste im Content Browser wird nützlich sobald du BP_ tippst und nur Blueprints siehst.

Diese Project Settings am ersten Tag setzen

Geh in Edit → Project Settings und ändere das jetzt, nicht später:

  • Engine → General Settings → Use Fixed Frame Rate: im Editor aus lassen, aber überleg in den Editor Preferences Max FPS auf 120 zu setzen damit der Editor nicht deine GPU verheizt.
  • Engine → Rendering → Lumen Global Illumination: an lassen wenn du auf UE5 bist, aber Software LumenHardware Lumen nur wenn du ne RTX-Klasse GPU hast.
  • Maps & Modes → Default Maps: setz Editor Startup Map und Game Default Map auf deine Level, nicht das Engine-Sample.
  • Project → Description: Company Name, Project Name, Copyright Notice eintragen. Das landet später in der gepackten exe — du willst nicht „MyAwesomeGame © 2026 Epic Games" ausliefern.
  • Project → Packaging → For Distribution: AUS vorerst, aber merk dir dass der Schalter existiert.

Versionierung — Git LFS, auch als Solo-Dev

Ja, auch für ein Solo-Projekt. Future-Du wird Present-Du danken. Das Setup:

  1. Git-Repo im Projekt-Root initialisieren (gleicher Ordner wie die .uproject).
  2. Git LFS installieren.
  3. Eine .gitattributes anlegen die Binärdateien per LFS trackt:

CB1

  1. Eine .gitignore anlegen die die regenerierbaren Ordner ausschließt:

CB2

  1. Früh committen, oft committen. Commit vor jedem größeren Refactor — git reset --hard kann dir Stunden retten.

GitHub gibt dir 1 GB LFS-Storage gratis, danach 5 $/Monat für 50 GB. Lohnt sich.

Was du NICHT tun solltest — Tag-Eins-Fehler

  • Pack nicht alles in BP_PlayerCharacter. Verlockend weil er Tick, Input und Viewport hat. Auch der Weg zu einem 5000-Node-Monster. Inventar? Eigene Component. Save-System? Eigener Manager. Quests? Eigenes Subsystem. Der PlayerCharacter soll orchestrieren, nicht enthalten.
  • Ordner nicht außerhalb des Editors umbenennen. Nutz den Content Browser → Rechtsklick → Rename. Unreal updated dann die Referenzen für dich. Umbenennen via Windows Explorer bricht jede Reference still.
  • Marketplace-Assets nicht in deinen normalen Ordner-Tree mischen. Halt sie unter Content/Marketplace/<PackName>/. Wenn du sie updatest willst du sie nicht zwischen deinen eigenen Assets haben.
  • „Use Source Control" in den Editor Settings nicht ausschalten. Auch wenn du kein Perforce nutzt — das ist der Schalter der dir im Content Browser zeigt welche Assets du geändert hast.

Typische Fehler

  • Default Map vergessen zu setzen. Du packst Wochen später dein Spiel und das exportierte Spiel öffnet TemplateMap.umap statt deines Titel-Screens. Beide Default Maps jetzt setzen.
  • Auf Desktop arbeiten statt in einem dedizierten Dev-Ordner. Lange Pfade unter Windows + Unreals tiefe Ordner-Verschachtelung = Path-Length-Fehler. Projekt unter C:\Dev\<ProjektName>\ oder ähnlich ablegen.
  • Leerzeichen im Projektnamen. Das meiste geht, aber einige Plugin-Packaging-Schritte brechen still bei Leerzeichen. MyGame ist OK. My Awesome Game beißt dich in Monat vier.
  • Symbol Server in Visual Studio nicht aktiviert wenn du C++ machst. Engine-Crashes ohne Symbols debuggen ist Misery. Project Settings → Programming → beide Symbol Server an.

Die 30-Sekunden-Zusammenfassung

  • Template Third Person, Starter Content aus.
  • Ordner nach Zweck, nicht nach Asset-Typ.
  • Naming-Konvention die alle nutzenBP_, M_, T_, WBP_, DA_, etc.
  • Project Settings: Default Maps, Project Description, Packaging Settings — am ersten Tag setzen.
  • Git + LFS + .gitignore, auch solo.
  • Player Character orchestriert; enthält nicht.

Das ist das Fundament. Alles was du darauf baust profitiert von diesen Entscheidungen. Alles was du ohne sie baust refactorst du irgendwann.

Nächste Woche: 10 Blueprint-Fehler die jeder Anfänger trifft — und wie du sie fixt. Sobald dein Projekt steht ist das Erste was du tust ein paar Nodes verkabeln. Das Zweite was du tust ist kryptische Fehlermeldungen kriegen. Nächsten Sonntag entschlüsselt.

— Marco