Start Building

Lesson Goal

Lesson 12 tuned performance in the editor. Exports apply different compilers, stripping, and (for web) download size rules. Small oversights become “it works in editor, crashes on launch.”

By the end of this lesson, you will:

  • install export templates that match your exact Godot patch version
  • create export presets for at least one desktop target and Web
  • set application name, version, and icon in a repeatable way
  • run a smoke test checklist on a packaged build and fix common HTML5 pitfalls

Step 1: Match editor version to export templates

  1. Note your version: Help → About (e.g. 4.x.y).
  2. Open Editor → Manage Export Templates and download templates for that same 4.x.y. Mismatched templates cause opaque export failures.
  3. If you are offline or pinned to a custom build, point Export → Install from file at the matching TPZ your team hosts in README or CI.

Rule: Bump Godot → re-download templates before shipping a milestone build.

Step 2: Project application identity

Configure once, inherited by all presets unless overridden:

  1. Project → Project Settings → Application → Config
    • Name — player-facing title (window title, OS menus).
    • Version — semantic version your players see in “About” dialogs where the OS exposes it.
  2. Application → Run
    • Main Scene must be your ship candidate (menu flow from Lesson 10).

Optional but professional: mirror the version in an autoload or credits label so QA and Lesson 11 save headers stay honest about save compatibility.

Step 3: Desktop export presets (Windows / Linux / macOS)

  1. Project → Export → Add… and pick a platform.
  2. Name presets clearly, e.g. Windows Release, Linux Steamdeck sanity, macOS unsigned dev.
  3. Set Runnable on the preset you use for day-to-day test builds (only one runnable per platform in typical flows).
  4. Release vs debug template: use release for builds you give to friends; use debug when you need readable stack traces during first porting work.
  5. Embed PCK (or not): embedding simplifies distribution of a single binary; keeping PCK external helps some mod or patch workflows. Pick one policy per SKU and document it.

Smoke test (desktop): launch exported binary on a clean user account (or fresh folder), start a new game, fight one encounter, open inventory, save/quit, relaunch, load. Compare to editor behavior.

Step 4: Icons and metadata

  1. Project Settings → Application → Config → Icon — default project icon (square PNG; higher resolution is safer for OS scaling).
  2. Per-preset Icons section (where available): Windows .ico, macOS icns if you package that way—prepare assets in your art pipeline, not minutes before a milestone.
  3. High-DPI / per-monitor quirks: test windowed and fullscreen on your worst monitor.

Step 5: Web export — size, threads, and feature tags

Godot’s HTML5 export is powerful but picky.

  1. Enable Export → Web preset. First export may warn about threads, GDExtension, or unsupported modules—read the dialog; it is telling you what the browser will refuse.
  2. Features / variant: disabling unused 3D, VR, or heavy modules trims WASM and load time. For this 2D action course track, prefer a smaller feature surface until you prove you need more.
  3. Godot 4 Web often benefits from hosting that sends correct MIME types and COOP/COEP headers when using threads—test on real static hosting (Netlify, GitHub Pages, your CDN), not only file://.
  4. Path to Godot Game in the generated HTML: keep relative paths if you deploy in a subfolder; broken paths are the top “black screen” cause.

Smoke test (web): cold load in Chrome and one second browser, open devtools console (no red errors), complete one loop of movement + UI.

Step 6: Packaging layout for your slice

For jams and internal QA:

Output Suggestion
Windows .zip Executable + .pck if external; ship Visual C++ runtime note in README if you link dynamically.
Linux tarball Mark executable bit; mention distro baseline.
Web folder index.html, .wasm, .pck, .js (+ worker files if any)—upload the whole bundle.

Add a one-page BUILD_NOTES.md: Godot version, preset names, date, known issues from Lesson 12 monitoring.

FAQ

Do I need code signing on day one?
No for learning builds; yes before Steam or broad Windows distribution. Unsigned Gatekeeper friction on macOS is real plan early if you target Mac players.

Why does my export differ from editor FPS?
Release builds optimize; debug builds trace. Re-run your Lesson 12 monitor pass on the exported binary, not only in-editor.

Can I skip web if I only ship desktop?
Yes—omit the HTML5 preset until you need a demo. Keep the skill; Itch.io and demo discs love a browser build.

Mini challenge

  1. Create three presets: Windows release, Linux release, and Web release (even if you only ship one—practice).
  2. Bump Config Version, export, and confirm the value appears in your credits or debug overlay.
  3. Host the web folder locally with a tiny static server (any tool you like) and verify load stays under a target you write down (e.g. “first interactive frame under 10s on cable”).

Summary

  • Templates must match engine patch.
  • Presets encode platform, debug/release, and runnable defaults.
  • Identity (name, version, icon) belongs in Project Settings plus export overrides where needed.
  • Web demands trimmed features, correct hosting, and console-clean smoke tests.
  • Always run the slice on a packaged build after your Lesson 12 perf habits.

Next you will formalize QA, known issues, and release notes. Continue to Lesson 14: QA Pass and Release Prep.

Random Illustrations artwork by Dribbble artist