Skip to main content

Clean Folder Structure (IDE)

Β· 4 min read
Nazake
Game Developer

Unreal Engine's default C++ folder layout works, but it quickly becomes a mess as your game grows. A well-structured Source folder can save hours of debugging and onboarding headaches.

Here’s a clean and modular C++ folder structure that scales with solo and team development.


πŸ“ Folder Structure​

This goes inside your Source/YourProject directory:

Source/YourProject/
β”‚
β”œβ”€β”€ Core/
β”‚ β”œβ”€β”€ YourProject.h
β”‚ β”œβ”€β”€ YourProject.cpp
β”‚ β”œβ”€β”€ LogChannels.h # Centralized log categories
β”‚ └── Utility/ # Macros, helpers, common utilities
β”‚
β”œβ”€β”€ Framework/ # Game framework classes
β”‚ β”œβ”€β”€ GameMode/
β”‚ β”œβ”€β”€ GameState/
β”‚ β”œβ”€β”€ Player/ # Player-specific logic
β”‚ β”‚ β”œβ”€β”€ Character/
β”‚ β”‚ β”œβ”€β”€ Controller/
β”‚ β”‚ └── State/
β”‚ └── HUD/ # HUD/UI related to gameplay
β”‚
β”œβ”€β”€ AI/ # Artificial intelligence
β”‚ β”œβ”€β”€ Controllers/ # AAIController subclasses
β”‚ β”œβ”€β”€ BehaviorTrees/ # BTs, services, tasks, decorators
β”‚ β”œβ”€β”€ Perception/ # Perception system classes
β”‚ └── Data/ # Blackboard data, config

β”œβ”€β”€ Systems/ # Self-contained gameplay systems
β”‚ β”œβ”€β”€ Inventory/ # Inventory system implementation
β”‚ β”‚ β”œβ”€β”€ InventorySystem # Core system classes
β”‚ β”‚ β”œβ”€β”€ InventoryComponents # Component(s) related to inventory
β”‚ β”‚ β”œβ”€β”€ InventoryEnums # Enums used by inventory system
β”‚ β”‚ β”œβ”€β”€ InventoryStructs # Structs and data structures
β”‚ β”‚ β”œβ”€β”€ InventoryDataAssets # UDataAsset definitions
β”‚ β”‚ β”œβ”€β”€ InventoryInterfaces # Interfaces used by inventory system
β”‚ β”‚ └── [Etc...]
β”‚ β”‚
β”‚ β”œβ”€β”€ Abilities/ # Gameplay abilities system
β”‚ β”‚ β”œβ”€β”€ AbilitySystem
β”‚ β”‚ β”œβ”€β”€ AbilityComponents
β”‚ β”‚ β”œβ”€β”€ AbilityEnums
β”‚ β”‚ β”œβ”€β”€ AbilityStructs
β”‚ β”‚ β”œβ”€β”€ AbilityDataAsset
β”‚ β”‚ β”œβ”€β”€ AbilityInterfaces
β”‚ β”‚ └── [Etc...]
β”‚ β”‚
β”‚ β”œβ”€β”€ Interaction/ # Player or world interaction system
β”‚ β”‚ β”œβ”€β”€ InteractionSystem
β”‚ β”‚ β”œβ”€β”€ InteractionComponents
β”‚ β”‚ β”œβ”€β”€ InteractionEnums
β”‚ β”‚ β”œβ”€β”€ InteractionStructs
β”‚ β”‚ β”œβ”€β”€ InteractionInterfaces
β”‚ β”‚ └── [Etc...]
β”‚ β”‚
β”‚ └── [Other systems…]
β”‚
β”œβ”€β”€ Input/ # Enhanced Input support
β”‚ β”œβ”€β”€ Config/ # InputMappingContexts, InputActions
β”‚ └── Handlers/ # Custom input logic or wrappers
β”‚
β”œβ”€β”€ UI/
β”‚ β”œβ”€β”€ Widgets/ # UUserWidget classes
β”‚ └── Data/ # UI-related data assets and enums etc...
β”‚
β”œβ”€β”€ Editor/ # Editor tools, widgets, etc.
β”‚ β”œβ”€β”€ Widgets/
β”‚ └── Data/
β”‚
β”œβ”€β”€ Dev/ # Temporary/test/dev-only code
β”‚ └── Sandbox/
β”‚
└── YourProject.Build.cs # Build configuration file

🧠 Breakdown​

Core​

Core headers, macros, and logging config. Usually where your precompiled header (YourProject.h) and main module file (YourProject.cpp) live. Contains utilities and helper functions common across your entire project.

Framework​

Contains core gameplay framework logic such as GameMode, GameState, HUD, and player-specific classes like Character, Controller, and PlayerState.

AI​

Holds all AI-related logic including behavior trees, blackboard data, AI controllers, and perception components.

Systems​

Self-contained gameplay systems that encapsulate specific game mechanics. Designed to be modular for reuse or plugin conversion.

  • Inventory Implements all inventory-related features: core systems, components for inventory management, enums for item types or states, data structures for item definitions, UDataAssets for configurable data, and interfaces for interaction contracts.

  • Abilities Manages gameplay abilities including the ability system core, ability-related components, enums, structs, data assets, and interfaces to define ability behaviors and effects.

  • Interaction Handles player or world interaction systems: interaction logic, components, enums to define interaction types, data structs, and interfaces to implement consistent interaction contracts.

  • Other systems Add more gameplay systems as needed, following the same modular structure.

Input​

Contains all input-related logic and configuration, such as input mapping contexts, input actions, and input components.

UI​

Contains your UUserWidget C++ classes and any supporting UI logic or data (e.g. data tables, UI enums).

  • Widgets: All UUserWidget subclasses for HUD elements, menus, and UI components.
  • Data: UI-related data assets, enums, and supporting structures.

Editor​

Includes tools, custom editors, and development-only assets used to enhance the Unreal Editor experience.

Dev​

Temporary or experimental code and sandbox tests. Useful for prototyping and development without affecting production code. Should be excluded from shipping builds.


✍️ Naming Conventions​

Stick to Unreal’s coding standards but you can adopt slight variations for clarity:

  • Classes: U, A, F, I prefixes (e.g. UUserWidget, AEnemy, FItemData, IInteractable)
  • Components: UYourProject[Name]Component (e.g. UYourProjectHealthComponent)
  • Systems: Folder-level prefixes like Inventory/, Abilities/, etc.
  • Log Categories: Use a centralized LogChannels.h

βœ… Best Practices​

  • 1 class per file: Avoid multiple classes in one file unless nested or private.
  • Minimal header includes: Use forward declarations where possible.
  • Avoid circular dependencies: Especially between systems β€” use interfaces or weak references.

A clean C++ folder structure reduces confusion, speeds up compile times, and helps new developers (or future you) navigate the codebase with confidence.

Got your own folder strategy or engine module setup? Share it in the comments!