Hyper systems use Data Tables, Data Assets, and Structures for different kinds of gameplay data. Choosing the right format keeps systems editable, scalable, and easier to integrate.

For shared setup guidance, see the Migration Guide and Integration Guide. Use the System Atlas to look up functions, variables, events, components, and ownership references. Use this page for data-format decisions and project-specific data organization.

For Unreal Engine reference, see Data-Driven Gameplay Elements in Unreal Engine.

Related Resources

• Play

• Unreal Engine 5 Fundamentals course

Quick Decision Guide

Data-Driven Design

Data-driven design separates gameplay logic from gameplay content. Designers can add or balance items, equipment, quests, state effects, and other content without changing Blueprint or C++ logic.

Data-driven systems are useful because they support rapid iteration, external editing, version-control-friendly changes, and large content libraries.

Example: adding a new item

Abstract Classes

Many Hyper systems use abstract parent classes to keep integrations loosely coupled. External systems call the shared abstract interface, while the project can swap between Basic, Advanced, or custom child implementations.

• The abstract class declares the functions external systems should call.
• Shared variables and interfaces remain stable across modules.
• Child components can be swapped without changing every external reference.
• Dynamic dispatch routes the call to the assigned child implementation.

Basic/Example components are not intended to be final game-ready implementations. They show how systems can interact and provide integration examples. Advanced components are the preferred production-oriented implementations where available.

Data Tables

Data Tables are spreadsheet-like collections of rows. Each row follows the same structure, and each row name is used for lookup.

Example: DT_Items

Use Data Tables When

• You have many similar entries.
• All entries share the same structure.
• Designers need to view and compare many rows at once.
• CSV export/import or spreadsheet editing is useful.
• Rows need fast lookup by row name.

Hyper examples: DT_Items, DT_Equipment, DT_StateEffects, quest definitions, crafting recipes, and level progression tables.

Data Assets

Data Assets are individual asset files. They are better than tables when each entry is a unique configuration with nested data, asset references, or a richer Details panel editing experience.

Example weather assets:

• Content/Data/Weather/DA_Sunny: sunny sky, low cloud coverage, no precipitation, warm temperature.
• Content/Data/Weather/DA_Rainy: dark sky, high cloud coverage, rain, cooler temperature.
• Content/Data/Weather/DA_Snowy: snowy precipitation, cold temperature, winter visual setup.

Use Data Assets When

• You have a small number of unique configurations.
• Each entry has nested or complex data.
• The configuration references materials, sounds, particles, textures, or other assets.
• A direct Blueprint asset reference is better than a row-name lookup.
• Viewing one complete configuration at a time is clearer than a wide table.

Weather is a good Data Asset use case because each weather type is a complete configuration. A weather table would become very wide and harder to read because sky, lighting, particles, audio, post-process, and gameplay modifiers all need their own fields.

Structures

Structures define reusable data shapes. A structure does not store all content by itself; it defines what data belongs together so tables, assets, arrays, variables, replication, and function parameters can use the same format.

Example: F_ItemData

• Item ID
• Display Name
• Description
• Item Type
• Icon
• Mesh
• Weight
• Value
• Max Stack Size

Common Hyper structures:

• F_ItemData: used by inventory, equipment, crafting, quests, vendors, and item rewards.
• F_AttributeData: used by Attribute Manager arrays, UI, save/load, and buff/debuff calculations.
• F_RewardData: used by quest rewards, achievements, loot drops, and event rewards.

Combining the Three

The formats are often used together.

1. Define a structure such as F_ItemData.
2. Create a Data Table such as DT_Items using that structure as the row type.
3. Use row lookup to retrieve an F_ItemData value in Blueprint.
4. Pass that structure into inventory, equipment, crafting, quest, or vendor functions.

This keeps one data definition while allowing many systems to consume the same item format.

Comparison

Best Practices

• Use clear prefixes: DT_ for Data Tables, DA_ for Data Assets, and F_ for structures.
• Keep row names stable because systems often use them as identifiers.
• Keep structures focused. Split very large structures into nested structures where it improves readability.
• Use Data Tables for bulk editing and comparison.
• Use Data Assets for unique configurations with rich asset references.
• Back up or commit before CSV re-imports.
• Cache frequently used row data instead of repeatedly searching tables by non-row properties.

Summary

Use Data Tables for large collections of similar entries, Data Assets for unique configurations, and Structures for reusable data shapes. Hyper systems combine these patterns so content stays designer-editable while the Blueprint logic remains stable and reusable.