An empty Unreal Engine 5 project — literally nothing in it but the default map — packages to over 321MB. Add a few Marketplace assets, some plugins you tried but forgot about, and the typical accumulation of six months of development, and you are looking at a 5-15GB build for a game that might only need 1-2GB of actual content. Players notice. Reviewers notice. Steam Deck owners with 64GB of storage especially notice.

Reducing UE5 build size is not difficult, but it requires systematic work across multiple areas: plugin auditing, asset reference cleanup, cooking settings, compression configuration, shader permutation control, and platform-specific optimization. Most teams can cut their shipping build by 40-60% without removing any actual game content.

This guide covers every optimization technique available for UE5 packaging and shipping in 2026. We walk through the complete process from initial audit to final package, including how to use the Unreal MCP Server to automate the tedious scanning and configuration work, how to ship only the Blueprint Template Library modules your game actually uses, and specific considerations for Steam Deck and other storage-constrained platforms.

The Problem: Where Does the Size Come From?

Before optimizing, you need to understand what is actually consuming space. A typical UE5 project's build size breaks down roughly like this:

Default Engine Content (100-200MB)

UE5 includes engine content that gets cooked into every project by default:

• Engine textures and materials: Default materials, debug textures, preview assets — roughly 40-60MB
• Engine meshes: Primitives, preview meshes, placeholder geometry — 10-20MB
• Shader bytecode: Compiled shaders for all materials, including engine defaults — 50-100MB depending on target platform and RHI
• Internationalization data: ICU data for text rendering and locale support — 25-40MB

Plugin Content (50-500MB+)

Every enabled plugin can contribute content to your build, even if you never reference it directly:

• Niagara: The particle system plugin includes default emitters and module scripts. Even if you use Niagara, you probably don't need every default asset. Cost: 20-60MB
• Paper2D: If you are making a 3D game, this is dead weight. Cost: 5-15MB
• MediaFramework plugins: Media player plugins for formats you don't use. Cost: 5-20MB each
• AI Module / Navigation: If your game has no AI or navmesh, these contribute unused content. Cost: 10-30MB
• Marketplace plugins: Third-party plugins often include example content, documentation assets, and demo maps that get cooked. Cost: varies wildly, 10-200MB per plugin

Your Content (Highly Variable)

Your actual game content is usually the largest portion, but also the most compressible:

• Textures: Typically 40-70% of total content size before compression
• Meshes: 10-20% of content
• Audio: 5-15% of content
• Animations: 5-10% of content
• Blueprints and data assets: Usually small (< 5%)

Orphaned and Unreferenced Content (0-30%)

Assets that nothing references but that still get cooked because they exist in directories that the cooker scans. This includes:

• Test maps and prototype levels
• Abandoned material experiments
• Imported reference assets
• Duplicate textures imported at different times
• Unused LOD levels or texture variants

Step 1: Plugin Audit — Disable What You Don't Need

The fastest size reduction comes from disabling unused plugins. Every enabled plugin potentially adds binaries, content, and shader permutations to your build.

How to Audit Plugins

Open Edit > Plugins and systematically review every enabled plugin. For each one, ask:

1. Does my game use this plugin's features?
2. If yes, do I reference its content directly?
3. If I disable it, does my project still compile and run?

Plugins Safe to Disable for Most Projects

Here is a list of commonly enabled plugins that many projects don't actually need:

2D/Paper2D Plugins:

• Paper2D — Unless you are making a 2D game or using sprite rendering
• Paper2D Tilemap — Tilemap support for 2D games

AI Plugins (if no AI in your game):

• AIModule — Core AI framework
• AITestSuite — AI testing framework (should never ship)
• EnvironmentQueryEditor — EQS editor support

Audio Plugins (platform-specific):

• AudioCapture — Microphone input (unless your game uses voice)
• Synthesis — Procedural audio generation (unless used)

Platform Plugins (disable for platforms you don't ship on):

• AndroidMedia, AndroidMoviePlayer — If not shipping on Android
• AppleMoviePlayer — If not shipping on Apple platforms
• WindowsMoviePlayer — If using a different media playback solution
• AvfMedia, WmfMedia — Platform-specific media frameworks

XR Plugins (if not a VR/AR game):

• OpenXR, OculusVR, SteamVR — Each adds runtime binaries
• HeadMountedDisplay — Core VR framework

Editor/Development Plugins:

• CryptoKeys — Editor-only key generation
• FacialAnimation — If not using facial animation
• MagicLeapMedia — MagicLeap platform (rarely needed in 2026)
• MediaCompositing — Advanced media compositing

Online Plugins (if single-player offline):

• OnlineSubsystem — Core online framework
• OnlineSubsystemUtils — Online utilities

Automating the Plugin Audit

Manually checking each plugin is tedious, especially when you have 80+ plugins enabled. The Unreal MCP Server with its 207 tools can automate this process:

• Scan all enabled plugins and list them with their estimated size contribution
• Cross-reference plugin content with your project's asset references to identify plugins whose content is never referenced
• Generate a report of plugins that are safe to disable based on dependency analysis
• Batch-disable plugins from a list (with backup of the original .uproject file)

After disabling plugins, always do a full rebuild and test. Some plugins have non-obvious dependencies — for example, the Niagara plugin is required if any particle system in your project uses it, even if you don't think you added Niagara effects (Marketplace assets often include them).

Expected Savings

Plugin cleanup alone typically saves 50-200MB, depending on how many unnecessary plugins were enabled. Projects that started from a template with "all bells and whistles" may save even more.

Step 2: Asset Reference Scanning

Orphaned assets — files that exist in your project but are never referenced by anything that gets cooked — are pure waste in your build.

Finding Orphaned Assets

UE5 provides the Size Map tool (Window > Developer Tools > Size Map) that shows asset sizes in a treemap visualization. But this shows all assets, not just referenced ones.

For finding specifically orphaned assets, use the Reference Viewer:

1. Right-click an asset > Reference Viewer
2. Look for assets with no inbound references (nothing points to them)
3. These assets will only be cooked if they are in a directory that the cooker explicitly includes

A more systematic approach is the Asset Audit:

1. Open the Asset Audit window (Window > Developer Tools > Audit)
2. This shows disk size, memory size, and reference counts for all assets
3. Sort by reference count — assets with 0 references are candidates for removal or exclusion

The Cooker's Directory Scanning Behavior

Understanding how the cooker decides what to cook is essential:

Always cooked: Assets referenced (directly or indirectly) by any map listed in your Packaging settings' "Maps to Include" list. This follows the entire reference chain — if Map_A references Blueprint_B which references Texture_C, all three are cooked.

Additionally cooked: Assets in any directory listed in "Additional Directories to Cook" (Project Settings > Packaging). This is where accidental inclusion happens — if you added /Game/ to this list (a common mistake), every asset in your project gets cooked regardless of whether it is referenced.

Never cooked: Assets in directories listed in "Directories to Never Cook."

Cleaning Up References

Common sources of orphaned references:

Redirect chains: When you rename or move assets, UE5 creates redirectors. These can create reference chains that pull in old assets. Run "Fix Up Redirectors in Folder" on your entire Content directory.

Soft references in code: TSoftObjectPtr and FSoftObjectPath in C++ or soft references in Blueprints create references the reference viewer shows but that might only be loaded at runtime under specific conditions. These are legitimate references but worth reviewing — do you still use that feature path?

Level streaming references: Sub-levels reference their own set of assets. If you removed a sub-level from your level list but didn't delete the sub-level asset, its references still exist (though they may not cook if the sub-level's map isn't in the cook list).

Data table and curve table references: Data tables can reference assets in their rows. These references are real and will cause cooking, even if the specific row is never accessed at runtime.

Using MCP for Asset Scanning

The Unreal MCP Server can automate the asset scanning process:

• Scan the entire project for assets with zero inbound references
• Identify reference chains that are the sole path to large assets (removing one reference might free hundreds of MB)
• Find duplicate assets (same source file imported multiple times)
• Generate a cleanup report with estimated size savings per action

This is particularly valuable for projects that have been in development for months or years, where accumulation of unused assets is inevitable.

Expected Savings

Reference cleanup typically saves 10-30% of content size. Projects with heavy prototyping phases or extensive Marketplace asset usage often save more.

Step 3: DefaultEngine.ini Cooking Settings

The DefaultEngine.ini file controls many cooking behaviors that affect build size.

Essential Cooking Settings

Add or modify these in your project's Config/DefaultEngine.ini:

Exclude editor-only content:

[/Script/UnrealEd.ProjectPackagingSettings]
bSkipEditorContent=True

This prevents content in /Engine/EditorResources/, /Engine/EditorMeshes/, and similar editor-only directories from being cooked. Savings: 20-50MB.

Exclude unused internationalization data:

[Internationalization]
+CulturesToStage=en

By default, UE5 includes internationalization data for all supported cultures. If your game only supports English, or English plus a few specific languages, specifying only those cultures saves 15-30MB of ICU data.

Disable cooking of development-only assets:

[/Script/UnrealEd.ProjectPackagingSettings]
bCookAll=False
bCookMapsOnly=False

Setting bCookAll=False ensures only referenced assets are cooked. Setting bCookMapsOnly=False ensures the cooker follows references from maps rather than just cooking map files.

Exclude specific directories:

[/Script/UnrealEd.ProjectPackagingSettings]
+DirectoriesToNeverCook=(Path="/Game/Test")
+DirectoriesToNeverCook=(Path="/Game/Prototypes")
+DirectoriesToNeverCook=(Path="/Game/DevAssets")

Platform-Specific Cook Profiles

UE5.7 supports cook profiles that override settings per platform. In your platform-specific engine configs:

; DefaultEngine_Windows.ini
[/Script/UnrealEd.ProjectPackagingSettings]
bCompressed=True
bShareMaterialShaderCode=True
bSharedMaterialNativeLibraries=True

Sharing material shader code across assets that use the same shaders can save 10-30% of shader storage. This is one of the most impactful settings.

Step 4: Texture Compression and Optimization

Textures are usually the largest category of content in a shipping build. Optimizing them provides the biggest absolute savings.

Texture Format Selection

UE5 supports multiple compressed texture formats. Choosing the right one per texture type is critical:

BC7 (Default for color textures): Best quality for color data. 8 bits per pixel compressed. This is the default and usually correct for color/albedo textures.

BC5 (Normal maps): Two-channel compression optimized for normal maps. 8 bits per pixel. Make sure your normal maps use this — the engine should set it automatically, but verify.

BC4 (Grayscale): Single-channel compression for masks, roughness maps, AO maps. 4 bits per pixel — half the size of BC7 for textures that only need one channel.

BC1/DXT1 (Low quality color): 4 bits per pixel. Acceptable for distant textures, skyboxes, or textures where quality loss is not noticeable. Half the size of BC7.

ASTC (Mobile/Console): Required for Android and used on some console platforms. Variable block size — ASTC 4x4 is highest quality (8 bpp), ASTC 12x12 is lowest quality (~0.89 bpp).

Texture Size Reduction

Most projects have textures larger than they need to be:

Max texture size per LOD group: In Project Settings > Engine > Rendering > Textures, set max texture sizes:

• World textures: 2048 (rarely need 4096 unless it is a hero asset viewed up close)
• Character textures: 2048 for player character, 1024 for NPCs
• UI textures: Match resolution needs (often 512-1024)
• Effects textures: 512-1024

Per-texture max size override: For specific textures, open the texture asset and set the Maximum Texture Size property. A rock texture used for a small pebble does not need to be 4096x4096.

Mipmap stripping: For mobile or storage-constrained platforms, you can strip the top N mip levels. Stripping the top 2 mips of all textures (4096 becomes 1024) saves approximately 75% of texture storage but reduces visual quality at close range.

Texture streaming pool: Configure the texture streaming pool size to limit runtime memory. This doesn't directly reduce build size but ensures the engine loads appropriate mip levels.

Virtual Textures

If your project uses Runtime Virtual Texturing (RVT), the virtual texture tiles are generated at runtime and don't contribute to build size. Converting terrain and landscape materials to use RVT can reduce the number of stored textures significantly.

Texture Audit

For a comprehensive audit, list all textures sorted by size:

1. Open the Size Map (Window > Developer Tools > Size Map)
2. Filter to Texture2D assets
3. Sort by disk size
4. Review the top 20-30 textures — these likely account for 50%+ of texture storage

Common findings:

• Lightmap textures at unnecessary resolution (reduce lightmap resolution on BSP and static meshes)
• 4096x4096 textures on small props
• Uncompressed textures that should be compressed (check the Compression Settings property)
• Duplicate textures (same image imported multiple times under different names)

Expected Savings

Texture optimization typically reduces total build size by 20-40%. For projects with many 4K textures, the savings can be even more dramatic.

Step 5: Audio Compression

Audio is often the second-largest content category, and many projects ship with poorly optimized audio.

Compression Format Selection

UE5 supports several audio compression methods through Sound Wave properties:

OGG Vorbis: Good general-purpose lossy compression. Quality settings from 0 (smallest, lowest quality) to 100 (largest, highest quality). Quality 40-60 is sufficient for most game audio. Compression ratio: roughly 10:1 to 15:1 at quality 50.

ADPCM: Lower compression ratio than Vorbis (roughly 4:1) but much cheaper to decode. Good for sounds that play frequently or on many channels simultaneously (footsteps, impacts, ambient loops).

Opus: Better compression efficiency than Vorbis at low bitrates. Good for voice/dialogue. Compression ratio: 15:1 to 25:1 at typical quality settings.

PCM (Uncompressed): No compression. Only use for very short sounds that need zero decode latency (UI clicks, frame-precise gameplay sounds). Every uncompressed sound at CD quality (44.1kHz, 16-bit, stereo) costs ~10MB per minute.

Audio Optimization Strategies

Convert stereo to mono where appropriate: Most sound effects don't need to be stereo. Footsteps, impacts, weapon sounds, UI sounds — these should all be mono. The 3D spatialization system handles positioning. Mono cuts file size in half compared to stereo.

Reduce sample rate: Not all audio needs 44.1kHz or 48kHz sampling. Ambient sounds and distant effects can often use 22kHz without noticeable quality loss. This cuts file size in half again.

Set compression quality per category:

• Music: Quality 60-80 (players notice music quality)
• Dialogue: Quality 40-60 (speech compresses well)
• Sound effects: Quality 30-50 (masked by gameplay)
• Ambience: Quality 30-40 (continuous, low-attention sounds)
• UI: ADPCM or low-quality Vorbis (short, simple sounds)

Sound Cue optimization: Sound Cues that reference many Sound Waves pull all those waves into the build. If a Sound Cue randomly selects from 20 variations but you only need 10, the extra 10 are still cooked.

Streaming vs loading: Large audio files (music, long ambient loops) should be set to streaming. This doesn't reduce build size directly but reduces the amount of data that needs to be loaded into memory simultaneously.

Expected Savings

Audio optimization typically saves 5-15% of total build size. Projects with extensive voice acting or high-quality music tracks see larger savings.

Step 6: Shader Permutation Reduction

Shaders are compiled into platform-specific bytecode and stored in the build. Every unique material, every feature toggle, and every quality level multiplies the number of shader permutations.

Understanding Shader Permutations

A single material might compile into dozens or hundreds of shader permutations:

• Static lighting path vs dynamic lighting path
• With vs without fog
• With vs without atmospheric scattering
• Per quality level (Low, Medium, High, Epic, Cinematic)
• Per mesh type (static mesh, skeletal mesh, instanced static mesh, Nanite)
• With vs without virtual texturing
• Forward vs deferred rendering path

The total permutation count is the product of all these toggles. A material with 8 binary options generates 2^8 = 256 permutations. Multiply by the number of unique materials in your project.

Reducing Permutations

Share materials: Material Instances that reference the same parent Material share shader code. Using Material Instances extensively (instead of unique Material assets) dramatically reduces unique shader count.

; DefaultEngine.ini
[/Script/UnrealEd.ProjectPackagingSettings]
bShareMaterialShaderCode=True

Disable unused shader features globally:

; DefaultEngine.ini
[/Script/Engine.RendererSettings]
r.AllowStaticLighting=False    ; If using fully dynamic lighting
r.SupportSkyAtmosphere=False   ; If not using sky atmosphere
r.ForwardShading=False          ; If not using forward rendering
r.Mobile.EnableStaticAndCSMShadowReceivers=False  ; If not targeting mobile

Each disabled feature eliminates an entire dimension of permutations.

Reduce quality levels: If you only support High and Epic quality, you can skip compiling shaders for Low and Medium:

[ShaderCompiler]
r.ShaderQuality.Low=0
r.ShaderQuality.Medium=0

Strip feature levels: If only targeting SM5 (Shader Model 5), disable compilation for SM6 and mobile shader models:

[/Script/WindowsTargetPlatform.WindowsTargetSettings]
DefaultGraphicsRHI=DefaultGraphicsRHI_DX12
-TargetedRHIs=SF_VULKAN_SM6

Shared Shader Libraries

Enable shared shader libraries to deduplicate shader bytecode across materials:

[/Script/UnrealEd.ProjectPackagingSettings]
bSharedMaterialNativeLibraries=True

This collects all shader permutations into a shared library file instead of embedding them per-asset. Deduplication alone can save 20-40% of shader storage.

Expected Savings

Shader optimization saves 10-30% of total build size, sometimes more. Projects with many unique materials and all features enabled see the largest savings.

Step 7: Stripping Debug and Development Content

Several categories of content are included by default but are only useful during development.

Debug Symbols

For shipping builds, debug symbols should be excluded from the distributed package:

[/Script/UnrealEd.ProjectPackagingSettings]
BuildConfiguration=Shipping
bIncludeDebugFiles=False

Debug symbols (.pdb on Windows, .dsym on Mac) can be 500MB-2GB+. Keep them archived separately for crash analysis but never distribute them.

Console Commands and Stat Rendering

The Shipping build configuration automatically strips console command access and stat rendering code, but verify:

[/Script/Engine.Engine]
bAllowConsoleInShipping=False

Development-Only Blueprints

If you have debug visualization Blueprints, cheat menus, or testing tools, ensure they are either:

• In directories listed in DirectoriesToNeverCook
• Wrapped in WITH_EDITOR or preprocessor guards (C++ only)
• Excluded via the asset manager's rules

Expected Savings

Stripping debug content saves 50MB-2GB depending on project size and whether debug symbols were previously included.

Step 8: Shipping Only Needed Blueprint Template Library Modules

The Blueprint Template Library includes 8 gameplay systems: health/combat, inventory/crafting, dialogue, quests, abilities/buffs, stats, saves, and interaction. Most games don't use all 8.

Modular Inclusion

The Blueprint Template Library is designed for modular use. Each system is a self-contained module with clearly defined dependencies:

• Health/Combat: Standalone, no dependencies on other modules
• Inventory/Crafting: Standalone
• Dialogue: Depends on Save module (for tracking dialogue state)
• Quests: Depends on Save module (for quest progress persistence)
• Abilities/Buffs: Depends on Stats module (for stat modifications)
• Stats: Standalone
• Saves: Standalone (core serialization)
• Interaction: Standalone

If your game only uses Health/Combat and Inventory/Crafting, you can exclude the other 6 modules entirely.

Exclusion Methods

Directory exclusion: Add unused module directories to DirectoriesToNeverCook:

[/Script/UnrealEd.ProjectPackagingSettings]
+DirectoriesToNeverCook=(Path="/Game/BlueprintTemplateLibrary/Dialogue")
+DirectoriesToNeverCook=(Path="/Game/BlueprintTemplateLibrary/Quests")
+DirectoriesToNeverCook=(Path="/Game/BlueprintTemplateLibrary/Abilities")

Reference removal: If you never reference the unused modules from any of your game assets, the cooker will automatically exclude them (assuming bCookAll=False). But it's worth explicitly adding directory exclusions as a safety net.

Selective migration: For maximum control, only migrate the specific modules you need into your project from the Library. This guarantees no unused code or assets are present.

Size Impact

Each Blueprint Template Library module is lightweight (the entire library is under 15MB), but the principle matters for all third-party code libraries. Every included-but-unused module adds to cook time, package size, and cognitive overhead.

Step 9: PAK File Chunking for DLC

If your game will have downloadable content, PAK file chunking lets you split your build into a base package and additional chunks that can be downloaded separately.

Setting Up Chunks

UE5 uses the Primary Asset Labels system for chunk assignment:

1. Create Primary Asset Label assets in your Content directory
2. Assign assets to specific chunk IDs (0 = base game, 1+ = DLC chunks)
3. Configure the Asset Manager to respect chunk assignments

; DefaultEngine.ini
[/Script/Engine.StreamingSettings]
s.UseBackgroundLevelStreaming=True
s.AsyncLoadingTimeLimit=5.0

Chunk Strategy

• Chunk 0: Core game content — main menus, core gameplay assets, shared materials and textures
• Chunk 1: Main campaign levels
• Chunk 2: Side content (optional areas, bonus levels)
• Chunk 3+: DLC content packs

Each chunk becomes a separate .pak file. The game only needs Chunk 0 to start; other chunks download or install as needed.

Chunk Size Considerations

Steam recommends keeping individual download chunks under 2GB for reliable downloading. The Nintendo eShop has a 4GB initial download limit for "play while downloading" functionality. Plan chunk sizes around these platform limits.

Patching and Chunk Updates

When you update your game, only modified chunks need to be re-downloaded. This means chunk boundaries should be stable — don't reorganize chunks between patches, or players will need to re-download everything.

Step 10: Platform-Specific Packaging

Different platforms have different constraints and optimization opportunities.

Windows/PC

The most forgiving platform in terms of storage:

• Ship with compression enabled (bCompressed=True)
• Include all quality levels (players have diverse hardware)
• Consider offering a "high-res texture pack" as optional DLC for 4K textures
• Target build size: 2-10GB for indie, 20-50GB for larger projects

Steam Deck

The Steam Deck's storage situation:

• Base model: 64GB eMMC (effectively ~40GB after OS)
• 256GB and 512GB NVMe models are more common now but still smaller than desktop SSDs
• MicroSD card expansion (slower, players prefer internal storage)

Steam Deck optimizations:

• Aggressive texture compression (BC1 instead of BC7 where acceptable)
• Strip top mip levels (most textures don't need 4K on a 1280x800 screen)
• Lower audio quality (the built-in speakers and most headphones don't resolve high-bitrate differences)
• Consider a separate "Deck-optimized" build that strips ultra-quality assets

; DefaultEngine_SteamDeck.ini (custom platform profile)
[/Script/Engine.RendererSettings]
r.DefaultFeature.AntiAliasing=2       ; FXAA instead of TSR
r.MaxAnisotropy=4                      ; Reduced anisotropic filtering
r.Streaming.PoolSize=512              ; Reduced texture streaming pool

Console Platforms

PlayStation and Xbox have specific packaging requirements:

• Mandatory encryption for PAK files
• Specific compression requirements (platform SDKs provide details under NDA)
• Download size limits for digital storefronts
• "Play as you download" requirements affect chunk organization

Mobile (Android/iOS)

The most constrained platform:

• Google Play has a 150MB APK limit (with expansion files for additional data)
• Apple App Store allows up to 4GB but warns users about downloads over 200MB on cellular
• Use ASTC texture compression (mandatory on modern mobile GPUs)
• Aggressive mip stripping (mobile screens are small)
• Mono audio only
• Minimum shader quality levels
• Target: under 1GB total, ideally under 500MB

Build Size Before and After: A Real Example

Here is a realistic example of applying all these optimizations to a mid-sized indie project:

Starting Point

A third-person action RPG, 6 months into development:

After Optimization

That is a 43% reduction. With more aggressive texture compression (acceptable for stylized games), you could push this to 50-55%.

The "Nano" Template Approach

For very small projects (game jams, prototypes, minimal releases), consider starting from a stripped-down project template:

1. Create a new Blank project (not Third Person or other templates)
2. Disable every plugin except what you need
3. Set bSkipEditorContent=True from the start
4. Configure texture limits from the start
5. Use DirectoriesToNeverCook for any test/prototype directories

A truly minimal UE5.7 project (no plugins, no editor content, no internationalization) can package under 80MB. This is your floor — everything above it is content you chose to include.

Building a Nano Template with MCP

The Unreal MCP Server can automate creating a Nano template:

• Disable all non-essential plugins in the .uproject file
• Configure DefaultEngine.ini with optimized cooking settings
• Set up DefaultGame.ini with appropriate packaging defaults
• Create the directory exclusion rules
• Validate the configuration by checking for common issues (like accidentally disabling a required plugin)

Save this as a project template and use it as the starting point for every new project. You will never need to retroactively optimize a project that was lean from the beginning.

Automating the Entire Process with MCP

Many of the optimization steps described above involve repetitive file scanning, configuration changes, and validation. The Unreal MCP Server can automate much of this pipeline:

Asset Audit Automation

• Scan all project assets and generate a size report sorted by category and individual asset size
• Identify unreferenced assets across the entire project
• Find duplicate assets (same source hash, different import paths)
• Detect textures that exceed recommended size limits for their usage context
• Flag audio files that are stereo when mono would suffice

Configuration Automation

• Review current DefaultEngine.ini settings and suggest optimizations
• Apply cooking settings across all platform configs consistently
• Verify that DirectoriesToNeverCook entries match actual directory paths
• Check plugin enable/disable state against project references

Validation Automation

• After optimizations, verify the project still cooks without errors
• Compare build sizes before and after optimization passes
• Detect any new unreferenced assets introduced by recent content additions (useful as a CI step)

This transforms build optimization from a manual, error-prone checklist into a repeatable, automated process.

Common Packaging Mistakes

Mistake 1: "Additional Directories to Cook" Set to Root

If AdditionalDirectoriesToCook includes /Game/, every asset in your project cooks regardless of references. This should usually be empty or contain only specific directories with assets loaded dynamically at runtime (like data tables loaded by string path).

Mistake 2: Never Testing Packaging Until Ship Day

Package your game early and often. A weekly packaging build catches size regressions when they are introduced, not six months later when you have no idea which of 500 commits caused the problem.

Mistake 3: Including Marketplace Example Content

Most Marketplace assets include example maps, demo Blueprints, and documentation assets. These are useful during evaluation but should be excluded from shipping builds. Move example content to directories listed in DirectoriesToNeverCook.

Mistake 4: Uncompressed Audio Mastering

Some audio middleware (Wwise, FMOD) handles compression internally. If you are using one of these, ensure UE5 isn't also applying compression (double-encoding degrades quality) or, conversely, that UE5 isn't storing the audio uncompressed when the middleware expects to receive compressed data.

Mistake 5: Not Using Shipping Configuration

The Development and DebugGame build configurations include console command support, stat rendering, and other debugging features that add size and reduce performance. Always use the Shipping configuration for final builds.

Mistake 6: Ignoring Derived Data Cache

The DDC (Derived Data Cache) is not included in packages, but a corrupted DDC can cause the cooker to skip assets or include stale data. If you see unexpected packaging results, clear the DDC: delete the DerivedDataCache folder and recook.

Monitoring Build Size Over Time

The best optimization is prevention. Set up monitoring to track build size trends:

CI/CD Integration

Add a packaging step to your CI/CD pipeline that:

1. Builds the project in Shipping configuration
2. Records the total package size and per-category breakdown
3. Compares against the previous build
4. Alerts if size increased by more than a configurable threshold (we use 5%)

Budget Allocation

Set a build size budget at the start of the project:

Review against the budget monthly. When a category exceeds its budget, that team reviews and optimizes before adding more content.

Asset Size Gates

Consider adding size checks to your content pipeline:

• Textures over 2048x2048 require lead approval
• Audio files over 30 seconds must use streaming
• Individual assets over 50MB require justification

These gates prevent the slow accumulation of oversized assets that leads to bloated builds.

Conclusion

UE5's default packaging behavior prioritizes convenience over efficiency. It enables many plugins by default, cooks broadly rather than narrowly, and uses conservative compression settings. This makes sense for development — you want things to Just Work while you are iterating. But it produces shipping builds that are 2-3x larger than necessary.

The optimization process is systematic and largely automatable. Plugin audit, asset reference scanning, compression configuration, shader permutation reduction, and platform-specific settings each contribute a meaningful percentage of size reduction. Applied together, cutting your build size by 40-60% is realistic for most projects.

Start by packaging your project today, even if it is months from release. Know your current size. Set a budget. Use the Unreal MCP Server to automate the scanning and configuration work. Configure Blueprint Template Library modules for selective inclusion from the beginning. And package regularly — catching a 200MB size regression the week it is introduced is far easier than hunting for 2GB of waste six months later.

Your players' hard drives will thank you. And on Steam Deck, where every gigabyte matters, a lean build is not just polite — it is a competitive advantage.