The Hyper folder structure keeps shared core definitions, individual systems, templates, UI, and resource assets separated so systems can reference each other without duplicating data or creating brittle dependencies.

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 folder ownership, naming, and extension guidance.

Top-Level Layout

Content/
└── Hyper/
    ├── Core/
    ├── Templates/
    ├── [SystemName]/
    ├── UI/
    └── ResourcePack/

Why Core Exists

Core prevents duplicate definitions. If Inventory, Equipment, Crafting, and Quest systems all need item data, they should reference the same shared structure instead of each system shipping its own copy.

Bad structure:

Hyper/InventorySystem/
└── F_ItemData
Hyper/EquipmentSystem/
└── F_ItemData
Hyper/QuestSystem/
└── F_ItemData

This creates multiple definitions of the same concept and makes integrations harder to maintain.

Good structure:

Hyper/Core/InventorySystem/Structures/
└── Struct_ItemData

Hyper/InventorySystem/
└── references Core/InventorySystem/Struct_ItemData
Hyper/EquipmentSystem/
└── references Core/InventorySystem/Struct_ItemData
Hyper/QuestSystem/
└── references Core/InventorySystem/Struct_ItemData

The shared structure stays in one place, and every system references the same source of truth.

Core Subfolders

Each system can have a matching Core folder when it exposes definitions that other systems need.

Hyper/Core/InventorySystem/
├── Enums/
├── Structures/
├── Interfaces/
└── AbstractClasses/

System Folders

System folders hold the actual implementation assets for one module. Keep assets here when they belong to that system and are not shared core definitions.

Hyper/[SystemName]/
├── Blueprints/
├── Components/
├── Data/
├── Maps/
├── UI/
└── Examples/

Example: Inventory System

• AC_InventoryComponent
• DT_Items
• UI_InventoryMenu
• UI_ItemSlot
• BP_DroppedItem

Example: Quest System

• AC_QuestComponent
• Struct_QuestData
• E_Quest_Status
• DT_Quests
• UI_QuestJournal
• BP_QuestGiver

Template Folders

Templates combine systems into a genre-specific or bundle-specific project foundation. Template folders should contain template-specific setup and examples, not duplicate core definitions.

Hyper/Templates/[TemplateName]/
├── Template-specific maps
├── Template-specific game mode setup
├── Pre-configured example data
└── Integration examples

When you buy a template, you usually receive Core, the included system folders, template-specific files, UI, and ResourcePack content together.

UI Folder

The Hyper/UI folder contains reusable widgets and system-specific UI. Shared widgets should stay generic; system-specific screens should be grouped by system.

Hyper/UI/
├── Widgets/        (generic reusable elements)
├── MainWidgets/    (main menus / major screens)
├── Inventory/      (inventory-specific UI)
└── Quest/          (quest-specific UI)

Generic widgets are things like confirm dialogs, reusable item slots, prompts, and shared menu elements. They are useful when several systems need the same interaction pattern.

System-specific widgets belong in their system folder under UI when they are only meaningful for that system, such as inventory menus or quest journal entries.

Resource Pack

ResourcePack contains shared placeholder and support assets used by multiple systems.

• Icons
• UI textures
• Placeholder meshes
• Particles and Niagara effects
• Sounds
• Materials

Some systems include more resources than others. Do not treat ResourcePack as final game art; use it as example/support content unless a specific asset is intended to ship in your project.

Naming Conventions

Finding Assets Quickly

Use Content Browser search instead of manually opening every folder. Prefixes make search predictable.

• UI_Inv shows inventory UI widgets.
• Struct_ shows structures.
• AC_ shows actor components and abstract classes.
• Enum_Item shows item enums.
• DT_Items opens the item data table.

Add frequently used folders to Content Browser Favorites when working on one system heavily.

Where to Put Your Own Content

Keep project-specific content outside the Hyper folder whenever possible. This makes updates safer and makes it easier to see which assets belong to your project.

Recommended:

Content/MyProject/
├── Blueprints/
├── UI/
├── Data/
├── Maps/
└── Art/

Avoid:

Content/Hyper/MyCustomGameplay/
Content/Hyper/InventorySystem/MyEditedInventory/
Content/Hyper/UI/MyCustomMenu/

You can modify Hyper files directly, but updates may overwrite those changes. Direct edits are only practical when you do not plan to update or when you are prepared to re-apply changes after every update.

Safe Extension Pattern

The safest way to customize a Hyper system is to create child Blueprints or duplicate UI into your own project folder.

1. Create a child Blueprint or child widget from the Hyper asset.
2. Save it under your own project folder, for example Content/MyProject/Blueprints/.
3. Override only what your project needs.
4. Reference your child asset from your own project setup.

This keeps the original Hyper asset intact, reduces update conflicts, and makes your project-specific changes easier to track.

Version Control Guidance

• Commit Hyper content when you first add systems.
• Commit Hyper content again when you update systems.
• Keep your own project content in separate commits where practical.
• Before updating Hyper systems, commit or back up any local changes you made to Hyper files.
• Keep UI customizations separate by using child widgets or project-owned copies.

Summary

The folder structure is designed around ownership. Core contains shared definitions, system folders contain implementation, Templates contain genre or bundle setup, UI contains shared and system-specific widgets, and ResourcePack contains reusable support assets.

For project work, keep your own content outside Content/Hyper and extend Hyper assets through child Blueprints or project-owned UI copies whenever possible.