Reducing build size while retaining required features
Measurement, feature profiles, modules, renderers and exported-game checks.
Reduce an export template relative to a working baseline. First distinguish executable, managed runtime, PCK/assets and download-archive sizes: optimizing one does not necessarily reduce the others or memory use.
Measurable workflow
- Fix the same platform, architecture, project and release settings. Record each baseline artifact’s size.
- Change one option or profile. Record compilation and link time.
- Export with the new template. Check startup, every level, dynamically loaded resources, UI, localization, saves and required platform features.
- Compare sizes and behavior. On failure return to the last working configuration rather than disabling another random subsystem.
Savings depend on the project and toolchain. Figures such as “15% smaller without 3D” are not a promise for your build.
Code optimization and symbols
optimize=size/size_extra selects compiler size optimization. Check support and actual results for your compiler; a smaller binary does not guarantee higher FPS or faster startup.
LTO can change size and linking time, but lto=auto is platform-selected. production=yes does not mean LTO is necessarily active. Keep symbols separately when supported: they are needed to diagnose crashes. Shrinking shipped files is not a reason to lose crash diagnosis for your version.
Feature profiles
build_profile selects a JSON build profile. disabled_classes lists disabled classes; disabled_build_options changes build options. This differs from profile=... selecting a Python file of ordinary options.
Automatic used-class detection can start a profile but does not prove completeness. Check dynamic loading, string-based class names, plugins, external packs and content absent during analysis. Disabling a class can remove required derived capabilities; validate the profile against the entire exported game.
Remove features according to the project
| Group | Check before disabling |
|---|---|
| 3D | 3D levels/resources, physics, navigation and XR; disable_3d also enables related disables |
| 2D | Entity2D, 2D physics/navigation; this is not the same as removing every interface |
| Advanced GUI | Actual complex Controls, dialogs, menus, formatted text and editor tools |
| Physics/navigation | Required servers and selected backend; visual 3D does not imply every physics backend is used |
| Formats/modules | Import, runtime decoding, networking, archives, audio, video, extensions and dependencies |
| Renderers | Project rendering method, fallback and target-device capabilities |
| TextServer | Fonts, shaping, line breaking, direction and every UI language |
disable_2d, disable_3d, disable_advanced_gui and the listed individual physics/navigation disables are template options: current SConstruct rejects them for target=editor. A stripped game template does not replace an editor.
Disabling text_server_adv does not automatically enable text_server_fb: the fallback module is off by default. Retain a suitable TextServer and check required languages; do not assume fallback duplicates every advanced feature.
For C# projects retain a consistent mono module, managed SDK and runtime. Measure them separately from the native EXE. Broad modules_enabled_by_default=no can remove a required format or integration even when compilation succeeds.
Distribution
Archive or HTTP compression can reduce transferred bytes without reducing installed size, memory or decoding time. Web delivery needs correct server MIME/Content-Encoding configuration; renaming a compressed file does not replace a browser check.
This article was checked against current Source options and dependencies. No stripped engine/game was built here; no size savings or every-project acceptance is established. Apply the criteria above before adopting your own configuration.
Continue with SCons and profiles, exporting.