Atlas

Goal: run on a potato

Atlas has one rule above all others: optimization. Browser games are played on old laptops and cheap PCs, so every architectural decision is weighed against draw calls, triangle count and a stable frame rate first. When two designs are viable, the one that renders faster wins.

The engine and its editors are private. The game built on it, Undead & Unemployed, is public on itch.io and Playgama. I am happy to walk through the code on a call.

Generic engine, specific games

The engine knows nothing about any particular game. A game is a single folder with its rules, configuration and UI, and it plugs into the engine through presets. That split is what lets one engine ship more than one game.

Headless (client + server)

core/ECS, math, fixed-step clock

sim/Rapier physics, movement, runtime loop, authority

Client only

render/WebGPU renderer, batching, LOD

net/Transports, WebSocket today

Per game

games/<id>/Rules, config, UI

One simulation, pluggable authority

The simulation is separate from rendering from day one. A game declares whether it runs locally, hosted in the player’s browser, or on a dedicated server. Either way it is the same authoritative step function: the local player gets client-side prediction and remote players are interpolated. Only the transport and where the save file lives change.

Rendering for low-end hardware

• WebGPURenderer with a capped pixel ratio and an optional GPU timing overlay.
• Instancing and BatchedMesh to collapse thousands of props into a handful of draw calls.
• An asset pipeline that turns exported asset packs into optimized GLBs with Draco geometry compression, KTX2 textures and generated LODs.

Tooling

Level and navigation editors built in React sit on top of the same engine, so what you edit is exactly what the game renders.

Result

A shipped game, Undead & Unemployed, published on itch.io and Playgama, with the engine ready for the next one.