In this lesson, you will learn how to supercharge your project’s compilation speed and maintainability by splitting your game logic into distinct, isolated C++ modules.
The Problem: The Monolithic Bottleneck
When you start a project, all your C++ code usually lives inside a single module (e.g., MyGame). As your game grows, every tiny change you make to a single file forces Unreal’s build system to re-parse and re-compile that entire massive module. This leads to long wait times and tangled dependencies where everything is coupled to everything else.
The Solution: Modular Architecture
Instead of one giant "bucket" for your code, we can create smaller, focused modules. Think of this like organizing your house: instead of throwing everything into one junk drawer, you have separate drawers for kitchen tools, office supplies, and bathroom items.
In Unreal, each module is defined by its own folder, a unique [ModuleName].Build.cs file, and a header/source file for the module itself. By splitting your project—for example, into a CoreGame module and a RuntimeUI module—you ensure that changes in your UI code don't trigger a full recompilation of your core gameplay logic.
How it looks
Each module requires its own Build.cs file. This file tells the engine exactly what that specific module needs to function:
// RuntimeUI.Build.cs
public class RuntimeUI : ModuleRules {
public RuntimeUI(ReadOnlyTargetRules Target) : base(Target) {
PCHUsage = PCHUsageMode.UseExplicitOrSharedPCHs;
// Only include what this module specifically needs
PublicDependencyModuleNames.AddRange(new string[] { "Core", "CoreUObject", "Engine", "UMG" });
}
}
By explicitly defining PublicDependencyModuleNames, you force yourself to be intentional about what your code talks to. If RuntimeUI doesn't need to know about your PhysicsEngine module, you simply don't include it. This separation keeps your compile times snappy and your code architecture clean, preventing "spaghetti" dependencies from forming across your entire project.
Key Takeaway: Splitting your project into smaller, independent modules significantly reduces compilation times and prevents tightly coupled code by enforcing clear boundaries through individual Build.cs configurations.