The engine
Stardust Engine
The game engine under every aeone.games game — one Rust codebase for the simulation and the renderer, running as native code on Steam Deck and desktop, and compiled to WebAssembly + WebGPU for the free games in the browser. Large, moving worlds at full frame rate. Written and evolved by LLM agents on a codebase built for them to read, play, and debug.
- 1,000,000actors
- 60Hz sim
- ∞fps · monitor
Capabilities
A native Rust renderer
Our own renderer, written in Rust on wgpu: Vulkan on Steam Deck and Linux, DirectX 12 on Windows, Metal on macOS, WebGPU in the browser — the same code on all of them. Instanced rendering draws thousands of distinct actors — ships, swarms, crowds — in a handful of draw calls, and every pipeline compiles behind the loading screen, never mid-play.
A deterministic simulation core
The simulation is Rust on its own thread, over one fixed memory layout with no per-frame allocation — native code on Steam Deck and desktop, WebAssembly in the browser. No garbage-collection stutter, and deterministic by construction — the same inputs replay to the same state.
The whole world, in plain SQL
Game state is laid out as Apache Arrow, the open columnar standard, so the running game answers questions in plain SQL. It is how an agent debugs: it reads what the game is actually doing — every table, live — instead of guessing from logs.
Replays, tick for tick
Every session records its inputs, not its pixels. A few kilobytes reproduce a whole run move-for-move — on screen for a human, or headless for an agent — so a bug is recorded once and every fix is proven against that exact run.
Steam Deck first, then everywhere
Our games are built for Steam Deck first — native, at the Deck's own frame rate. The same app runs on Linux, Windows and macOS, and the free games and demos play in any browser tab with no install.
Built by agents, by design
The engine is written and maintained by LLM agents operating on a deliberately agent-legible codebase — roughly 35% comment density and a design corpus that runs nearly one prose-token per code-token. The bet: in LLM-driven development the bottleneck isn't typing code, it's loading the right context.
Built with
How we work
The engine is half of it.
The other half is the studio that runs on it — agents that write, play, tune, and review every game we make.