Three pieces of infrastructure landed. None of it is a player feature, and you’ll never touch any of it. It’s what we use to run the world.
Small teams usually build this later, after the game, once the duct tape starts failing. We built it now, because it’s what you need to run a world for years rather than to ship a game once.
A web-based console for operating the live server. Around 55 pages and components, around 190 tests, plus a client SDK and a command-line tool. There’s a lower-level admin gateway underneath it, and an admin client that runs inside the Unity editor.
It can start, stop, restart, and kill the server, kick players, broadcast, put the world into maintenance mode, control game-time, and run live-ops during an incident. It also browses NPCs, RAG documents, prompts, combat logs, and conversation traces, so we can see what the world did and why. Operators sign in with Steam.
The server reports its own health continuously: uptime, CPU on the process and the machine, memory, garbage collection, threads, network, GPU, and per-disk usage and I/O.
It samples every two seconds, stores the history, and charts it, so we can look back at any moment and see what the machine was doing. It runs as a background service.
Deeper request, database, and LLM tracing exists too, switched off by default.
The pipeline builds all three desktop clients. The Mac build is code-signed and notarized, which is what keeps your machine from throwing an “unidentified developer” warning.
The chain runs end to end: bump a version, cut a release, build, auto-upload to Steam. Going live stays a manual step.
The Linux client builds on demand but isn’t wired into the release-to-Steam path yet. Update: Linux client uploaded to Steam.