Datamanagement #

This documentation explains how we manage data at Games by Hyper and why we use specific data structures for different purposes.

Data Management Methods We Use:

• Data Tables: For collections of similar items (items, equipment, quests, etc.)
• Data Assets: For unique, standalone configurations (weather types, game modes, etc.)
• Structures (Structs): For organizing related data into reusable containers

Understanding when to use each method will help you work effectively with our systems and extend them for your own needs.

Official Documentation:

For complete technical details, see Epic Games' official documentation:

Data-Driven Gameplay Elements in Unreal Engine

Data management philosophy #

Why Data-Driven Design? #

Data-driven design separates game logic from game content, allowing designers to modify content without touching code.

From Epic Games' documentation:

“Data Driven Gameplay helps mitigate the amount of work and complexity involved for games that have an extended lifetime. You can move data to Microsoft Excel or other spreadsheet documents that can be maintained and then imported to automatically take effect in the game.”

Key Benefits:

• Designer Independence: Non-programmers can add/modify content
• Rapid Iteration: Change values without recompiling code
• Easy Balancing: Adjust numbers and see results immediately
• Scalability: Add hundreds of items, quests, or enemies without code changes
• External Editing: Use Excel, Google Sheets, or other tools to manage data
• Version Control Friendly: Data files are easier to merge than code

Without Data-Driven Design:

1. Programmer creates new item class in C++
2. Compile code
3. Create blueprint from class
4. Configure properties
5. Test in game
6. Repeat for each item

With Data-Driven Design (Data Tables):

1. Open DT_Items in Excel or Unreal Editor
2. Add new row with item properties
3. Save
4. Test in game immediately
5. Can add 100 items in same time as 1 code-based item

This is why all our systems use data-driven approaches.

Our Approach at Games by Hyper #

We use a combination of data structures based on what the data represents:

Data Tables → Collections of similar items

• Items (DT_Items)
• Equipment (DT_Equipment)
• Crafting recipes
• Quest definitions
• State effects (DT_StateEffects)

Data Assets → Unique, standalone configurations

• Weather types (Sunny, Rainy, Snowy, etc.)
• Game mode settings
• Difficulty presets
• Audio mixing presets

Structures → Reusable data containers

• Item structure (shared by inventory, equipment, etc.)
• Attribute structure (health, stamina, etc.)
• Reward structure (quest rewards, loot drops)

This approach gives us:

• ✅ Flexibility to add content rapidly
• ✅ Clear organization of data
• ✅ Designer-friendly workflows
• ✅ Performance optimization
• ✅ Easy to understand and maintain

---

Abstract Classes #

In our systems we use abstract classes:

We also have a tutorial in our Udemy course within our fundamentals class on how it works in detail.

Here is the “abstract” version (haha:P):

Abstract Classes declare functions that are being used in child classes.

The abstract aims to include the minimum that should be ably exposed so other external classes can interact with it.

The abstract also declares variables that are used in all other modules.

By means of structural inheritance, we are able to swap child components of this abstract on any actor without messing up the references.

If you swap one of the child components for another child component, calling functions will stay the same due to the structural inheritance of the abstract. You will keep calling the functions externally on the abstract. Due to dynamic dispatching, it will determine on which child it will execute the actual logic. That would be the one that you have assigned: e.g. the advanced or basic component.

By using this method, I am making sure to couple the components as loosely as I am able to. This will benefit nearly all potential non-functional requirements of your project (ISO25010) like modularity, compatibility, useability, maintainability, and portability.

In most of my systems, I have made two children of the abstract: Advanced and Basic

Basic/Example:
The basic version is not intended to be game-ready. It is intended to show how other systems are able to interact with each other and give you guidance on how to do so.

As an example:

In the tree-cutting system, some would want to know how to pick up a log, connect it to a combat component to apply damage to the tree, make the hatchet swappable, and put a log in an inventory.

To show you how, I have included all of these examples by connecting them to a basic version of the inventory, equipment, interaction, and combat component.

The “Basic” component is swappable with the “advanced” component of my other modular systems and it will nearly always work well. Sometimes you will need to change settings and code which I purged for the sake of folder clutter.

If you do not want to use my other modular assets, it is no problem. You can remove it and use the basic integrations as an example of how to integrate into your own.

Advanced:
The advanced can be a child of the basic or a direct child of the abstract. That depends on if the functionality of the basic will exactly be the same in the advanced. It does implement extra functions besides the basic component. It can optionally override an existing function of the basic to give a certain addition to the basic function.

The advanced components are intended to be preferably used above the basic components and should be able to swap easily.

---

Data tables #

What Are Data Tables? #

Data Tables are spreadsheet-like collections of structured data where each row represents an entry and each column represents a property.

From Epic Games' documentation:

“Data Tables are a table of miscellaneous but related data grouped in a meaningful and useful way, where the data fields can be any valid UObject property, including asset references.”

Structure:

Data Table: DT_Items

| Name (Row) | Display Name | Item Type | Weight | Value | Icon |

|————-|—————–|———–|——–|——-|—————|

| Sword_Iron | Iron Sword | Weapon | 5.0 | 100 | Icon_Sword |
| Potion_HP | Health Potion | Consumable| 0.5 | 50 | Icon_Potion |
| Gold_Coin | Gold Coin | Currency | 0.01 | 1 | Icon_Gold |

Each row is accessed by its Name (Row Name), making lookups fast and easy.

Key Characteristics:

• Tabular format: Rows and columns like a spreadsheet
• Structure-based: Each row must follow the same structure definition
• Row Names: Each row has a unique name for lookup
• Multiple entries: Designed for many similar items
• Excel-compatible: Can import/export CSV files

When to Use Data Tables #

Use Data Tables when you have many similar items that share the same properties but with different values.

Ideal Use Cases:

• Items/Inventory:
• Hundreds of items (weapons, armor, consumables, materials)
• All items share same properties (name, type, weight, value, icon)
• Need to view/edit many items at once
• Designers frequently add new items
• Equipment:
• Different equipment pieces (swords, bows, armor)
• Shared properties (damage, durability, requirements)
• Easy to balance stats across all equipment
• Quests:
• Multiple quests with similar structure
• Quest ID, name, description, objectives, rewards
• View all quests in one table for balancing
• Character Stats/Levels:
• Level progression tables
• XP requirements per level
• Stat bonuses per level
• Crafting Recipes:
• Many recipes with ingredients and results
• Easy to see all recipes at a glance
• State Effects:
• DT_StateEffects (Low Health, Starving, Diseased)
• Trigger conditions and effects for each state

When NOT to Use Data Tables:

• ❌ Single, unique configurations (use Data Assets instead)
• ❌ Complex hierarchical data (use nested structures or Data Assets)
• ❌ Data that doesn't fit a tabular format

Benefits of Data Tables #

Spreadsheet-Like View:

The biggest advantage is seeing many items at once:

Data Table Editor shows:

• All 500 items in one scrollable view
• Sort by any column (damage, weight, value)
• Filter to find specific items
• Compare items side-by-side
• Spot inconsistencies easily

Mass Editing:

Balancing Example:

• Select all “Iron” weapons
• Increase damage by 10%
• See immediate effect across all iron weapons
• Much faster than editing individual assets

Excel Integration:

Workflow:

1. Export data table to CSV
2. Open in Excel or Google Sheets
3. Use spreadsheet tools (formulas, sorting, filtering)
4. Make bulk changes
5. Re-import CSV
6. All changes applied automatically

Fast Lookups:

Blueprint/Code:

Get Data Table Row by Name(“Sword_Iron”)

→ Returns entire row structure instantly

→ No searching through arrays

→ Optimized for frequent access

Designer-Friendly:

• Visual table interface
• No blueprint knowledge required
• Easy to add/remove rows
• Clear column headers explain each property
• Tooltips provide additional context

Version Control:

• Text-based storage (easy to diff)
• Can see exactly what changed
• Merge-friendly for team collaboration

Our Usage – Items and Equipment #

DT_Items (Item Data Table):

We use a Data Table for items because:

• We have many items (hundreds potentially)
• All items share the same structure (Item ID, Name, Type, Weight, Value, Icon, etc.)
• Designers need to view all items at once for balancing
• Easy to add new items (just add a new row)
• Can compare items side-by-side (all swords, all potions, etc.)
• Excel export allows bulk balancing and modification

Structure:

DT_Items Structure:

• Row Name: Unique Item ID
• Display Name: Name shown to player
• Description: Item description
• Item Type: Weapon, Armor, Consumable, Material, etc.
• Icon: Item icon texture
• Mesh: 3D mesh for world display
• Weight: Item weight (for inventory capacity)
• Max Stack Size: How many can stack in one slot
• Value: Gold value
• Assigned Attributes: Attributes applied when added to inventory
• … (additional properties per item type)

DT_Equipment (Equipment Data Table):

Similar reasoning:

• Many equipment pieces (swords, bows, armor, shields)
• All equipment shares similar properties (damage, durability, requirements)
• Designers balance stats by viewing all equipment together
• Easy to see progression (Iron Sword → Steel Sword → Mithril Sword)
• Cross-reference with DT_Items (each equipment entry references an item)

Structure:

DT_Equipment Structure:

• Row Name: Unique Equipment ID
• Item Reference: Reference to DT_Items entry
• Equipment Type: Melee, Ranged, Armor, etc.
• Damage/Defense: Primary stats
• Durability: Max durability
• Equip Animations: Animation montages for equip/unequip
• Assigned Attributes: Attributes applied when equipped
• Gender Restrictions: Male/Female specific equipment
• … (additional properties per equipment type)

• ✅ Inventory system reads from DT_Items → instant access to all item data
• ✅ Equipment manager reads from DT_Equipment → all equipment stats available
• ✅ Quest system references DT_Items for rewards → easy to specify quest rewards
• ✅ Crafting system uses DT_Items for recipes → clear ingredient/result relationships
• ✅ Designers can add 50 items in 10 minutes without programmer help

See Inventory documentation and Equipment Manager documentation for full details on these data tables.

---

Data assets #

What Are Data Assets? #

Data Assets are individual, self-contained configuration files. Each Data Asset is a unique instance with its own properties.

Structure:

Unlike Data Tables (many rows in one file), Data Assets are individual files:

Data Asset Approach:

Content/Data/Weather/DA_Sunny (individual file)

• Weather Name: “Sunny”
• Sky Color: Bright Blue
• Cloud Coverage: 10%
• Precipitation: None
• Temperature: 25°C

Content/Data/Weather/DA_Rainy (individual file)

- Weather Name: "Rainy"

• Sky Color: Dark Gray
• Cloud Coverage: 90%
• Precipitation: Rain
• Temperature: 15°C

Content/Data/Weather/DA_Snowy (individual file)

• Weather Name: “Snowy”
• Sky Color: White/Gray
• Cloud Coverage: 80%
• Precipitation: Snow
• Temperature: -5°C

Each weather type is its own asset file with unique configuration.

Key Characteristics:

• Individual files: Each asset is a separate file
• Unique configurations: Not rows in a table
• Direct references: Can be referenced directly in blueprints
• Class-based: Each asset is an instance of a defined class
• Rich editing: Full Details panel available for each asset

When to Use Data Assets #

Use Data Assets when you have distinct, unique configurations that don't fit well in a table format.

Ideal Use Cases:

• Weather Types:
• Each weather is unique (Sunny, Rainy, Snowy, Foggy)
• Complex nested properties (skybox settings, particle systems, audio)
• Not a huge number of variations (maybe 5-10 weather types)
• Each weather drastically different from others
• Game Mode Configurations:
• Deathmatch mode settings
• Capture the Flag settings
• Battle Royale settings
• Each has unique rules and properties
• Difficulty Presets:
• Easy (damage multipliers, AI settings, resource amounts)
• Normal
• Hard
• Nightmare
• Each preset is a complete configuration
• Character Classes:
• Warrior (starting stats, abilities, equipment)
• Mage
• Rogue
• Each class is fundamentally different
• Audio Mix Presets:
• Indoor acoustics
• Outdoor acoustics
• Combat mix
• Stealth mix

When NOT to Use Data Assets:

• ❌ Many similar items that fit in a table (use Data Tables)
• ❌ Simple value lookups (use Data Tables or Enums)
• ❌ Need to view/compare many items at once (Data Tables better)

Benefits of Data Assets #

Individual Asset Editing:

Editing DA_Snowy weather:

• Full Details panel
• Visual preview of properties
• Nested structures expanded
• Can reference other assets (materials, sounds, particles)
• Changes auto-save to this specific asset

Direct Blueprint References:

Blueprint:

Variable: Current Weather (Data Asset reference)

• Set to DA_Sunny by default
• Can drag-and-drop DA_Rainy, DA_Snowy, etc.
• No row name lookup needed
• Type-safe reference

Complex Nested Data:

Data Asset can contain:

• Structures
• Arrays of structures
• References to other assets (materials, textures, sounds)
• Complex hierarchies
• Blueprint-defined logic

Data Table rows are flatter, less hierarchical.

Asset Browser Integration:

Content Browser:

• See all weather assets at a glance
• Thumbnails show preview
• Right-click to duplicate
• Create variations easily

Inheritance:

Base Weather Data Asset Class

↓

DA_Sunny (inherits base class)

DA_Rainy (inherits base class)

DA_Snowy (inherits base class)

Can add custom variables per asset

Or override base class behavior

No Row Name Management:

Data Table: Must manage unique row names

Data Asset: File name is the identifier

• Rename file = rename asset (automatic)
• No duplicate row name errors
• More intuitive

Our Usage – Weather System #

Weather System Data Assets:

We use Data Assets for weather types because:

• Each weather type is fundamentally unique (Sunny vs Rainy vs Snowy)
• Complex configuration per weather (sky settings, particles, audio, post-process)
• Only a small number of weather types (5-10, not hundreds)
• Each weather is its own complete configuration
• Not tabular data – doesn't make sense as rows in a table
• Visual editing – easier to configure in full Details panel

Data Asset Structure:

DA_Sunny (Data Asset):

• Weather Name: “Sunny”
• Sky Settings:

 - Sun Brightness: 10.0
 - Sky Color: RGB(135, 206, 250)
 - Cloud Texture: T_Clouds_Sparse
 - Cloud Coverage: 10%

• Lighting:

 - Directional Light Intensity: 8.0
 - Light Color: Warm Yellow
 - Shadow Intensity: 0.6

• Particle Systems:

 - Precipitation: None
 - Ambient Particles: Dust motes, lens flare

• Audio:

 - Ambient Sound: Birds chirping, gentle wind
 - Weather Sound: None

• Post-Process:

 - Exposure: Bright
 - Color Grading: Warm tones

• Gameplay Effects:

 - Visibility Range: Maximum
 - Movement Speed Modifier: 100%
 - Temperature: 25°C

DA_Rainy (Data Asset):

• Weather Name: “Rainy”
• Sky Settings:

 - Sun Brightness: 2.0
 - Sky Color: RGB(100, 100, 120)
 - Cloud Texture: T_Clouds_Storm
 - Cloud Coverage: 95%

• Lighting:

 - Directional Light Intensity: 3.0
 - Light Color: Cool Gray
 - Shadow Intensity: 0.3

• Particle Systems:

 - Precipitation: Rain particle system
 - Ambient Particles: Splashes, drips

• Audio:

 - Ambient Sound: Thunder, wind
 - Weather Sound: Rain on surfaces

• Post-Process:

 - Exposure: Dark
 - Color Grading: Desaturated, cool

• Gameplay Effects:

 - Visibility Range: Reduced 50%
 - Movement Speed Modifier: 90% (slippery)
 - Temperature: 12°C

DA_Snowy (Data Asset):

• (Similar complex configuration for snowy weather)

Why Not a Data Table?

If we used a Data Table for weather:

DT_Weather (Data Table – Bad Approach):

| Row Name | Name | SunBright | SkyColorR | SkyColorG | SkyColorB | CloudTex | CloudCov | ... |

|———-|——–|———–|———–|———–|———–|———-|———-|—–|

| Sunny | Sunny | 10.0 | 135 | 206 | 250 | T_Cloud | 10 | ... |
| Rainy | Rainy | 2.0 | 100 | 100 | 120 | T_Storm | 95 | ... |

Problems:

• ❌ Very wide table (dozens of columns)
• ❌ Hard to see relationships between properties
• ❌ Can't nest structures well
• ❌ Difficult to reference other assets (particles, sounds)
• ❌ Poor editing experience
• ❌ Only 5-10 weather types, no benefit from table view

Data Asset Advantages for Weather:

• ✅ Each weather file is self-contained and easy to understand
• ✅ Rich nested properties (Sky Settings, Lighting, Particles, Audio)
• ✅ Can reference complex assets (particle systems, sound cues, materials)
• ✅ Easy to create variations (duplicate DA_Sunny → DA_Sunny_Evening)
• ✅ Blueprint can switch weather: Set Current Weather = DA_Rainy
• ✅ Designer-friendly editing with full Details panel
• ✅ Can preview each weather asset individually

This is why Data Assets are perfect for weather and similar unique configuration systems.

5 STRUCTURES (STRUCTS)

---

What Are Structures? #

Structures (Structs) are custom data containers that group related properties together. They're like blueprints for data organization.

Definition:

Structure: F_ItemData

Properties:

• Item ID (String)
• Display Name (String)
• Description (Text)
• Item Type (Enum)
• Icon (Texture Reference)
• Mesh (Static Mesh Reference)
• Weight (Float)
• Value (Integer)
• Max Stack Size (Integer)

This structure can then be used in:

• Data Table rows (each row is an F_ItemData structure)
• Data Assets (contain F_ItemData structures)
• Blueprint variables
• Arrays
• Function parameters

Key Characteristics:

• Reusable: Define once, use everywhere
• Type-safe: Guarantees data consistency
• Composable: Structures can contain other structures
• Blueprint-accessible: Can be used in blueprints
• Networked: Automatically replicates if marked for replication

When to Use Structures #

Use Structures when you need to group related data that will be used in multiple places.

Ideal Use Cases:

• Data Table Row Definitions:

Structure: F_ItemData

Used in: DT_Items (each row is F_ItemData)

• Ensures all rows have same properties
• Can reuse structure in code/blueprints
• Type-safe lookups
• Function Parameters:

Function: Add Item to Inventory

Parameter: Item Data (F_ItemData structure)

• Pass entire item as single parameter
• Cleaner than dozens of individual parameters
• Easier to extend (add properties to structure)
• Arrays of Related Data:

Variable: Quest Rewards (Array of F_RewardData structures)

Each reward contains:

• Reward Type (Item, Gold, XP)
• Reward ID
• Quantity
• Optional fields
• Nested Data in Data Assets:

Data Asset: DA_Rainy (Weather)

Contains:

• Sky Settings (F_SkySettings structure)
• Lighting Settings (F_LightingSettings structure)
• Particle Settings (F_ParticleSettings structure)
• Shared Data Definitions:

Structure: F_AttributeData

Used by:

• Attribute Manager component
• Save game system
• UI widgets
• Replication
• Item effects

One definition, many users.

How We Use Structures #

Item Structure:

F_ItemData (Structure):

Used in:

1. DT_Items – Each row is F_ItemData
2. Inventory Component – Stores array of F_ItemData
3. Equipment Manager – References F_ItemData
4. Crafting System – Recipe inputs/outputs are F_ItemData
5. Quest System – Quest rewards are F_ItemData
6. Vendor System – Items for sale are F_ItemData

• Single source of truth for item data format
• Change structure, all systems update
• Type-safe across all systems

Attribute Structure:

F_AttributeData (Structure):

Properties:

• Attribute Tag (Gameplay Tag)
• Current Value (Float)
• Max Value (Float)
• Regen Rate (Float)

Used in:

• Attribute Manager arrays
• Character stat displays
• Save/load system
• Buff/debuff calculations

Reward Structure:

F_RewardData (Structure):

Properties:

• Reward Type (Enum: Item, Gold, XP, Reputation)
• Item ID (String, optional)
• Amount (Integer)
• Gameplay Tag (optional, for tagged rewards)

Used in:

• Quest rewards (DT_Quests)
• Achievement rewards
• Loot drop tables
• Event rewards

Nested Structures:

Data Table: DT_Quests

F_QuestData (Structure):

• Quest ID (String)
• Quest Name (String)
• Description (Text)
• Objectives (Array of F_QuestObjective structures)

 - Objective Type
 - Target
 - Required Amount

• Rewards (Array of F_RewardData structures)

 - Reward 1: F_RewardData
 - Reward 2: F_RewardData

• Prerequisites (F_QuestPrerequisites structure)

 - Required Level
 - Required Quests
 - Required Items

This creates clean, organized, hierarchical data.

6 COMPARISON: DATA TABLES VS DATA ASSETS VS STRUCTS

Quick Reference Guide #

| Feature | Data Tables | Data Assets | Structures |

|———|————-|————-|————|

| **Purpose** | Collections of similar items | Unique configurations | Data organization/containers |

| **Format** | Rows and columns (spreadsheet) | Individual asset files | Property definitions |

| **Quantity** | Many items (hundreds) | Few items (5-20) | Reusable definitions |

| **Editing** | Table editor, Excel | Details panel per asset | Structure editor |

| **Use Case** | Items, equipment, quests | Weather types, game modes | Data definitions, function params |

| **View Multiple** | Yes (all rows visible) | No (one asset at a time) | N/A (not data storage) |

| **Excel Export** | Yes | No | No |

| **Nested Data** | Limited | Excellent | Designed for nesting |

| **Blueprint Use** | Row lookup by name | Direct reference | Variable types, parameters |

| **Our Examples** | DT_Items, DT_Equipment, DT_StateEffects | DA_Sunny, DA_Rainy, DA_Snowy | F_ItemData, F_AttributeData, F_RewardData |

Decision Matrix #

Choose Data Tables When:

• ✅ You have many similar items (50+)
• ✅ Need to view/compare multiple entries at once
• ✅ Properties are relatively flat (not deeply nested)
• ✅ Want Excel integration for bulk editing
• ✅ Designers will frequently add new entries
• ✅ Examples: Items, equipment, enemies, quests, crafting recipes

Choose Data Assets When:

• ✅ You have few unique configurations (5-20)
• ✅ Each entry is fundamentally different
• ✅ Need complex nested properties
• ✅ Want direct blueprint references
• ✅ Properties include asset references (materials, sounds, particles)
• ✅ Each configuration is self-contained
• ✅ Examples: Weather types, game modes, difficulty settings, character classes

Choose Structures When:

• ✅ Need to define data format for other systems
• ✅ Want reusable data containers
• ✅ Creating Data Table row types
• ✅ Organizing function parameters
• ✅ Creating nested data within Data Assets
• ✅ Need type safety across multiple systems
• ✅ Examples: Item data, attribute data, quest objectives, rewards

Can Combine:

Common Pattern:

1. Define Structure: F_ItemData

 - Defines what properties an item has

1. Create Data Table: DT_Items (uses F_ItemData)

 - Stores hundreds of items
 - Each row is F_ItemData structure

1. Use in Blueprints:

 - Get row from DT_Items → Returns F_ItemData
 - Pass F_ItemData to functions
 - Store F_ItemData in arrays

This combines all three for maximum flexibility.

---

Best practices #

Data Organization #

Folder Structure:

Content/

├── Data/
│ ├── Items/
│ │ ├── DT_Items (Data Table)
│ │ ├── DT_Equipment (Data Table)
│ │ └── DT_Crafting (Data Table)
│ ├── Quests/
│ │ └── DT_Quests (Data Table)
│ ├── Weather/
│ │ ├── DA_Sunny (Data Asset)
│ │ ├── DA_Rainy (Data Asset)
│ │ └── DA_Snowy (Data Asset)
│ └── Structures/
│ ├── F_ItemData
│ ├── F_QuestData
│ └── F_AttributeData

Keep Related Data Together:

• All item-related tables in Items folder
• All quest-related data in Quests folder
• Weather Data Assets grouped together

Separate by System:

• Inventory system data separate from Equipment system data
• Even if they reference each other

Naming Conventions #

Data Tables:

Prefix: DT_

• DT_Items
• DT_Equipment
• DT_Quests
• DT_StateEffects
• DT_Crafting

Data Assets:

Prefix: DA_

• DA_Sunny
• DA_Rainy
• DA_Deathmatch
• DA_HardDifficulty

Structures:

Prefix: F_

• F_ItemData
• F_QuestData
• F_AttributeData
• F_RewardData

Be Descriptive:

GOOD: DT_Items, F_ItemData, DA_SunnyWeather

BAD: Items, Data, Sunny

Performance Considerations #

Data Table Lookups:

FAST:

• Get Data Table Row (by name)
• Indexed lookup, very fast
• O(1) time complexity

SLOW:

• Iterate all rows to find specific property
• Linear search
• O(n) time complexity

Best Practice:

• Design row names for easy lookup
• Cache frequently accessed rows

Data Asset Loading:

Data Assets:

• Loaded when referenced
• Can use lazy loading (TSoftObjectPtr)
• Large assets (with many sub-assets) can take time

Best Practice:

• Preload critical Data Assets at level start
• Use async loading for non-critical assets
• Don't reference hundreds of Data Assets simultaneously

Structure Size:

Structures:

• Lightweight, fast to copy
• Avoid massive structures (hundreds of properties)
• Break into smaller, logical structures

Best Practice:

• Keep structures focused and minimal
• Use nested structures for organization
• Don't add unnecessary properties

Excel Integration:

Data Tables:

• Export to CSV for bulk editing
• Make changes in Excel
• Re-import CSV

Best Practice:

• Always backup before re-importing
• Use version control
• Test re-import on copy first
• —

END OF DOCUMENTATION

• Epic Games: Data-Driven Gameplay Elements (Official Documentation)
• Inventory Documentation (DT_Items usage)
• Equipment Manager Documentation (DT_Equipment usage)
• Attribute Manager Documentation (structures and data tables)

Summary:

At Games by Hyper, we use data-driven design extensively:

• Data Tables: For collections (items, equipment, quests) – easy to view and edit many similar entries
• Data Assets: For unique configurations (weather types, game modes) – complex nested properties
• Structures: For data organization (item data, attributes, rewards) – reusable containers

Understanding when to use each approach will help you work effectively with our systems and build your own data-driven content.