A spreadsheet of rows, each row the same struct, keyed by row name.
Large homogeneous datasets
Item lists, enemy stat tables, dialogue lines, loot tables
Imports from CSV or JSON, so designers can bulk-edit in a spreadsheet
Data Asset
A single authored object — an instance of a UDataAsset subclass — with its own properties and references to other assets.
A distinct configurable thing
A weapon definition, an ability, a character loadout
Supports inheritance and rich object references
Rule of thumb. Many rows of the same shape → Data Table. A distinct object, especially one referencing other assets or needing polymorphism → Data Asset.
Primary Data Assets also plug into the Asset Manager for controlled loading and streaming — Chapter 9 covers that machinery, including why UPrimaryDataAsset is the recommended base when bundles are involved.
2
A System Designers Can Extend Without Code
Define the data shape in C++ — a struct for a table row, or a Data Asset class, with well-organized and well-ranged properties (Chapter 3).
Drive behavior generically from that data. The system reads values and references rather than hardcoding logic per content item.
Designers add a row or a new Data Asset, fill in the values, and reference the mesh, montage, effects and tags. It works with no code change.
Use enums and tags to categorize, and soft references for assets so you control loading.
Concretely: to add an enemy, a designer duplicates a Data Asset, sets health, speed, AI type and abilities, and assigns a mesh. The spawner and the AI read the asset and behave accordingly. Nobody recompiles.
The soft-reference point matters here. A Data Asset that hard-references every mesh, montage and VFX in the game pulls all of it into memory the moment the asset loads. Chapter 7 covers why; Chapter 9 covers the loading tools.
3
Structs and Enums
Structs bundle related fields into a named, meaningful unit — FAbilityData holding cost, cooldown, damage and tags. Designers see grouped, labelled data instead of a scatter of loose variables.
Enums give designers a fixed, named set of choices — EEnemyType — instead of magic numbers or free text. They prevent invalid values, self-document intent, and drive clean switch logic. Marked BlueprintType, they appear as dropdowns.
Together they make data self-explanatory and constrained. A designer cannot enter a nonsensical value, and the intent is legible at a glance. Add clamp meta specifiers on the numeric fields and the surface becomes genuinely safe.
Interview drill
Answer each out loud before re-reading the chapter.
Data Tables versus Data Assets: when do you use each?
How would you structure a system so designers can add content without touching code?
How do you use structs and enums to make a system readable and safe for designers?