Desktop, Web & Mobile Exports

Publishing puts your game on a server. Exporting turns it into a product players install — branded as yours, with your name, icon and colors, pointed at whichever server you choose.

Open Build → Export Game in the studio. The modal opens with a readiness overview: what you can build right now, what each target will produce, and what's missing (a signing key, a server URL, an icon) before it will succeed. Every export runs pre-flight validation first, so failures are explained up front instead of thirty minutes into a build.

Targets#

The Server target#

Every other target produces something a player installs or opens. Server produces the other half: the authoritative game server, ready to deploy.

You need it only if you run your own box. If your profile points at an ED5-hosted server, that server is managed for you and the target says so instead of building something you'd never use. When your profile points anywhere else, the build screen flags that you'll need this export too — it's the half players can't download.

What comes out is a server-bundle/ folder with the server and its dependencies already built, the database migrations, a .env.example prefilled from your profile, and a README.md carrying the deploy commands. Upload it, pnpm install --prod, fill in .env, run it. Full walkthrough: Self-Hosting on a VPS.

Left out on purpose: node_modules (a Windows install can't run on Linux), the admin app (authoring tools never belong on a public server), your local database, and the demo art packs. Pre-flight refuses to build an engine missing its compiled server or its migration SQL — both would produce a bundle that starts perfectly and then acts as if your database were empty.

Making a single-player game#

The engine is server-authoritative — the client asks, the server decides — and that doesn't relax for one player. There is always a game server. The only question is whose machine it runs on.

Tick Run the game server on the player's machine on a Windows, macOS or Linux export and the installer carries the server and your world inside it. The game then needs no host, no account and no internet.

That makes it a genuinely different product, so choose deliberately:

It is not a "multiplayer off" switch — it is one world per player, and they can never meet. For a solo game that is exactly right. For a shared one it is the opposite of what you want.

What ships, and what happens on first launch#

The export puts the built server, its dependencies and a copy of the open project's world into the installer. The first time a player opens the game, the world is copied into their own save folder and the server starts against that copy; every launch after that reuses it.

A later export never overwrites a save. Players keep their progress across updates — which is also why new content does not reach an existing save the way publishing reaches a hosted server.

Before you ship one#

• Open the project you want to ship. The export takes the world from the currently open project, and refuses to build without one rather than shipping an empty game.
• Expect a much larger installer. You are shipping a database and a server, not just a client — a few hundred MB on top, and more if your world is large.
• The server URL is ignored. Nothing is baked in, because the address isn't known until the player's own server picks a free port.
• Your private settings are cleared from the copy that ships. The installer carries a copy of your project's database, so the export blanks the secret values from Settings (payment, auth and Steam keys) and removes the email addresses and passwords of any local accounts in that copy. Your own project is never touched. If the build log warns that it could not do this, treat that installer as containing them.
• Set an Update URL. It is the only way a fix reaches players who already installed.

Branding#

• Identity — game name, publisher, copyright line, application/bundle id and version. Everything a player or their operating system can read off the game comes from these (below)
• App icon — one image brands every export; without one, each build gets a default icon made from your game's name (below)
• Splash — mobile splash art and its background color
• Orientation — mobile exports apply the orientation you configured (portrait, landscape, or free)
• Game links — the Android export writes a link scheme (your app id) and your play host into the app, so a link opens the installed game on its join page — see Phone & Tablet Play
• Web install — hosted games install as themselves: the play page serves a per-project web manifest with your name, accent color and logo, so an installed shortcut is your game, not the engine

Your name on the game#

An exported game says it is yours everywhere a player or their computer looks: the window title, the taskbar, the installer, the list of installed apps, the file's Properties dialog. All of it is taken from your project's export settings. Nothing in a build names the engine unless you type it.

Where to author it: Build → Export Game → Config → Game Info (and App ID under App Identity & Mobile).

1. Open Build → Export Game and switch to the Config tab.
2. Under Game Info, fill in Game Name and Version.
3. Fill in Publisher with your studio's name, or your own.
4. Optionally fill in Copyright. Leave it blank for the standard line.
5. Click Save Config, then export. The build log has one line that starts Branding: and lists the name, version, app id, publisher and copyright line the build was packaged with.

What each part of an installed desktop game shows, and where it comes from:

Gotchas:

• Leave a field blank and the build falls back to the game's own name, never ours. A project with nothing filled in ships as "My MMO", version 0.1.0, published by "My MMO".
• An empty Version no longer ships the engine's version number. It used to; now it is 0.1.0, and pre-flight warns you. If you ever released a build with the Version field empty, set a version higher than that build's before your next release: an installed game only updates to a higher version, and 0.1.0 is lower than the number those builds carried.
• A version that is not numbers gets a warning. Something like Beta 3 or v1.2 is left as you typed it, and pre-flight warns: Windows packaging refuses a version that does not start with numbers, and a game that updates itself cannot tell which of two such versions is newer. Use three numbers; add a label after a hyphen if you want one (1.0.0-beta.3).
• Line breaks are flattened. Each of these is one line; a pasted line break becomes a space.
• Linux packages must name a website. A Linux build takes it from the Client URL of the profile you build. With no web address at all, pre-flight warns and the package lists https://<game-name>.invalid/, a placeholder that leads nowhere. Windows and macOS builds name no website.
• Changing the Game Name changes the install folder. Players who installed under the old name get a second install rather than an update. Pick the name before your first release.
• Android and iOS take the app's name from the same Game Name field. Publisher and Copyright apply to the desktop targets only.
• There is no feature flag — this applies to every export.

Your app icon#

One image becomes the icon everywhere your game is installed. Set it once and every target picks it up.

Where to author it: Build → Export Game → Config → App Icon.

1. Prepare a square PNG, 512×512 or larger. One file covers all platforms — the export converts it to each platform's native format for you.
2. Open Build → Export Game and switch to the Config tab.
3. Under Game Info, click Browse next to App Icon and choose your file.
4. Click Save Config, then export. The build log names the icon it staged.

Where it shows up:

The default icon. A game with no icon does not borrow ours. Each build makes one for it: a plain colour tile with the first letter (or digit) of the game's name, in a colour picked from the name, so two of your games are easy to tell apart. A name with no Latin letter or digit gets the tile with a plain diamond. Build → Export Game tells you before you build (No app icon set — this build will use a default icon instead: a plain colour tile with the letter "D") and the build log says it again, with where to set your own.

Gotchas:

• Under 512×512 is refused for desktop. Pre-flight warns and the build uses the default icon rather than shipping a blurry one. The web target is more forgiving — but under 192×192, browsers won't offer to install your game at all.
• Non-square art is rejected. Icons are square everywhere; crop before you import.
• PNG is the format to use. .ico and .icns are accepted, but each only applies to its own platform — an .ico brands Windows and leaves macOS and Linux on the default icon.
• An .ico must contain a 256×256 frame. Windows packaging refuses one that doesn't, and most hand-made .ico files stop at 48 or 64. If yours does, the build says so and uses the default icon instead. A single 512×512 PNG avoids the whole question — the build generates every size it needs from it.
• No icon is a warning, never an error. Every export still completes; it ships with the default icon (the letter tile), and both the Build window and the build log say so. An icon can cost you your branding, never your build.
• Web exports get the default icon too. A web bundle built with no usable icon used to keep the engine's logo as its installed-app icon; it now carries your game's letter tile.
• Hosted games are separate. A game played in the browser on its play link takes its installed-app icon from your loading screen logo in the UI & HUD editor, not from this field — that one reaches players without re-exporting.

Server Profiles#

An exported build has to know where to connect. Use my hosted project fills the URLs in for you from your account: it resolves your project's stable play URL and its game-server address, and stamps when it was resolved so you can tell when a profile has gone stale. You can also point a build at any self-hosted server by entering the URLs yourself.

Signing#

Gotcha — which platforms you can build from where:

Build	From Windows	From macOS	From Linux
Windows installer (.exe) + zip	Yes	—	—
macOS .dmg + zip (Apple Silicon and Intel)	No	Yes	No
Linux AppImage + .deb	—	—	Yes

A macOS build is signed only when you fill Signing → macOS identity; without it players must right-click the app → Open the first time. Add your Apple ID, app-specific password and Team ID and turn on Notarize to remove that step entirely.

Distribution#

The play page can show a Get the game section: a browser install prompt (or "Add to Home Screen" hint on iOS) plus download buttons for your desktop installers, pulled from your public releases. It's off unless you configure it, so an unconfigured game just joins straight into play.

Shipping on Steam instead of (or as well as) your own downloads? See Publishing on Steam.

Each desktop game installs under its own name, in its own folder, with its own entry in Add/Remove Programs — so a player can keep several of your games (or several games built with the studio) installed side by side without one replacing another. The folder name comes from your game name, so renaming a game between releases makes the next installer land in a new folder rather than upgrading the old one.

Updating a Game People Already Installed#

Most changes never need a new installer. What you change decides what players have to do:

Turning on auto-updates#

1. In Build → Export Game → Config, set Update URL on the profile you ship, to a folder you control — for example https://releases.yourgame.com/win/. Leave it blank and the game simply has no update channel.
2. Export. Alongside the installer you now also get latest.yml and a .blockmap file.
3. Upload all three — latest.yml, the installer, and the .blockmap — into that folder, replacing what's there.
4. For the next release, raise Game version before exporting, then repeat.

Installed games check that folder on launch, download a newer version in the background, and install it when the player quits. The .blockmap is what lets them download only the parts that actually changed instead of the whole installer again.

The version is what triggers it. Auto-update compares the version in latest.yml against the installed one, so a build you forgot to bump will never be offered — even if everything inside it changed.

Missing latest.yml is the one failure that hides: an installed game just quietly never updates. Exports fail loudly if you set an Update URL and the feed file doesn't get produced, so you can't ship that state by accident.

Exports are cached by content fingerprint. Re-exporting after changing only your branding skips the long client build entirely, so the second export is minutes rather than tens of minutes.

App Store note: a mobile build that only wraps a remote URL can be rejected under App Store rule 4.2 ("repackaged website"). Bundling your game's assets into the app is the mitigation, and the export flow surfaces this before you submit.