🏗️ Lesson 8.1: Modules in Depth — Build.cs & Target.cs

Public vs Private

A module can split its code into Public/ and Private/ folders. This isn't cosmetic — it controls what other modules can include.

Source/MyModule/
├── MyModule.Build.cs
├── Public/                 # headers other modules CAN include
│   └── MyPublicClass.h
└── Private/                # headers only THIS module can include
    ├── MyPublicClass.cpp
    └── MyInternalHelper.h  # implementation detail, hidden from others

The Full Build.cs

Lesson 2.1 covered dependency lists. A .Build.cs controls much more — it's C# that runs at build time:

public class MyModule : ModuleRules
{
    public MyModule(ReadOnlyTargetRules Target) : base(Target)
    {
        PCHUsage = PCHUsageMode.UseExplicitOrSharedPCHs;

        // Public: dependencies exposed through THIS module's public headers.
        PublicDependencyModuleNames.AddRange(new string[]
        { "Core", "CoreUObject", "Engine" });

        // Private: dependencies used only in .cpp files.
        PrivateDependencyModuleNames.AddRange(new string[]
        { "Slate", "SlateCore" });

        // Extra include paths (e.g. for third-party headers — Lesson 8.2).
        PublicIncludePaths.AddRange(new string[] { /* ... */ });

        // Toggle IWYU-friendly builds, unity builds, optimization, etc.
        bUseUnity = true;                    // combine cpp files for faster builds
        // OptimizeCode = CodeOptimization.InShippingBuildsOnly;
    }
}

Target.cs & Configurations

A .Target.cs configures a whole build output (Lesson 2.1: game vs editor). It also chooses which modules to include and default settings for the target.

// MyProject.Target.cs — the game target
public class MyProjectTarget : TargetRules
{
    public MyProjectTarget(TargetInfo Target) : base(Target)
    {
        Type = TargetType.Game;
        DefaultBuildSettings = BuildSettingsVersion.Latest;
        IncludeOrderVersion = EngineIncludeOrderVersion.Latest;

        // The modules this target builds:
        ExtraModuleNames.AddRange(new string[] { "MyProject", "MyGameplayModule" });
    }
}

Orthogonal to the target type is the build configuration — the optimization/debug level you compile:

A Second Module

As a project grows, splitting code into multiple modules speeds up builds (only changed modules recompile) and enforces boundaries. To add one, create the folder + files and register it in the .uproject.

// MyGameplayModule.cpp — every module needs an implementation + IMPLEMENT_MODULE.
#include "Modules/ModuleManager.h"

// A minimal module. Use IMPLEMENT_GAME_MODULE for a gameplay module,
// or a custom IModuleInterface (below) if you need startup code.
IMPLEMENT_MODULE(FDefaultModuleImpl, MyGameplayModule);

// In MyProject.uproject — declare the new module:
"Modules": [
    { "Name": "MyProject",         "Type": "Runtime", "LoadingPhase": "Default" },
    { "Name": "MyGameplayModule",  "Type": "Runtime", "LoadingPhase": "Default" }
]

Loading Phases & Startup

Modules load at a loading phase during engine startup — Default is typical, but some modules must load earlier (before the engine is fully up) or later. And a module can run code when it loads by implementing IModuleInterface.

// MyGameplayModule.cpp — a module with startup/shutdown hooks.
#include "Modules/ModuleManager.h"

class FMyGameplayModule : public IModuleInterface
{
public:
    virtual void StartupModule() override
    {
        // Runs when the module loads — register things, load assets, etc.
        UE_LOG(LogTemp, Log, TEXT("MyGameplayModule started"));
    }

    virtual void ShutdownModule() override
    {
        // Runs when the module unloads — clean up what StartupModule did.
        UE_LOG(LogTemp, Log, TEXT("MyGameplayModule shut down"));
    }
};

IMPLEMENT_MODULE(FMyGameplayModule, MyGameplayModule);

💡 The _API macro connects back: the MYPROJECT_API macro you've seen on every UCLASS (since Lesson 1.5) is the module's export macro — it marks a class as visible to other modules that depend on yours. UHT defines one per module (<MODULENAME>_API). A class without it is usable only within its own module. Now you know why it was always there.

Hands-on Exercise & Quiz

Summary

📚 Additional Resources

• Unreal Engine Modules (Epic)
• Build Configurations Reference (Epic)

🚀 What's Next?

Modules organize your code. Next: bringing in other people's code — integrating third-party C++ libraries through the build system, the thing Blueprint simply cannot do.