What Galatrix is
Most engines are a download, a build pipeline and a hosting problem you solve yourself. Galatrix puts both halves on one web stack, an editor that runs in a tab and a platform that hosts what you publish.
Updated
The two halves
Galatrix is an engine and a platform, and the split matters because it decides what you have to do yourself.
The engine is the part you build with: a 3D scene, physics, scripting, animation, navigation, terrain, UI. It runs in a browser tab, the same tab you play in. There is no separate runtime to install and no export step between changing something and trying it.
The platform is the part that carries your game to other people: accounts, hosted multiplayer rooms, a place your world is listed and found, avatars that follow a player between worlds, saved progress, leaderboards. You do not rent a server or configure one.
Either half is useful without the other. You can build something single-player, export it, and host it anywhere. You can also play what other people published without ever opening the editor.
What the browser actually removes
Three things, and they are the reason the whole thing exists.
No toolchain. Opening a URL is the install. There is no SDK, no package manager, no compiler, no version of the engine to keep in step with a version of your project.
No build to wait for. You place something, press Play, and you are inside it. The play-test is the same engine that runs the published game, so behaviour you see while testing is the behaviour players get.
No servers to arrange. When you publish, a Galatrix game server hosts the room. Multiplayer is the default way a published world runs, not something you bolt on at the end.
The editor is also installable. It is a progressive web app, so it can live in its own window with its own icon, and it caches itself: the editor, the viewport and single-player play-testing keep working with no connection. Publishing and multiplayer need a server, so those do not.
How a multiplayer session works, in one paragraph
You do not need this to build a game, but knowing it explains a lot of the design advice elsewhere in these guides. When a player joins your world, the platform finds a room with space or starts a new one on whichever game server is least busy, then hands the player a single-use ticket to connect straight to it. From that point the server runs the simulation: it holds the authoritative physics, steps it on a fixed tick, and broadcasts what changed. The player’s client sends intent (move here, jump, use this) and predicts the result locally so it feels instant, then corrects itself when the server’s version arrives.
This is why a player cannot tell the server they are somewhere else, and why two people in the same room see one world instead of two drifting copies.
What it is good at, and what it is not
Galatrix suits games made of clear, chunky geometry and readable systems: obstacle courses, driving, arenas, tycoons, collectathons, hangouts, 2D side-scrollers. Blocky worlds are a first-class citizen — you can bring in Minecraft-format builds and they are baked down into optimised static geometry rather than run as a live voxel engine.
It is not a photorealistic engine, and a browser tab is not a console. You are working inside a web page’s memory and a GPU you did not choose, on a machine that might be a phone. That budget shapes what looks good here: strong shapes, strong lighting, restrained draw distances. The engine gives you the levers — quality presets, distance culling, a profiler — but the budget is real and it is worth designing inside it from the start rather than trimming at the end.
Where the boundary sits with the docs
These guides cover concepts and workflow: what a thing is for, when to reach for it, what the trade-off is. They deliberately avoid naming exact fields, keys and function signatures, because those move as the engine moves and there is one place that always matches it — the documentation, whose script reference is generated straight from the engine source.
So: read here for the shape of the work, and follow the links for the specifics.
Where to go next
If you want to make something, the fastest honest route is not a blank scene — it is a starter kit, because a working game you can take apart teaches the engine faster than a tutorial. If you want to know what happens when you are ready to show it to people, read publishing and what review means.