Appearance
Exporting a standalone build
Besides publishing to the Galatrix servers for multiplayer, you can export your map as a standalone build — a self-contained game you can host anywhere or open in a browser. Think of it as a local build: it runs your scene with the same engine and the same scripts, just single-player and offline rather than networked.
Build it
From the editor's top menu choose Map → Build Standalone. A dialog collects the options:
| Option | What it does |
|---|---|
| Game Name | The title shown on the start screen and used for the downloaded file. |
| Format | Single HTML — one self-contained .html file with Three.js, Rapier, the engine, and your scene all embedded inline. No external dependencies; opens directly in any browser, even offline. ZIP Bundle — the same game split into separate files (index.html + standalone.js + scene.json). Also fully self-contained, but it needs a local static server to run (e.g. npx serve .), because a browser won't fetch the side files over file://. |
| Shadow Quality | Low / Medium / High shadow map resolution. |
| Show player avatar | Render the capsule character (turn off for first-person or fully scripted players). |
| Compress scene data | Gzip the embedded scene; the build decompresses it in the browser at load. |
| Compress dependencies | Gzip the embedded Three.js + Rapier bundle (~8 MB → ~1.5 MB), decompressed in the browser at load. |
| Minify | Off by default. Single HTML: compacts the page itself (comments and whitespace stripped) along with your script sources. ZIP: minifies script sources and writes scene.json compact instead of pretty-printed — index.html stays readable so you can still open and tweak it. Scripts keep every name; nothing is renamed. |
| Engine modules | Leave optional engine subsystems out of the export to shrink it (see below). |
| Render API | Which graphics API the exported game draws with (see below). |
Click Build and the file downloads.
Render API
Browsers offer two graphics APIs, and an exported game embeds the engine built for the one you pick:
| Setting | What it does |
|---|---|
| Automatic | The default, and it builds a WebGL 2 game. On the kind of scenes made here — many separate objects rather than a few large ones — WebGL 2 measured faster, so an export that expresses no preference gets it. |
| WebGL 2 | Always WebGL 2. The conservative choice, and the one that keeps GLSL-only shaders working. |
| WebGPU | Asks for WebGPU specifically. Because it is a choice rather than a result, it is loud when it cannot be honoured: pick it and the dialog lists what would pin your game to WebGL 2, and the build log repeats it. Where a player's browser has no WebGPU, the game still starts on a compatibility layer. |
One thing decides whether a game can draw on WebGPU: whether its custom shaders have a WebGPU version. A game with no custom shaders, or whose shaders all carry one, is drawable on either API. A game with a shader that is GLSL only is a WebGL 2 game, and picking WebGPU for it resolves back to WebGL 2 rather than shipping something that cannot compile — the dialog and the build log both say so.
Nothing else about your game changes with this setting — the same scene, scripts, physics and audio run either way.
Engine modules
The engine ships a few optional subsystems that a given game may not use. Under Engine modules in the Build dialog you can leave the ones you don't need out of the export:
- Terrain renderer and Tilemap renderer are auto-detected. The editor scans your main map and every sub-map; if none of them contain a terrain (or tilemap) object, that renderer is pre-checked to be stripped, so a game that never uses it simply doesn't ship it. If a map does use it, it's marked "used by this game" and left in.
- Particle system, Animator and math.geo / math.curve are marked advanced and left in by default. Each is reachable from scripts (
particles.*,animation.*,math.geo.*) as well as (for particles/animator) a component, so a scan can't prove a game never uses them — stripping them is an explicit opt-in rather than something the editor decides for you. Only strip one if you're sure your game never uses it.
Stripping is safe by construction: if you strip a module a map actually needs, the game fails loudly at load with a clear message — "The … engine module was stripped from this build. Re-enable it in Build ▸ Engine modules and re-export the game." — never a silent broken scene. It's a per-export choice; your editable project always keeps everything, so you can re-export with the module back in at any time.
In practice this trims a small slice off the download (a renderer is tens of KB against a multi-MB engine), so treat it as a nice-to-have for size-sensitive hosting rather than a big win.
Offline multiplayer room
One module works the other way round: it is off unless you ask for it, and it adds code rather than removing it. Offline multiplayer room ships the multiplayer runtime itself and runs it with no network: the same room code a published game's server runs, and the same client a player's browser runs, both in the one page, for one player. Turn it on for a map written for rooms that should also play alone exactly as it does online. Room-side hooks (onPlayerJoined, onClientEvent, players.getAll and the rest), client scripts, server-driven entities, spawn protection, sub-map hops through players.teleportToScene and per-player HUDs all run as they do in a room, because it is that code. The player is a guest of the room, so their save stays in their browser as a guest's does online; the map's own records (world data, leaderboards, badges) are kept in the browser as well.
It costs about 2.4 MB more in the export (670 KB compressed): the room, its physics, and a second copy of the renderer, since the room and the play-test runtime are separate builds. A map that does not need the multiplayer runtime should leave it off and use the ordinary local build, which is the default.
What you get
A standalone build is a local build, not a multiplayer client. It runs the exact same runtime the editor's Play Mode uses, so behavior matches what you tested:
- your scene, lighting, audio, particles, and weather;
- every entity script, the input/camera/cursor/character-controller APIs, spawn/destroy, and player verbs;
- render-to-texture cameras and multi-camera viewports;
- a click-to-play start screen.
Because it isn't networked, the player-vs-player and server-authoritative pieces don't apply — it's one local player (or a fully scripted one).
A map with Run scripts unguarded on exports its scripts as written, and the build runs them without the script guard. Such a build refuses to start on a Galatrix site: galatrix.com and its subdomains, and localhost on ports 3000 to 3039, where the Galatrix development servers run. npx serve picks port 3000 by default, so give it another: npx serve -l 5000. It also refuses a site where the player is signed in to Galatrix: one that serves Galatrix under a path of its own shares its storage with every other page on it.
Branding
Standalone builds carry a small GALATRIX.com mark: the start screen reads "GALATRIX.com Engine", and an in-game watermark sits in the top-left corner. The watermark is part of the game UI and stays above the scene, so it is not removed by the running game.
When to use which
- Publish (multiplayer, hosted on Galatrix) — for a shared, server-authoritative game others join.
- Standalone build — for a single-player game, an offline demo, a portfolio piece, or hosting the game yourself.
See also
- Quality & performance — the render ceilings an exported build carries with it. Worth a pass before shipping, since you don't know what hardware the page will open on.