View Categories

Folder Structure

14 min read

Folder Structure #

This documentation explains how we organize our folder structure at Games by Hyper and why we use this specific organization.

Root Folder: Hyper/

Everything from Games by Hyper is contained within the Hyper folder, keeping our content separate from your project files.

Main Subfolders:

  • Core: Abstract classes, data models, enums, structures, shared systems
  • Templates: Complete template projects (Multiplayer Survival, etc.)
  • [Individual Systems]: Inventory, Equipment, Quests, etc. (each has own folder)
  • Resource Pack: Icons, meshes, Niagara effects, sounds, materials
  • UI: All user interface widgets and elements

Understanding this structure will help you:

  • ✅ Navigate our systems quickly
  • ✅ Understand how systems interconnect
  • ✅ Integrate multiple systems easily
  • ✅ Extend systems with your own content
  • ✅ Keep your project organized

All Games by Hyper content is organized under a single root folder:

Content/

└── Hyper/
 ├── Core/
 ├── Templates/
 ├── InventorySystem/
 ├── EquipmentSystem/
 ├── QuestSystem/
 ├── AttributeSystem/
 ├── CraftingSystem/
 ├── InteractionSystem/
 ├── [... other systems ...]
 ├── ResourcePack/
 └── UI/
Benefits of Single Root Folder:
  • ✅ Clear Separation: Our content vs. your content
  • ✅ Easy Migration: Move entire Hyper folder to new project
  • ✅ No Conflicts: Won't clash with your existing folders
  • ✅ Simple Updates: Replace Hyper folder to update systems
  • ✅ Professional Organization: Industry-standard approach

Why This Structure? #

Modular System Design:

When you purchase a system (e.g., Inventory System), you get:

  • The Inventory System folder (core inventory logic)
  • Related systems that work with it (Interaction, etc.)
  • References to abstract classes in Core folder
  • UI elements in UI folder
  • Resources in Resource Pack folder
Example – Buying Inventory System:

You receive:

├── Hyper/Core/ (abstract classes, data models)
├── Hyper/InventorySystem/ (inventory blueprints)
├── Hyper/InteractionSystem/ (works with inventory)
├── Hyper/UI/Inventory/ (inventory UI widgets)
└── Hyper/ResourcePack/ (icons, meshes for items)

This structure ensures:

  • ✅ Systems work together out of the box
  • ✅ No missing dependencies
  • ✅ Easy to add more systems later
  • ✅ Core functionality stays consistent across systems

Template Integration:

When you purchase a template (e.g., Multiplayer Survival Template), you get:

  • The template folder with template-specific content
  • All systems used in that template (each in own folder)
  • Core folder with shared abstract classes
  • UI folder with all interface elements
  • Resource Pack with all assets

All systems reference the same Core folder, keeping everything compatible.

Core folder #

Purpose #

The Core folder is the central communication hub for all Games by Hyper systems.

Location: Hyper/Core/

Key Concept:

The Core folder contains abstract classes, data models, and shared functionality that multiple systems reference.

This keeps the Hyper folder clean and organized while allowing systems to integrate seamlessly.

What's in Core? #

The Core folder is organized per system, with each system having its own subfolder containing its abstract classes, data models, and shared functionality.

Structure:

Hyper/Core/

├── InventorySystem/
│ ├── Enums/
│ ├── Structures/
│ ├── Interfaces/
│ └── AbstractClasses/
├── EquipmentSystem/
│ ├── Enums/
│ ├── Structures/
│ ├── Interfaces/
│ └── AbstractClasses/
├── QuestSystem/
│ ├── Enums/
│ ├── Structures/
│ ├── Interfaces/
│ └── AbstractClasses/
├── AttributeSystem/
│ ├── Enums/
│ ├── Structures/
│ ├── Interfaces/
│ └── AbstractClasses/
└── [... other systems ...]

What's in Each System Folder:

Enums:

Hyper/Core/InventorySystem/Enums/

├── Enum_ItemType
├── Enum_ItemRarity
└── [... other enums ...]

Naming Convention: Enum_[Name]

Enums define fixed sets of options (Item Type: Weapon, Armor, Consumable, etc.).

Structures:

Hyper/Core/InventorySystem/Structures/

├── Struct_ItemData
├── Struct_InventorySlot
└── [... other structures ...]

Naming Convention: Struct_[Name]

Structures define the data format used by the system.

Interfaces:

Hyper/Core/InventorySystem/Interfaces/

├── BPI_Inventory
├── BPI_Interactable
└── [... other interfaces ...]

Interfaces allow systems to communicate without tight coupling.

Abstract Classes:

Hyper/Core/InventorySystem/AbstractClasses/

├── AC_ItemBase (abstract item class)
└── [... other abstract classes ...]

Naming Convention: AC_[Name]

Abstract classes define the blueprint that system components inherit from, ensuring consistency.

Why Per-System Organization?:

  • ✅ Clear ownership: Know which system each data model belongs to
  • ✅ Easy to find: All inventory-related core files in one place
  • ✅ Modular: Can see exactly what core files each system provides
  • ✅ No clutter: Don't mix unrelated system data models together

Why Separate Core? #

Problem Without Core Folder:

Bad Structure (without Core):

Hyper/InventorySystem/

├── F_ItemData (structure)
├── E_ItemType (enum)
└── BPI_Inventory (interface)

Hyper/EquipmentSystem/

├── F_ItemData (duplicate structure - conflict!)
├── E_EquipmentSlot (enum)
└── BPI_Equipment (interface)

Hyper/QuestSystem/

├── F_ItemData (duplicate structure - conflict!)
└── F_RewardData (references F_ItemData - which one?)

Result:

❌ Duplicate definitions

❌ Conflicts between systems

❌ Can't share data models

❌ Systems don't integrate well

Solution With Core Folder:

Good Structure (with Core):

Hyper/Core/InventorySystem/Structures/

└── Struct_ItemData (SINGLE definition)

Hyper/InventorySystem/

└── (references Core/InventorySystem/Struct_ItemData)

Hyper/EquipmentSystem/

└── (references Core/InventorySystem/Struct_ItemData)

Hyper/QuestSystem/

└── (references Core/InventorySystem/Struct_ItemData)

Result:

  • Single source of truth
  • No conflicts
  • All systems use same data format
  • Perfect integration

Template Compatibility:

When you buy a template (e.g., Multiplayer Survival):

  • Template references Level System (for XP and progression)
  • Inventory System references Level System (for level requirements)
  • Equipment System references Level System (for equipment requirements)

All these references point to Hyper/Core/LevelSystem/AbstractClasses/AC_LevelBase, ensuring compatibility.

Benefits:
  • ✅ Clean Organization: Systems don't duplicate shared code
  • ✅ Easy Integration: New systems automatically compatible
  • ✅ Maintainability: Update shared code in one place
  • ✅ Scalability: Add unlimited systems without conflicts
  • ✅ Template Support: All template systems work together

Templates folder #

Purpose #

The Templates folder contains complete template projects that you can purchase.

Location: Hyper/Templates/

What Are Templates?:

Templates are full, ready-to-use game projects (e.g., Multiplayer Survival Template) that include multiple systems working together.

Structure #

Template-Specific vs. Systems:

  • Templates folder: Contains template-specific content (game modes, maps, player controllers)
  • System folders: Contains reusable systems (inventory, crafting, quests)
Example – Multiplayer Survival Template:

When you buy the template, you get:

Hyper/Templates/MultiplayerSurvival/ (template-specific)

├── Game mode for multiplayer survival
├── Survival world map
├── Player controller for survival
└── Template-specific blueprints

Hyper/InventorySystem/ (reusable system)

Hyper/CraftingSystem/ (reusable system)

Hyper/EquipmentSystem/ (reusable system)

Hyper/QuestSystem/ (reusable system)

Hyper/AttributeSystem/ (reusable system)

Hyper/BuildingSystem/ (reusable system)

… (all systems used by template)

Hyper/Core/ (shared abstract classes and data models)

Hyper/UI/ (all UI for template and systems)

Hyper/ResourcePack/ (all assets)

System Modularity #

Key Benefit: Systems are separate from templates, so you can:

  • ✅ Use individual systems without buying templates
  • ✅ Use systems from one template in another template
  • ✅ Mix and match systems for custom projects
  • ✅ Update systems independently
Example:

Scenario: You buy Inventory System separately (not template)

You get:

├── Hyper/Core/ (abstract classes)
├── Hyper/InventorySystem/ (inventory logic)
├── Hyper/InteractionSystem/ (works with inventory)
├── Hyper/UI/Inventory/ (inventory UI)
└── Hyper/ResourcePack/ (icons, meshes)

Later, you buy Crafting System:

Added:

├── Hyper/CraftingSystem/ (crafting logic)
├── Hyper/UI/Crafting/ (crafting UI)
└── (references same Core folder - automatically compatible!)

Result:

  • Inventory + Crafting work together seamlessly
  • No conflicts
  • Shared data models (F_ItemData, etc.)
  • Can add unlimited systems this way

Individual system folders #

Each system (Inventory, Equipment, Quests, etc.) has its own folder at the root level of Hyper.

Location: Hyper/[SystemName]/

Standard Structure #

Every system folder follows a consistent structure:

Hyper/[SystemName]/

├── Blueprints/
│ ├── Components/
│ ├── Actors/
│ ├── Widgets/ (if system-specific, otherwise in UI folder)
│ └── [... system blueprints ...]
└── Maps/
 └── [SystemName]_Example
Example – Inventory System:

Hyper/InventorySystem/

├── Blueprints/
│ ├── Components/
│ │ └── AC_InventoryComponent
│ ├── Actors/
│ │ └── BP_DroppedItem
│ └── DataTables/
│ └── DT_Items
└── Maps/
 └── InventorySystem_Example
Example – Equipment System:

Hyper/EquipmentSystem/

├── Blueprints/
│ ├── Components/
│ │ └── AC_EquipmentComponent
│ ├── DataTables/
│ │ └── DT_Equipment
│ └── [... equipment blueprints ...]
└── Maps/
 └── EquipmentSystem_Example
Example – Quest System:

Hyper/QuestSystem/

├── Blueprints/
│ ├── Components/
│ │ └── AC_QuestComponent
│ ├── DataTables/
│ │ └── DT_Quests
│ └── [... quest blueprints ...]
└── Maps/
 └── QuestSystem_Example

Blueprints Folder #

Location: Hyper/[SystemName]/Blueprints/

Contains all blueprints specific to that system.

Common Subfolders:

Blueprints/

├── Components/
│ └── (Components for the system)
├── Actors/
│ └── (Actors for the system)
├── DataTables/
│ └── (System-specific data tables)
├── Functions/
│ └── (Blueprint function libraries)
└── [... other blueprint types ...]

What Goes Here:

  • ✅ System components (AC_InventoryComponent, AC_QuestComponent, etc.)
  • ✅ System actors (BP_DroppedItem, BP_QuestGiver, etc.)
  • ✅ System-specific data tables (DT_Items, DT_Quests, etc.)
  • ✅ System functions and utilities

What Does NOT Go Here:

  • ❌ UI widgets (go in Hyper/UI/ instead)
  • ❌ Shared abstract classes (go in Hyper/Core/[SystemName]/ instead)
  • ❌ Shared data models (go in Hyper/Core/[SystemName]/ instead)

Maps Folder #

Location: Hyper/[SystemName]/Maps/

Contains example map demonstrating the system.

Purpose:

  • Shows how the system works
  • Provides testing environment
  • Demonstrates best practices
  • Reference for integration
Example:

Hyper/InventorySystem/Maps/

└── InventorySystem_Example
 - Demonstrates inventory UI
 - Shows item pickup interaction
 - Example items placed in world
 - Test player character with inventory

Naming Convention:

[SystemName]_Example

Examples:
  • InventorySystem_Example
  • EquipmentSystem_Example
  • QuestSystem_Example
  • CraftingSystem_Example

Resource pack folder #

Purpose #

The Resource Pack folder contains all visual and audio assets provided by Games by Hyper.

Location: Hyper/ResourcePack/

Contents #

Hyper/ResourcePack/

├── Icons/
│ ├── Items/
│ │ ├── Weapons/
│ │ ├── Armor/
│ │ ├── Consumables/
│ │ └── Materials/
│ ├── UI/
│ │ ├── Buttons/
│ │ ├── Backgrounds/
│ │ └── Icons/
│ └── Abilities/
├── Meshes/
│ ├── Items/
│ │ ├── Weapons/
│ │ ├── Armor/
│ │ └── Props/
│ ├── Characters/
│ └── Environment/
├── Materials/
│ ├── UI/
│ ├── Items/
│ └── Effects/
├── Niagara/
│ ├── Effects/
│ │ ├── Fire/
│ │ ├── Magic/
│ │ └── Weather/
│ └── Particles/
├── Sounds/
│ ├── UI/
│ │ ├── Clicks/
│ │ ├── Notifications/
│ │ └── Alerts/
│ ├── Items/
│ │ ├── Equip/
│ │ ├── Pickup/
│ │ └── Use/
│ └── Ambient/
├── Textures/
│ ├── UI/
│ ├── Items/
│ └── Effects/
└── Animations/
 └── [... animations ...]

What's Included:

  • Icons: Item icons, UI icons, ability icons
  • Meshes: 3D models for items, characters, props
  • Materials: UI materials, item materials, effect materials
  • Niagara Effects: Particle systems (magic, fire, weather, etc.)
  • Sounds: UI sounds, item sounds, ambient sounds
  • Textures: UI textures, item textures, effect textures
  • Animations: Character animations, item animations

System-Specific Resources:

Some systems include more resources than others:

  • Inventory System: Many item icons, meshes, sounds
  • Crafting System: Crafting station meshes, effect particles
  • Weather System: Weather particles, sky textures, ambient sounds
  • Ability System: Ability icons, effect particles, cast sounds

Ui folder #

Purpose #

The UI folder contains all user interface widgets and elements for all systems.

Location: Hyper/UI/

Key Concept:

All UI is centralized in one folder, organized by function and system.

This keeps UI separate from system logic and makes it easy to find/modify interface elements.

Widgets Subfolder (Generic Elements) #

Location: Hyper/UI/Widgets/

Contains generic, reusable UI elements used across multiple systems.

Structure:

Hyper/UI/Widgets/

├── Buttons/
│ ├── UI_Button_Master
├── Dialogs/
│ ├── UI_ConfirmDialog
│ ├── UI_MessageBox
│ └── UI_InputDialog
├── Panels/
│ ├── UI_Panel_Standard
│ ├── UI_Panel_Scrollable
│ └── UI_Panel_Tabs
├── Elements/
│ ├── UI_ProgressBar
│ ├── UI_Slider
│ ├── UI_Checkbox
│ └── UI_DropdownMenu
└── [... other generic elements ...]
Examples of Generic Elements:
  • ✅ Buttons: Standard button, close button, confirm button, cancel button
  • ✅ Dialogs: Confirm dialog, message box, input dialog
  • ✅ Panels: Standard panel, scrollable panel, tabbed panel
  • ✅ Elements: Progress bars, sliders, checkboxes, dropdowns
  • ✅ Notifications: Toast notifications, alert popups

Why Generic Elements?:

Example – Confirm Dialog:

Used by:

  • Inventory (Delete item confirmation)
  • Equipment (Unequip confirmation)
  • Quest (Abandon quest confirmation)
  • Crafting (Craft item confirmation)
  • Settings (Reset settings confirmation)
Benefits:
  • Consistent look and feel
  • No duplicate widgets
  • Update once, affects all systems
  • Faster development

Main Widgets Subfolder #

Location: Hyper/UI/MainWidgets/

Contains main UI screens and core interface elements.

Structure:

Hyper/UI/MainWidgets/

├── UI_InGameHUD
├── UI_MenuHome
├── UI_PauseMenu
├── UI_Settings
└── [... other main widgets ...]
Examples:
  • UI_InGameHUD: In-game heads-up display (health, stamina, hotbar, etc.)
  • UI_MenuHome: Main menu / menu home screen
  • UI_PauseMenu: Pause menu overlay
  • UI_Settings: Settings screen (graphics, audio, controls, etc.)

NOT “Main Menu Home”:

The menu home screen is UI_MenuHome, not “Main Menu Home”.

System-Specific Subfolders #

Location: Hyper/UI/[SystemName]/

Each system has its own subfolder containing system-specific UI widgets.

Structure:

Hyper/UI/

├── Widgets/ (generic elements)
├── MainWidgets/ (main screens)
├── Inventory/
│ ├── UI_InventoryMenu
│ ├── UI_ItemSlot
│ ├── UI_ItemTooltip
│ └── UI_ItemDragDrop
├── Equipment/
│ ├── UI_EquipmentMenu
│ ├── UI_EquipmentSlot
│ └── UI_EquipmentStats
├── Crafting/
│ ├── UI_CraftingMenu
│ ├── UI_RecipeList
│ ├── UI_RecipeDetails
│ └── UI_CraftingProgress
├── Quest/
│ ├── UI_QuestJournal
│ ├── UI_QuestEntry
│ ├── UI_QuestTracker
│ └── UI_QuestRewards
├── Attribute/
│ ├── UI_AttributeBars
│ ├── UI_AttributeTooltip
│ └── UI_StateEffectIcon
├── Ability/
│ ├── UI_AbilityBar
│ ├── UI_AbilitySlot
│ └── UI_AbilityCooldown
├── Vendor/
│ ├── UI_VendorMenu
│ ├── UI_VendorItem
│ └── UI_BuySellPanel
└── [... other systems ...]
Benefits of System-Specific Subfolders:
  • ✅ Easy to Find: All inventory UI in Inventory folder, all quest UI in Quest folder
  • ✅ Clear Organization: No confusion about which widget belongs to which system
  • ✅ Modular: Can remove entire system folder if not needed
  • ✅ Scalable: Add new systems with own UI folders
Example – Inventory UI:

Hyper/UI/Inventory/

├── UI_InventoryMenu (main inventory screen)
├── UI_ItemSlot (individual item slot widget)
├── UI_ItemTooltip (item tooltip on hover)
└── UI_ItemDragDrop (drag-and-drop visual)

All inventory-related UI in one place!

Example – Quest UI:

Hyper/UI/Quest/

├── UI_QuestJournal (quest journal screen)
├── UI_QuestEntry (individual quest entry)
├── UI_QuestTracker (on-screen quest tracker)
└── UI_QuestRewards (quest reward display)

All quest-related UI in one place!

Naming conventions #

We use consistent prefixes for all asset types to make finding files easy.

Prefix Guide:

| Asset Type | Prefix | Example |

|————|——–|———|

| **UI Widgets** | `UI_` | UI_InventoryMenu, UI_ItemSlot, UI_ConfirmDialog |

| **Components** | `AC_` | AC_InventoryComponent, AC_QuestComponent, AC_EquipmentComponent |

| **Structures** | `Struct_` | Struct_ItemData, Struct_AttributeData, Struct_QuestData |

| **Enums** | `Enum_` | Enum_ItemType, Enum_EquipmentSlot, Enum_QuestStatus |

| **Data Tables** | `DT_` | DT_Items, DT_Equipment, DT_Quests |

| **Data Assets** | `DA_` | DA_Sunny, DA_Rainy, DA_GameSettings |

| **Blueprints (Other)** | `BP_` | BP_DroppedItem, BP_QuestGiver, BP_Interactable |

| **Interfaces** | `BPI_` | BPI_Inventory, BPI_Interactable, BPI_Saveable |

| **Abstract Classes** | `AC_` | AC_ItemBase, AC_QuestBase, AC_AbilityBase |

Why Use Prefixes?:

  • ✅ Quick Identification: Instantly know what type of asset you're looking at
  • ✅ Easy Searching: Search “UI_” to find all widgets, “Struct_” to find all structures
  • ✅ Alphabetical Grouping: Related assets group together in Content Browser
  • ✅ Ctrl+P Search: Type prefix + partial name to find files instantly
  • ✅ No Confusion: Clear distinction between different asset types
Examples in Practice:

Inventory System Files:

  • AC_InventoryComponent (component)
  • Struct_ItemData (structure)
  • Enum_ItemType (enum)
  • DT_Items (data table)
  • UI_InventoryMenu (widget)
  • UI_ItemSlot (widget)
  • BP_DroppedItem (actor blueprint)
  • BPI_Inventory (interface)

Quest System Files:

  • AC_QuestComponent (component)
  • Struct_QuestData (structure)
  • Enum_QuestStatus (enum)
  • DT_Quests (data table)
  • UI_QuestJournal (widget)
  • UI_QuestEntry (widget)
  • BP_QuestGiver (actor blueprint)
  • BPI_Quest (interface)

Using Ctrl+P with Prefixes:

Press Ctrl+P, then type:

“UI_Inv” → Shows:

  • UI_InventoryMenu
  • UI_InventorySlot
  • … (all inventory UI widgets)

“Struct_” → Shows:

  • Struct_ItemData
  • Struct_AttributeData
  • Struct_QuestData
  • … (all structures)

“AC_” → Shows:

  • AC_InventoryComponent
  • AC_QuestComponent
  • AC_EquipmentComponent
  • … (all components and abstract classes)

Folder hierarchy diagram #

Complete Folder Hierarchy:

Content/

└── Hyper/ (ROOT - Everything from Games by Hyper)
 │
 ├── Core/ (SHARED - Abstract classes, data models, organized per system)
 │ ├── InventorySystem/
 │ │ ├── Enums/
 │ │ ├── Structures/
 │ │ ├── Interfaces/
 │ │ └── AbstractClasses/
 │ ├── EquipmentSystem/
 │ │ ├── Enums/
 │ │ ├── Structures/
 │ │ ├── Interfaces/
 │ │ └── AbstractClasses/
 │ └── [... other systems ...]
 │
 ├── Templates/ (TEMPLATES - Complete template projects)
 │ ├── MultiplayerSurvival/
 │ │ ├── Blueprints/
 │ │ └── Maps/
 │ └── [... other templates ...]
 │
 ├── InventorySystem/ (SYSTEM - Individual system)
 │ ├── Blueprints/
 │ └── Maps/
 │
 ├── EquipmentSystem/ (SYSTEM - Individual system)
 │ ├── Blueprints/
 │ └── Maps/
 │
 ├── QuestSystem/ (SYSTEM - Individual system)
 │ ├── Blueprints/
 │ └── Maps/
 │
 ├── [... other systems ...]
 │ ├── Blueprints/
 │ └── Maps/
 │
 ├── ResourcePack/ (ASSETS - Visual and audio assets)
 │ ├── Icons/
 │ ├── Meshes/
 │ ├── Materials/
 │ ├── Niagara/
 │ ├── Sounds/
 │ ├── Textures/
 │ ├── Animations/
 │ └── Shared/
 │
 └── UI/ (USER INTERFACE - All UI widgets)
 ├── Widgets/ (generic elements)
 ├── MainWidgets/ (main screens)
 ├── Inventory/ (inventory UI)
 ├── Equipment/ (equipment UI)
 ├── Quest/ (quest UI)
 ├── Attribute/ (attribute UI)
 ├── Ability/ (ability UI)
 └── [... other system UI ...]

Navigation Flow:

Looking for Inventory Component?

→ Hyper/InventorySystem/Blueprints/Components/AC_InventoryComponent

Looking for Item Data Structure?

→ Hyper/Core/InventorySystem/Structures/Struct_ItemData

Looking for Inventory Menu Widget?

→ Hyper/UI/Inventory/UI_InventoryMenu

Looking for Item Icons?

→ Hyper/ResourcePack/Icons/Items/

Looking for Generic Confirm Dialog?

→ Hyper/UI/Widgets/Dialogs/UI_ConfirmDialog

Looking for Quest Abstract Class?

→ Hyper/Core/QuestSystem/AbstractClasses/AC_QuestBase

Looking for Example Map?

→ Hyper/InventorySystem/Maps/InventorySystem_Example

Best practices #

Navigation Tips #

Quick Navigation:

  • Know the category: Is it logic (system folder), UI (UI folder), or asset (Resource Pack)?
  • Find the system: Inventory, Equipment, Quest, etc.
  • Navigate to specific subfolder: Blueprints, Maps, UI, etc.

Content Browser Favorites:

Add frequently used folders to favorites:

Favorites:

  • Hyper/Core/
  • Hyper/UI/
  • Hyper/ResourcePack/
  • Hyper/InventorySystem/
  • Hyper/[your most-used system]/

Quick Open with Ctrl+P:

Unreal Engine's Quick Open feature (Ctrl+P) is the fastest way to find files:

Press Ctrl+P, then type:

  • “UI_Inventory” → Opens UI_InventoryMenu
  • “Struct_Item” → Opens Struct_ItemData
  • “AC_Inventory” → Opens AC_InventoryComponent
  • “Enum_Item” → Opens Enum_ItemType
  • “DT_Items” → Opens DT_Items data table
Benefits:
  • No need to navigate folder structure
  • Fuzzy search (partial matches work)
  • Shows all matching results instantly
  • Much faster than browsing folders

Search Tips:

Search by Prefix:

  • “UI_” → Finds all widgets
  • “AC_” → Finds all components
  • “DT_” → Finds all data tables
  • “Struct_” → Finds all structures
  • “Enum_” → Finds all enums
  • “BP_” → Finds all other blueprints

Search by System:

  • “Inventory” → Finds all inventory-related content
  • “Quest” → Finds all quest-related content

Naming Convention Summary:

UI Widgets: UI_[Name]

Components: AC_[Name]

Structures: Struct_[Name]

Enums: Enum_[Name]

Data Tables: DT_[Name]

Data Assets: DA_[Name]

Other Blueprints: BP_[Name]

Adding Your Own Content #

Where to Put Your Content:

  • DO:

Create your own root folder:

Content/

├── Hyper/ (Games by Hyper content - DON'T MODIFY)
└── MyProject/ (Your content - SAFE TO MODIFY)
 ├── Blueprints/
 ├── Maps/
 ├── UI/
 └── [... your folders ...]

❌ DON'T:

Don't add to Hyper folder:

Content/

└── Hyper/
 ├── InventorySystem/
 │ └── MyCustomInventory ← DON'T DO THIS
 └── MyCustomSystem/ ← DON'T DO THIS

Why?

  • ✅ Your content won't be overwritten when updating Hyper systems
  • ✅ Clear separation between our content and yours
  • ✅ Easier to manage and migrate

Modifying vs. Extending Our Systems:

⚠️ IMPORTANT – Modifying Our Files:

You CAN modify our system files directly:

  • Edit blueprints in Hyper/InventorySystem/
  • Modify UI widgets in Hyper/UI/
  • Change data tables, structures, etc.

BUT:

❌ We do NOT support updating if you modify our files

❌ Updates will overwrite your changes

❌ You'll lose customizations when updating

Only modify directly if:

  • You don't plan to update
  • You're willing to re-apply changes after updates
  • You maintain a backup of your modifications

BEST PRACTICE – Create Child Blueprints:

If you need custom logic, create child blueprints in your own folder:

Content/MyProject/Blueprints/

└── AC_MyInventoryComponent (child of AC_InventoryComponent)
 - Inherits from Hyper/InventorySystem/Blueprints/Components/AC_InventoryComponent
 - Add your custom logic here
 - Override specific functions if needed
 - Safe from updates
 - Can update parent system without losing changes

How to create child blueprint:

  1. Right-click AC_InventoryComponent
  2. Select “Create Child Blueprint Class”
  3. Save in your project folder
  4. Use your child component instead of original
Benefits of Child Blueprints:
  • ✅ Keep all original functionality
  • ✅ Add custom logic without modifying our files
  • ✅ Override only what you need
  • ✅ Safe to update parent systems
  • ✅ We support this approach
  • ✅ Best practice in Unreal Engine

Maintaining Organization #

When Adding New Systems:

If you purchase a new system later:

  • Extract to Hyper folder (new system folder appears)
  • Core folder updates (new abstract classes, data models)
  • UI folder updates (new UI subfolder)
  • Resource Pack folder updates (new assets)

Everything automatically integrates because all systems reference the same Core folder.

Version Control:

If using version control (Git, Perforce, etc.):

Track Hyper folder:

  • Commit when you first add systems
  • Commit when you update systems
  • Easy to see what changed

Separate your content:

  • Your folder is in separate commits
  • Clear history of your work vs. system updates

Backup Before Updates:

Before updating Hyper systems:

  • Backup entire Hyper folder
  • Update systems
  • Test in example maps
  • If issues, revert to backup

Keep UI Customizations Separate:

If you customize UI:

Good approach:

  1. Duplicate UI_InventoryMenu to your folder
  2. Rename to UI_MyInventoryMenu
  3. Customize your version
  4. Reference your version in your blueprints

OR (Better):

  1. Create child widget blueprint of UI_InventoryMenu
  2. Save in your folder as UI_MyInventoryMenu
  3. Override only what you need
  4. Inherits updates to parent automatically

Why?

  • Original UI_InventoryMenu unchanged
  • Updates won't overwrite your customizations
  • Can still reference original if needed
  • Child blueprints get parent updates automatically
  • —

END OF DOCUMENTATION

Summary:

Games by Hyper's folder structure is organized for modularity, clarity, and scalability:

  • Hyper/: Root folder for all our content
  • Core/: Shared abstract classes, data models, interfaces (central communication hub)
  • Templates/: Complete template projects (Multiplayer Survival, etc.)
  • [System Folders]: Individual systems (Inventory, Equipment, Quest, etc.) with Blueprints and Maps subfolders
  • ResourcePack/: All visual and audio assets (icons, meshes, sounds, effects)
  • UI/: All user interface widgets, organized by Widgets (generic), MainWidgets (main screens), and system-specific subfolders

This structure ensures:

  • ✅ Clean organization
  • ✅ Easy navigation
  • ✅ Seamless system integration
  • ✅ Scalability for unlimited systems
  • ✅ Template compatibility
  • ✅ Separation between our content and yours

Understanding this structure will help you work efficiently with our systems and build amazing projects!

What are your Feelings