Build your game as a desktop app, a deployable web bundle, or an Android/iOS app.
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
| Target | Artifact | Notes |
|---|---|---|
| Windows / macOS / Linux | A branded desktop app | The game client is bundled inside — it launches and serves locally, falling back to your hosted client if anything goes wrong |
| Web | A deployable bundle | A self-contained server bundle with a Dockerfile, README and config — deploy it anywhere, not just our hosting |
| Android | A real .apk or .aab | Built through a checked-in native shell; your application id and app name are patched in |
| iOS | A configured Xcode project, or a signed .ipa | Requires a Mac — the target refuses cleanly elsewhere with instructions |
| Server | A deployable game-server folder | The one target players never touch — it's what you upload to a VPS. Only needed if you host the game yourself |
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:
| Hosted (default) | On the player's machine | |
|---|---|---|
| Who runs the server | You, or ED5 | Each player, invisibly |
| The world | One world, shared | A private copy per player |
| Internet | Required | Never |
| Content updates | Publish, live on reconnect | Only via a new installer |
| Right for | An MMO, a co-op world, anything social | A single-player game |
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.
- Set an Update URL. It is the only way a fix reaches players who already installed.
Branding
- Identity — game name, application/bundle id, version
- App icon — one image brands every export (below)
- Splash — mobile splash art and its background color
- Orientation — mobile exports apply the orientation you configured (portrait, landscape, or free)
- 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 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.
| Field | What it does |
|---|---|
| App Icon | The image used as your game's icon. Browse opens a file picker; you can also paste a full path. Clear goes back to the ED5 icon. |
| Splash Image | Mobile only — the art shown while the app starts. |
Where it shows up:
| Target | Where players see it |
|---|---|
| Windows | Installer, the .exe, the taskbar, Add/Remove Programs |
| macOS | The app bundle, the Dock, the DMG |
| Linux | The AppImage and .deb, and the desktop menu entry |
| Android / iOS | The launcher / home-screen icon, generated at every density |
| Web | The icon a player gets when they install your game from the browser |
Gotchas:
- Under 512×512 is refused for desktop. Pre-flight warns and the build falls back to the ED5 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.
.icoand.icnsare accepted, but each only applies to its own platform — an.icobrands Windows and leaves macOS and Linux on the ED5 icon. - No icon is a warning, never an error. Every export still completes; it just ships with the ED5 icon, and the build log says so.
- 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
| Platform | What you provide |
|---|---|
| Windows / macOS | Code-signing certificate details (optional for local testing) |
| Android | A keystore for release builds; debug builds need nothing |
| iOS | Your Apple Developer Team ID for a signed archive |
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.
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:
| You changed | What players do |
|---|---|
| World content — zones, items, NPCs, quests, abilities, art | Nothing. Publish, and it's live on the next reconnect. Your world is served by the game server, not baked into the download. |
| Engine / game-server version | Nothing. A managed server rolls onto the new build by itself, and waits until nobody is playing so no one is dropped mid-session. |
| The game client — the part that draws your world | Nothing. The launcher keeps it current on its own. See The Game Launcher. |
| The launcher app itself | A new build has to reach them. Turn on auto-updates below, or they reinstall by hand. |
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.