Du hast 200 Items, jedes mit Name, Icon, Preis und Gewicht. Wo leben die? Unreal gibt dir drei Antworten — DataTable, DataAsset, Primary DataAsset — und Anfänger nehmen meist die erste, die sie in einem Tutorial gesehen haben. Wähl falsch, und du merkst es um Item 150 herum, wenn die Struktur, die du gewählt hast, gegen alles kämpft, was du brauchst. Treffen wir die Wahl gleich richtig.

Die drei Container, je in einer Zeile

  • DataTable — eine Tabelle. Viele Rows, alle dasselbe Struct. Import aus CSV/JSON.
  • DataAsset — eine einzelne Custom-Asset-Instanz. Eine reiche, flexible Struktur. Eines pro Ding, oder ein Config-Blob.
  • Primary DataAsset — ein DataAsset, das der Asset Manager zur Laufzeit per ID finden und asynchron laden kann.

DataTable: viele Rows, eine Form

Ein DataTable hält Rows, die alle ein einziges Struct teilen — ideal für "200 Items, jedes mit denselben Feldern". Du bearbeitest es wie eine Tabelle, oder importierst eine CSV/JSON (Thema letzte Woche). Schlag eine Row per Namen nach und du hast deine Daten.

Der Haken: ein DataTable ist ein Asset, komplett geladen. Jede Row lädt zusammen. Und wenn eine Row eine Hard-Reference auf ein schweres Mesh hält, zieht das Laden der Tabelle jedes Mesh auf einmal rein. (Ja — das ist die Soft-Reference-Falle mit anderem Hut. Speicher Soft-References in deinen Rows.)

Am besten wenn: viele Einträge, identische Form, in Masse bearbeitet, und ok, alle zusammen im Speicher zu haben.

DataAsset: ein reiches Ding

Ein DataAsset ist ein einzelnes Asset, das du mit einer Custom-Struktur füllst — verschachtelte Daten, Arrays, Soft-References, was auch immer deine Klasse deklariert. Statt 200 Rows in einer Datei machst du vielleicht 200 separate Assets, oder eine Handvoll Config-Assets (eins für die Audio-Settings, eins für die Schwierigkeitskurve).

Weil jedes sein eigenes Asset ist, kannst du sie einzeln soft-referenzieren und laden — die Daten dieser einen Waffe reinziehen, ohne die anderen 199 anzufassen. Das ist der strukturelle Unterschied zum DataTable, der am meisten zählt.

Am besten wenn: Einträge eine reiche oder variierende Form haben, oder du sie einzeln laden willst.

Primary DataAsset: ein DataAsset, das skaliert

Ein PrimaryDataAsset ist ein DataAsset, verdrahtet mit dem Asset Manager. Du gibst ihm einen Typ und eine ID, und jetzt kann die Engine "alle Waffen" aufzählen, sie asynchron per ID laden und aus dem Speicher halten, bis etwas fragt. Das ist, was Lyra und die meisten größeren Projekte für Content-Kataloge nutzen.

Die Kosten: du konfigurierst den Asset Manager (Project Settings → Asset Manager) und fängst an, in Primary-Asset-IDs zu denken. Mehr Setup — aber es ist die einzige Option hier, die wirklich für hunderte einzeln gestreamte Assets gebaut ist.

Am besten wenn: ein großer, wachsender Katalog, den du auffindbar und async-ladbar willst — jede Waffe, jeder Charakter, jedes Level im Spiel.

Eine schnelle Entscheidung

  • Viele identische Einträge, wie eine Tabelle bearbeiten, ok zusammen zu laden → DataTable.
  • Reiche oder einmalige Config, einzeln laden → DataAsset.
  • Großer Katalog, per ID auffinden und async laden → Primary DataAsset.

Wenn du zwischen den letzten beiden hin- und hergerissen bist, fang mit DataAsset an — das spätere Hochstufen zu PrimaryDataAsset ist billig. Der andere Weg, oder das Migrieren weg von einem DataTable, das aus seinem einzelnen Struct rausgewachsen ist, ist der schmerzhafte Rewrite.


Plugin tip
Den Container wählen ist die halbe Arbeit — ihn aus echten Daten füllen die andere. Ein Designer gibt dir eine CSV, eine API liefert JSON, und du brauchst es zur Laufzeit in einem DataTable, nicht per Editor-Reimport. FoxData überbrückt diese Lücke: CSV/JSON in DataTable-förmige Daten zur Laufzeit, als Blueprint-Nodes. Optional, aber es ist das, was aus einer "statischen Tabelle" lebende, designer-editierbare Daten macht.

Typische Fehler

  • Hard-References in einem DataTable. Die Tabelle laden lädt jedes referenzierte Asset. Nutz Soft-References in Rows.
  • DataTable für unpassende Formen. Wenn Einträge wirklich verschiedene Felder brauchen, kämpfst du ewig gegen das Single-Struct-Limit. Das ist DataAsset-Gebiet.
  • Eine Asset-Registry selbst bauen. Wenn du dein eigenes "finde alle X per Tag"-System baust, erfindest du den Asset Manager neu — nimm stattdessen PrimaryDataAsset.
  • Ein Struct bearbeiten, nachdem du Rows hast. Das Row-Struct zu ändern kann bestehende DataTable-Daten leeren. Entscheide die Form früh; mach ein Backup vor großen Änderungen.
  • Asset-Manager-Setup vergessen. PrimaryDataAssets sind nicht auffindbar, bis du ihren Typ in den Project Settings registrierst.

Die 30-Sekunden-Zusammenfassung

  • DataTable — viele gleich-geformte Rows, ein Asset, komplett geladen. Tabellen-Daten.
  • DataAsset — ein reiches, Custom-Asset; lad es einzeln.
  • Primary DataAsset — DataAsset + Asset Manager: per ID auffinden und async laden, in großem Maßstab.
  • Halt Soft-References in deinen Rows, damit eine Tabelle nicht jedes Mesh reinzieht.
  • Unsicher zwischen DataAsset und PrimaryDataAsset? DataAsset jetzt, hochstufen, wenn du den Katalog brauchst.

Als Nächstes, wenn die Votes halten: Ein Dialog-System, das skaliert — von der if/else-Hölle zu einem datengetriebenen Setup mit Verzweigungen, Bedingungen und Lokalisierung.

— Marco