Under the hood

No marketing here: how this thing is built and why.

Server

C++20, one process per world. All game state lives on a single thread — no mutexes, because there is exactly one owner. A second thread does nothing but sockets: polls them, reads and writes, and never touches game code.

Two queues bridge them: an inbound one wakes the logic, an outbound one reaches the I/O thread through a self-pipe. While the logic waits on the database, the sockets keep living on another core.

The tick runs 20 times per second. The client sends intent; the server decides.

Storage

PostgreSQL. The important property: world revisions are append-only and never change. Schema triggers physically reject UPDATE and DELETE on them — not a convention, an enforcement.

An A→B transition follows rules familiar to anyone who has written distributed systems:

• a lease on the transition, so two processes never move one world;
• a fencing token that only grows, so a late writer is cut off;
• a compare-and-set on the head, so a commit lands only if the head is where it was;
• an outbox written in the same transaction as the revision.

Which is where the verifiable claim comes from: a transition survives a server restart halfway through. Not "usually" — it is a regression test.

The hot path

A day of becoming is 20 ticks a second, and each of them used to hit the database. Today the hot path writes nothing:

• the base revision is decoded once and cached, because it is immutable;
• the lease is renewed when a third of its life is gone, not every tick;
• the world clock is written when a second has accumulated, not every tick.

After a crash the world replays at most one second — deterministically and idempotently.

Crypto

Ours, without TLS: X25519 for the handshake, ChaCha20-Poly1305 for frames, HKDF-SHA256 for keys. The server key is pinned in the client, so certificates and authorities are not part of the picture.

It is proven across three implementations: C++ on the server, CryptoKit in the Swift client, Python in the tests. All three agree on the same keys.

Client

macOS, Swift and Metal. The client owns the frame — passes, shadows, HDR. The shape of the world comes from the server and is never invented locally: until WorldSpec arrives, there is nothing to build.

Terrain is computed by the same algorithm in C++, Swift and Python, and matched bit-for-bit. Otherwise the player and the server would see different mountains.

Build and deploy

A monorepo. The server is built inside a container running the same Ubuntu as the production machine — otherwise the binary would not start there. Nothing is built on the production machine itself: two cores and a live game loop, and compilation would jitter the tick.

After a deploy comes a probe: a real encrypted handshake and login. If it fails, the binary rolls back to the previous one, automatically.

What is not here

No trackers, no cookies, no analytics, no outside requests. This site does not know that you are reading it.