Technical architecture

How Halvesper runs: one world on desktop, web and mobile, 1–5k CCU at launch, built on what the repo already has. Canon (00-canon.md) is binding; docs/platform.md and docs/plan.md are the earlier decisions this document extends. Lore, systems and art are other documents; this one covers only what they run on.

Every recommendation is labeled: - Decided: already in the code or in canon/platform, or a choice with no real alternative. Changing it is a deliberate canon change. - Proposal: the recommended path. Foster can overrule it without a spike. - Needs a spike: the answer depends on a measurement we don’t have yet. The spike and the result that decides it are in §13.

1. What exists today (2026-10-03)

Measured so far (these are the only real numbers; everything else below is a target to measure):

S1 found sandboxed scripts cheap enough for all monster AI, but once S1b made movement native the sandbox think was the larger cost, so S1 was reopened: monster behaviour is data run by native code, and the sandbox is for creator hooks (§5.3). The real cost was GDScript host physics. Body.move costs ~27 µs per body-tick on the VPS, and players use the same Body.move, so §5.3’s ~3 µs per player cannot hold in GDScript. At ~100 µs per player, a 6 ms tick holds ~60 players per process. Moving body movement and collision into a C++ GDExtension shared by server and client (spike S1b, Phase 0) is the plan; §5.3 has the fallback ladder.

2. Goals, non-goals and targets

Goals

1. One world, one account, on desktop, web and mobile (decided, canon).
2. Server-authoritative everything: movement, combat, drops, XP, economy (decided).
3. Feel first: own-character movement answers in the same frame on every platform, and bots in CI keep it that way (decided, canon pillar 5).
4. Never lose or duplicate a traded item (decided here; §7).
5. Cheap to run: bare metal, not managed game hosting (decided in platform.md).
6. Run by a very small team: few moving parts, each one boring (proposal; this drives most build-vs-adopt calls below).

Non-goals (for launch)

• Seamless open world. Maps are discrete, joined by portals, with a short fade. That is MapleStory’s model and it is what makes channels and sharding simple.
• PvP. Without it, lag compensation can favor the attacker freely (§5.6).
• Free-text chat. Preset phrases only at launch (platform.md), so no moderation pipeline is needed day one.
• Multiple regions/datacenters. US first (platform.md); EU is a post-launch project.
• Kubernetes, microservices, multi-cloud.
• Creator content (P4 in platform.md). The architecture keeps the door open; we don’t build the creator pipeline before launch.

Quantified targets

Latency budget (one input, US player, 80 ms RTT)

3. Topology

Diagram

                          players: web (WASM), desktop, iOS, Android
                                          |
            HTTPS (client, packs)         |  WSS (login, social)        WSS (gameplay)
     +--------------------------+         |                                 |
     | Cloudflare CDN + R2      |         v                                 v
     | web client, asset packs, |   +-----------+   +-------------+   +----------------------+
     | patch manifests          |   |  nginx    |-->|  Nakama     |   | game host 1..N       |
     +--------------------------+   | (svc host)|   |  accounts,  |   |  nginx: wss /c/<n>   |
                                    |           |   |  platform   |   |   -> 127.0.0.1:port  |
                                    |           |   |  logins,    |   |  channel procs (Godot|
                                    |           |-->|  friends,   |   |  --headless, 1/core) |
                                    +-----------+   |  groups,    |   |  spawner (Go agent)  |
                                         |          |  chat, IAP  |   +----------+-----------+
                                         v          +------+------+              |
                                    +-----------+          |          control plane: JSON over
                                    |  worldd   |<---------+----------WebSocket on WireGuard
                                    |  (Go)     |                                |
                                    |  directory, tickets, transfer, parties,    |
                                    |  market, mail, escrow, GM API, events      |
                                    +-----+-----+<-------------------------------+
                                          |
                               +----------v----------+       +-----------------------+
                               | PostgreSQL 17       |------>| replica (from beta)   |
                               | nakama db, world db |  WAL  | pgBackRest -> object  |
                               +---------------------+       | storage (PITR)        |
                                                             +-----------------------+
     observability: Vector (logs + SERVER_METRICS) -> Prometheus/Loki -> Grafana, alerts

In three sentences: players log in through Nakama and get a channel list and a signed join ticket from worldd, a small Go service that owns the world directory, transfers and every cross-character economy operation in PostgreSQL. Gameplay runs in channel processes, each a headless Godot server running the existing pure sim with every map of one channel, one process per core on cheap US bare metal, with nginx terminating wss on each host. Portals inside a channel stay in-process (as today); changing channel or host is a ticketed reconnect that saves the character first.

Services: build or adopt

Join flow (as built, worldd v1)

1. The client logs in to Nakama (device id for a guest, or email and password) and holds a Nakama session JWT and refresh token, stored on the device and refreshed when under 5 minutes are left or when worldd answers 401 (once); the login screen and character select are game/ui/login_screen.gd over game/net/account.gd.
2. With it as Authorization: Bearer, the client calls worldd (same origin, nginx /worldd/): GET /v1/characters, POST /v1/characters {name, class} (class warden, kindler, ranger or shade; names 3–12 letters after trimming, with at most one space, apostrophe or hyphen between letters, unique ignoring case, 400 when invalid and 409 when taken; 6 per account), and POST /v1/join {character_id}. worldd checks the JWT with Nakama’s session key (HS256), creates the account row on first sight (id = Nakama user id), and answers the join with {character, ticket}.
3. The ticket is base64url(JSON {account_id, character_id, channel, expires_unix}). base64url(HMAC-SHA256), valid 60 s, signed with a secret shared with the game server. The client sends it in its hello ({t, v, ticket}).
4. The game server checks it offline (game/net/ticket.gd; once per ticket, and one connection per character per process), then loads the character with GET /v1/internal/characters/{id} (service token) and only then welcomes the client. A character never saved gets the sim’s new kit in town.
5. It saves the whole character with PUT /v1/internal/characters/{id} on a hearth bank, on a map change, every 60 s and on disconnect, one save in flight per character. Each save carries save_seq + 1 and a reason; worldd rejects one not above the stored save_seq (409). A 409 means another session wrote the character: the server drops its copy unsaved and sends KICK {reason}, and the client goes back to login with that message. On stop (every deploy) systemd’s ExecStop creates the server’s stop file, since Godot does not hand SIGTERM to scripts; the server stops accepting, saves everyone with reason shutdown, waits up to 5 s for worldd and exits (TimeoutStopSec=20).
6. With no worldd configured (DELVE_WORLDD_URL unset: dev, CI, scenarios, bots) the server takes anonymous hellos as before and nothing persists. The client logs in only when given both Nakama and worldd (--nakama=/--worldd=, or ?nakama=/nakama&worldd=/worldd, which nginx adds to a bare visit) and not --offline.
7. When the socket closes on a logged-in client it goes back to character select and says why: the server’s KICK reason, a refused ticket (expired, or the character is already playing) when it was never welcomed, or a lost connection. A new join takes a new ticket.

Why worldd is its own Go service and not Nakama runtime code. Nakama’s Go runtime plugins must match Nakama’s exact Go and Nakama versions, which couples the economy to Nakama’s upgrade cycle. A separate ~5–10k-line Go service with pgx, verifying Nakama’s JWT session tokens, is easier to test, deploy and replace. If S6 shows Nakama is a poor fit, only accounts and social need replacing; worldd and the game don’t move.

Why US hosting changes from Hetzner to OVH. platform.md assumed Hetzner bare metal. Two facts changed: Hetzner sells dedicated servers only in Germany and Finland (its US sites are cloud-only) [1], and its 2026 repricing put an AX42 at €97.30/month [2]. US cloud instances there include only 1 TB of traffic [3]. OVH’s US Rise line (Vint Hill VA and Hillsboro OR) has a Ryzen 7 9700X, 8 cores, 64 GB, unmetered 1 Gbps for $77/month [4], and fdhproperty is already an OVH account. A single central US DC (Vint Hill) keeps one world simple; Hillsboro is the failover/West option. Hetzner Germany remains the obvious EU home later.

No private network on Rise-S. The Rise-S plan has no private (vRack) bandwidth, so every link between hosts (worldd control plane, Postgres streaming replication, pgBackRest, metrics) runs over WireGuard on the public NIC. That traffic counts against the 1 Gbps port: budget ~50 Mbps on the DB primary for WAL streaming and backups at launch and alert at 200 Mbps. Postgres listens only on the WireGuard interface. Moving the DB pair to a plan with vRack is a later option, not a launch need.

4. Worlds, channels, maps and transfers

Units (proposal, sized by S2)

Why channel-per-process and not map-per-process: in-channel portals stay what they are today (an in-memory move_to), so 90%+ of transfers cost no reconnect and no save; idle maps cost nothing; and a host runs one process per core with no cross-process traffic inside a channel. The fallback, if S2 shows a channel can’t hold ~400 players in the tick budget, is to split a channel by region (one process per region-channel pair) and make inter-region portals ticketed transfers, which the transfer path below supports anyway.

A crowded map (town at peak) is capped at 150. A portal into a full map offers “this map is crowded: switch channel?” (proposal; the systems writer may prefer overflow instances).

Density by CCU. A world that feels empty fails faster than one that lags. worldd opens and merges channels to hold density, not just to absorb load:

• Open a channel when every open channel is above 85% of its target for 5 min.
• Merge when a channel sits below 30% of target for 30 min. It closes to new joins, its players move at their next map change (a ticketed transfer behind the usual fade), and the process stops when it is empty or after 15 min.
• New and returning players are placed in the fullest channel under target, not the emptiest.
• Until S1b lands, the per-process target is whatever S2 measures (about 60 players in GDScript today), and density comes from fewer, fuller maps.

World bosses run in an instance process, not a channel: up to 60 attackers drawn from every channel, entered through a ticketed transfer from the boss’s field.

World singletons

Some things exist once per world, not once per channel: the titans and their routes, Wend’s Absence, Act state, the Pale Tenant’s resolution, the Sunline. These are world-singleton entities: worldd owns their state in Postgres, each channel process renders a read-only copy, and players’ contributions (motes banked, lights lit, boss damage) are reported up to worldd in aggregates every few seconds. Changes that alter the world (Sunline Strides, Act changes, route parameters) take effect only at a Turning boundary (the weekly reset), announced in advance on the event bus, so every process switches on the same tick. Inside an Act the only live changes are event-scoped (a world boss spawning, a Kneeling).

A one-per-world fight (Wend’s Absence, the Pale Tenant, Morrow’s birth) runs as many 60-attacker instances against one shared HP pool: each instance reports its damage to worldd every 1 s, worldd sums it and broadcasts the pool, and when it empties every instance gets the result on the same tick (03-systems.md §15.2).

Transfer kinds

Ticketed handoff (proposal): 1. Source process freezes the character (no input applied), serializes it and asks worldd to save with its lease epoch (§7.3). 2. worldd commits the save, bumps the epoch to the target process, picks the target (channel, map, entry point) and returns a ticket: {character, target, epoch, expires (+30 s), nonce}, HMAC-signed with a key the channel processes share. 3. Source sends TRANSFER {url, ticket} and drops the character from its sim. 4. Client opens wss://gN.<domain>/c/<k>, sends HELLO {v, ticket}. Target verifies the HMAC offline, asks worldd for the character (one row read plus items), places it. 5. A ticket is single-use (worldd records the nonce); an expired or replayed ticket is refused, and the client falls back to login.

This replaces today’s anonymous HELLO {v} and per-connection throwaway characters.

Titan holds that move

The holds are towns on walking titans (canon). Architecturally a hold is an ordinary set of maps, hosted in every channel like any other; what moves is which region the hold is above. Proposal:

• Each titan has a route: a looped list of (region, dwell_hours) legs, in content data, with loop lengths that divide the 168 h Turning. Its position is a pure function of the world clock: leg = f(world_time, route, epoch_offset, sunline_tier), where the Sunline tier is fixed for the whole Turning.
• The world clock is a sim input, like player input: the process passes the world time into Sim.tick, and the sim never reads the wall clock, so determinism and replays hold. No state to save, no sync traffic; every process, the client and worldd compute the same answer from the same data and the server’s clock sent in WELCOME.
• A hold’s descent portal (and the field’s ascent point) is a portal whose target is resolved at use time: portal.to = ["@descent", titan] resolves to the landing map of the region the titan is currently over. Same for the reverse. This is one indirection in Sim.take_portal; maps keep static portal digits.
• When the titan leaves a region, its ascent point in that region closes (portal inactive, visual change); players already below stay and walk to another hold or wait. No forced transfers.
• The Moth Queen’s night-only flight is a route leg with a schedule mask; while she is grounded her hold is reachable only from its grounded region.
• Backdrops (the landscape scrolling past a hold) are client-side cosmetics from the same clock.
• Story events can override a route (a titan stops, turns): worldd holds an override table, applied at the next Turning boundary and broadcast on the event bus; with the Sunline tier, this is the only titan state persisted.

This keeps the “world map never quite the same twice” pillar entirely in data plus a clock. Status: proposal; the systems writer owns the routes.

5. Simulation and netcode evolution

5.1 What stays, changes, is replaced

5.2 Hand-built platform maps (needs a spike: S3)

MapleStory’s collision is footholds: line segments, often sloped, that bodies stand on, plus walls, ropes and ladders as vertical segments. Its maps are painted backgrounds and tile props, not a collision grid. The canon (hand-built maps, HD painted art, slopes implied by the style) points the same way. Proposal:

• Collision data: footholds (segments (x1,y1)-(x2,y2), slope ≤ ~45°, flags: one-way or solid, layer), walls (vertical segments), climbables (rope/ladder segments with top/bottom), portals (rects with ids and targets), spawn points (monster kind, count, respawn seconds), NPC spots, and a camera bounding box. One-way is the default, as in MapleStory; down+jump drops through (today’s dropping).
• Physics: keep Body’s approach (move x, resolve; move y, resolve; speeds below a bound so no sweeps), but resolve against the foothold under the feet instead of grid tiles: a body on a foothold follows it (y = foothold.y_at(x)), walks off its end onto the connected next foothold or falls, and lands on any foothold crossed from above while falling. A uniform-grid spatial hash (e.g. 128 px cells) of segments keeps queries O(1).
• File format: game/content/maps/<id>.map.json (data only, never .tscn/.tres at runtime), integer map ids (append-only, like tile and item ids), schema-versioned. The sim loads it with JSON.parse_string and validates every field, as Protocol.read_frame validates input.
• Authoring: a Godot editor plugin (addons/mapkit) where designers draw footholds with Line2D-like nodes over the painted background, place portals and spawners as marker nodes, and export to .map.json. The .map.json is the source: mapkit opens it as a work scene and exports it back unchanged (a gate test), so there is no second copy to drift. Decided in PR #30. A map lint in the gate checks connectivity (every portal reachable from the entry using the bot’s movement), no gaps over ~1 jump, no spawn in a wall.
• Art is separate: background layers, parallax and props are the art pipeline’s .map.json sibling (client-only), keyed by the same map id.
• Transition: the text ROWS maps become a converter input (tiles → footholds) so the existing zone-tour bot and scenarios keep running while maps are rebuilt.

Decides: S3 shows slopes and one-way drop-through with zero prediction corrections at 100 ms RTT and no movement regression in the zone-tour bot. If foothold physics proves painful in the pure sim, the fallback is the current grid at 4 px with slope tiles.

Mover result (PR #28): game/sim/footholds.gd is the collision behind the zone’s seam, with NativeFootholds in C++ matching it bit for bit. Zones still trace their tile ROWS through Footholds.from_grid. The mover is stateless: a grounded body snaps to the nearest foothold within its slope reach, and an airborne one lands on the highest foothold it crosses, rising or falling: a body knocked up a slope faster than it rises lands on the slope instead of tunnelling under it (the grind bot found it on Mossy Field). No body may end a tick under the ground (Footholds.sunk, held by Zone.sunk in the fight scenarios). Prediction and the protocol are unchanged. The spatial hash uses 32-unit columns. Ground is solid, platforms are one-way. Three things change from the grid mover: feet are the box’s bottom centre, there are no ceilings, and there is no step-up (blocked walkers jump). The zone-tour and slime-fight sweeps pass 64 of 64 seeds, and a slope, platform jump and drop-through at 100 ms each way need no corrections (test_net.gd).

Map files (PR #29): maps are game/content/maps/<id>.map.json, read and validated by map_file.gd and registered by id in maps.gd (town 1, field 2, ponds 3, tollbridge 4). The text ROWS were converted once, to the same footholds the tracer gave. The rows survive as <id>.art.json; since the look pass the renderer no longer draws them (they still load, ids append-only, for the scenario that carves the grid) and they are retired as art; maps from the Mossway rebuild on (field, ponds, tollbridge) have none. mapkit (PR #30) round-trips every map. Mossy Field is moss mounds under two tiers of decks, drawn by game/render/ground.gd from its footholds. Still to do: time an editor round trip by hand. Maps may also name an ambient tier, list static lights as [x, y, radius, intensity], a hearth rect [x, y, w, h] where motes bank and lanterns refuel (town only), set carry_motes (true only for the Deep and the strata), and place props, all optional and appended to the key order. A prop is either art ({art, feet, width, flip}: assets/world/<art>.png, bottom centre at feet; render only) or a prop def placed by name ({def, feet, flip}): assets/world/<def>.json beside its art gives the art, its ref-px size and anchor, and its footholds and climbables in the art’s own ref px, and map_file.gd place adds them to the zone’s collision, mirrored when flipped, so a building’s porch, balcony, roof and ladders are where it is painted (props.gd draws the art behind the ground, or over it for a def with front, or over the characters for a def with over, such as pond water they wade in; ground.gd paints only the map’s own footholds, and every climbable). Footholds stay the sim’s only collision (town is Hearth with its hearth, Mossy Field is Dusk with one lamp). The grid mover is gone (PR #32): body.gd is state only, and S1b’s fuzz and kernel timing run on NativeFootholds.

Units: 1 sim unit = 4 ref px at 1920×1080; tiles.gd’s SIZE := 8 stays, so an 8-unit tile is 32 ref px, used only as a map-authoring snap (canon). project.godot is 1920×1080 with linear filtering and mipmaps, and the camera’s zoom 4 shows 480×270 units.

The Deep (08-scale.md §4) is assembled from hand-built pieces by seed: each piece is a small .map.json with typed edge sockets, and a deterministic assembler joins pieces into a map at instance creation. The assembler runs in the sim (server and client get the same seed), and the map lint runs on every piece and on 1,000 seeded assemblies in the Gate.

5.3 Entities per map and tick budget (S1 measured; S1b and S2 decide)

Per map instance (proposal): 150 players, 60 monsters (a busy field 25–40; boss maps fewer, bigger), 300 ground drops, 150 projectiles/effects.

Per channel process at 500 players, 60 Hz, on a Ryzen 9700X core. The “target” column is the budget; the “measured” column is what GDScript does today.

Monsters (S1 reopened 2026-10-03). Monster behaviour is data run by native sim code, as skills are (D7): each kind’s ai names an archetype (hop, fly, walk, hover-dash) and its numbers, and one C++ call per zone thinks every due monster. The GDScript path in behaviours.gd is the reference and matches it bit for bit, so the web build plays offline with real monsters. New archetypes are engine work; new monsters are data. Sandbox scripts are for creator hooks: event handlers (spawn, hit, phase change, death) that adjust a data behaviour, not a per-tick think.

Monster hooks (decided). A kind’s def may name a hook, a SafeGDScript with one entry point, hook(e: Dictionary) -> Dictionary, contract in game/sim/brains.gd:

• Events: spawn; hit on every damage taken, the killing blow included; phase when health crosses one of the kind’s phases (health fractions; by default the ai’s angry_at, so the Cinder Eye has one, at half); death. e carries the event, the monster (kind, id, centre, health, max health, phase, mark, its current behaviour, speed and wait), and per event the damage and attacker, or the phases from and to.
• Answers, each optional, clamped, absolute rather than cumulative: speed and wait, multipliers in [0.25, 4] on the kind’s speeds and on its rests, hovers and dash times; behaviour, another kind whose ai to run (state and count reset); mark, an integer in [0, 255] handed back in later events; adds, [kind, count], up to 3 non-boss monsters at its centre within the map cap, which fire no spawn hook of their own. A failing, over-budget or malformed answer changes nothing.
• The data think still runs natively; a hooked monster only carries a behaviour kind and a (speed, wait) scale, which the C++ and GDScript thinks apply bit for bit alike. With no hook nothing is drawn, stored or changed.
• Server only. The web client has no sandbox, and networked clients take monsters from snapshots, so what a hook does reaches them as positions, health and state. A hooked kind played offline (web, no server) runs its data behaviour unhooked.
• Same limits as S1 (4×2^20 instructions, 16 MB per call), and the server refuses to start if a hook fails to compile or to answer a spawn.

The per-tick whole-script think is retired from the game; the S1 bench keeps it (tools/bench/s1_brains.gd, tests/test_brains.gd) to measure the contract below. An example hook lives with the tests (tests/hooks/cinder_eye.sgd), not in content.

S1 (run 2026-10-03, PR #17) measured that contract: think_batch(dt, m: Array) -> Array, one call per monster kind, 14 values in and 6 out per monster, as plain Array (in godot-sandbox v0.60, indexing a PackedFloat64Array costs ~65k instructions per access). Monsters think at 12 Hz, staggered by list position; the host integrates movement every tick; the per-call budget is 4 units. At 4.5–5.5 µs per monster-tick it passed S1’s line, but after S1b put movement at ~2 µs it was the largest monster cost, hence the reopening. Data run natively thinks in 0.85–0.90 µs per monster-tick on the VPS (PR #26), about 7× less.

Bodies are the bottleneck. Players and monsters share Body.move, which costs ~27 µs per body-tick in GDScript on the VPS. Fallback ladder, in order, each step tried only if the one before misses the budget: 1. S1b (Phase 0): move Body.move and collision into a C++ GDExtension that is the shared sim core, used by server and client so prediction stays exact. Target ≤ 2 µs per body-tick on the VPS. Golden-vector tests run the GDScript and C++ paths on the same inputs and require identical output (positions are integers in sim units, so bit-exact parity is achievable). The web build needs a custom export template with dlink enabled so it can load the extension; that template is part of S1b. Result (PR #19): 1.7–2.0 µs on the VPS; parity is bit-exact over 2.6M body-ticks with float32 positions, as both paths do the same float operations. The C++ kernel itself is 0.06–0.08 µs, so nearly all of what is left is the GDScript-to-C++ call. The next gain is state held in C++ per zone, not a faster kernel. The grid mover is frozen until S3; the foothold mover replaces it in C++ with the same parity harness. 2. Profile and trim the remaining GDScript (snapshot packing moves to the same extension; protocol v2 removes var_to_bytes). 3. Split a channel by region (one process per region-channel pair), with inter-region portals as ticketed transfers. More processes, same players per core. 4. Drop the sim to 30 Hz with 60 Hz client interpolation. Halves cost; costs feel, so it is the last resort.

Light in the tick. Light radius, mote carry and Lampghost tests are sim queries against the same spatial hash as footholds, inside the budget above. Lampghosts that are hidden by darkness are filtered per client: the server sends a hidden Lampghost only to clients whose light reveals it (interest filtering), so a modified client cannot see them. Collision that depends on light (light-bridges, dark-only platforms) uses server-confirmed light state. Your own lantern is predicted exactly and static light is fixed once placed; for a party member’s lantern the server keeps a lightbridge solid for you for 0.5 s after their light leaves while your client fades it over the same 0.5 s (03-systems.md §6.9), so a client that sees the light late is never dropped by a correction it could not see.

Snapshots are staggered: client k gets its snapshot on ticks where tick % 3 == k % 3, so encode cost is spread evenly instead of spiking every third tick. Proposal.

5.4 Protocol v2 (proposal)

Replaces var_to_bytes (the TODO at the top of protocol.gd). Hand-packed with StreamPeerBuffer, little-endian.

Client → server, INPUT, 30 Hz: header (type u8, seq u32, last snapshot tick received u32, view tick u32 for lag compensation), then the last 6 frames, oldest first, each 8 bytes: move_x i8, move_y i8, buttons u8 (jump, use, interact, skill 1–5 edge bits), hotbar u8, aim_dx i16, aim_dy i16 (aim relative to the player, in pixels; touch sends facing). ≈ 60 bytes per packet, ~1.8 KB/s with framing. Today a frame is 10 floats (40 bytes) sent every tick with 4 redundant frames. Menu actions (inventory slot clicks, stash) leave the per-tick frame and become separate reliable ACTION messages with ids, since they don’t need tick-rate redundancy.

Server → client, SNAPSHOT, 20 Hz per client: - Header: tick, ack (last input applied), baseline tick (the client’s last received snapshot this one deltas against, or 0 for full). - Own character: full state as today’s ME fields, quantized; changed-field bitmask. - Entities in the client’s area of interest: for each, a 1-byte change mask, then only changed fields. New entities carry everything; gone entities are an id list. - Rare, reliable data (inventory, stash, stats, quest log, chat bubbles, damage numbers) goes as separate event messages with sequence numbers, sent once and resent until acked, not inside the snapshot (today’s hash-compare of inventory moves here).

Quantization: positions u16 at ¼ px (maps up to 16,384 px wide; larger maps use u24), velocities i16 at ⅛ px/s, health as u16 percent-of-max ×100 for others (exact for self), facing and flags in bits, entity ids u16 per map with a generation counter.

Delta compression: against the last snapshot the client acked (the client already reports ack for input; v2 adds the snapshot it last received). The server keeps a ring of the last 32 per-client sent states (~1.6 s). An idle entity costs 0 bytes; a walking one ~6–8 bytes. If the baseline has fallen out of the ring, send full.

Area of interest: the client’s view rectangle (from the resolution it reports, clamped to a maximum) plus a 50% margin, recomputed per snapshot with the map’s spatial hash. Players beyond it appear only on the minimap, at 2 Hz, as (id, x, y) u16s. Visible-player cap: 60 nearest, with a client setting to show fewer (mobile default 30).

Expected size: crowded town, 60 visible players walking + 0 monsters ≈ 60 × 7 + 40 header ≈ 460 B × 20 = 9 KB/s; a field with 6 players and 30 monsters ≈ 36 × 7 ≈ 250 B × 20 = 5 KB/s; idle ≈ 1 KB/s. Plus framing: WebSocket (2–6 B) + TLS record (~29 B) + TCP/IP (40 B) ≈ 75 B per message, ~1.5 KB/s at 20 Hz down plus ~2.2 KB/s up at 30 Hz. That is why input moves from 60 to 30 Hz.

Versioning: HELLO carries protocol version and content version. Servers accept the current and previous protocol during rollouts (§11.5).

5.5 Transport

WebSocket over TLS is the only transport every target (including the browser) has, and it is decided (platform.md). Its weakness is TCP head-of-line blocking: one lost packet stalls the next ~1 RTT of snapshots. Interpolation (100 ms) and input redundancy absorb this on wired and good Wi-Fi; mobile networks are the risk. Spike S7 runs the bots at 1–3% loss and 150 ms jitter; if stalls exceed what a 150 ms interpolation delay hides, add WebRTC data channels (unreliable, unordered) for snapshots only, which Godot supports on the web natively and on desktop/mobile through the webrtc-native GDExtension. Not before.

5.6 Input handling, prediction and lag compensation

• Own movement: predicted, replayed on each snapshot (decided, works). Skills that move the player (dash, teleport, rope-lift) must be predictable too, so they are defined as data executed by native sim code (impulse, duration, i-frames), not as scripts. The web client has no sandbox (tools/sandbox.sh); anything the client must predict cannot live in a sandboxed script. Decided by that constraint.
• Own attacks: the animation and hit spark play instantly on press; damage numbers and kills appear when the server confirms (~one RTT). MapleStory itself waits for the server; players read it as normal. Proposal.
• Hits on monsters (lag compensation): the client sees monsters ~100 ms + RTT/2 in the past. Each INPUT carries the client’s view tick (client._render_tick). For a player’s attack, the server tests the skill’s hitbox against monster positions rewound to the view tick, clamped to 250 ms, from a per-map ring of monster positions (15 ticks of history at 20 Hz sampling is enough, 6 bytes × monsters). PvE only, so favoring the attacker has no victim. Proposal.
• Hits on players: monster contact and projectiles resolve at server present against the server’s player position, which the client predicts accurately (zero corrections today). No rewind. Decided. The client does not predict its own contact hits: it draws monsters ~100 ms + RTT/2 in the past while its character runs RTT/2 ahead, so contact against what it sees would invent hits the server never had and miss ones it did, each a correction plus a wrong number. Each real hit is instead one correction (the knockback and stagger replay exactly once the snapshot carries them), which the render layer smooths: client.smoothing is drawn as an offset that eases away over ~100 ms at most 4 units a tick, snapping only past 64 units or across a zone change. The sim never sees it. tests/test_net.gd holds the drawn character to 8 units a tick through contact hits at 100 ms each way.
• Input starvation: when a client’s next frame has not arrived, that player’s tick waits for it (server._next_frame returns null and Zone.step skips the player) instead of repeating the last frame. The server then applies exactly the frames the client predicted, each once, so a client running slower than the server (a loaded machine, a throttled tab) is never corrected for it; it only looks slow to others. Only the player’s own movement and input wait: monster contact, knockback and death still land (Combat.step), and after STARVE_TICKS (8, the input buffer) without a frame the player stands idle, so a client that stops sending stops rather than freezing in place. Repeating the held frame cost the #82 newcomer playtesters (real client, four at a time on one host, running at ~75% speed) ~6,000 corrections a run, about half of them inside a hit’s 30-tick window and so read as knockback. Decided.
• Input buffer: keep MAX_BUFFER = 8 ticks; add server-side measurement of each client’s buffer depth and tell clients to nudge their send clock (time dilation of ±2%) so the buffer sits at 1–2 ticks. Proposal; reduces input latency by up to 100 ms on jittery links.

5.7 Determinism as an ops tool

The sim is deterministic per binary. Proposal: every channel process keeps a 10-minute in-memory flight recorder (inputs + map seeds + monster rolls, ~30 B per player per tick compressed) and dumps it on crash, on a GM request, or when an economy alert fires. That replays any incident offline with the same build. Not persisted routinely (500 players would be tens of GB a day).

6. Scripting and content

6.1 What runs where

Rules (decided, from platform.md): no load() of .tres/.tscn from any downloaded or creator source; content packages are data plus scripts, signed after review. Script contracts follow brains.gd: inputs as plain values, outputs clamped by the host, budget per call, failure leaves a safe default. Scripts get no engine access (restrictions = true). New script APIs are added as explicit host functions with validated arguments, never by opening engine classes.

6.2 Packaging and versioning

• A content build (CI) produces: data tables, .map.json, .sgd scripts, and a manifest {content_version, files: {path: sha256}} signed with an ed25519 key held by the deploy, not CI. Servers refuse unsigned or mismatched content. Proposal.
• Asset packs (textures, audio, fonts, map art) are built per region as PCKs by CI, with a gate check that they contain no script resources, signed the same way, uploaded to R2 under content-hash names. First-party packs only; creator art later goes through a whitelist importer, not PCK. Proposal.
• Server and client agree on content_version at HELLO. A client with an older content version downloads the delta before entering the world. Gameplay data the client needs (maps, skill data, item tables) is part of that, so balance changes ship without an app-store build.

6.3 Hot reload

• Data tables: worldd broadcasts “content N+1 available”; each channel process loads and validates it, then applies it at a map’s next empty moment or on a GM command. Clients fetch the delta and apply at the next map change. Proposal.
• Scripts: brains.use(kind, source) already replaces one monster script live and returns the compile error. Generalize it: compile all new scripts first, swap only if every one compiles and passes its smoke call (as server._check_scripts does at boot). Proposal.
• Engine/GDScript code (anything outside content): needs a process rollover (§11.5).

6.4 Client builds and patching

Compatibility rule (proposal): the server supports the current and previous protocol version for at least 14 days, so a store build in review never strands players. Each binary has a build number; worldd holds min_supported_build per platform and the client shows “update required” below it. Only protocol-breaking engine changes force an update; everything else is content.

Godot is pinned (tools/godot.sh: 4.7.1-stable) for client and server together; engine upgrades go through a staging soak with the bot suite.

7. Persistence

7.1 Data model (proposal; PostgreSQL 17, database world)

accounts            id (= Nakama user id, uuid), created_at, flags, age_gate, ban_until
characters          id bigserial, account_id, slot, name (unique, citext), class, level,
                    xp, map_id, x, y, channel_pref, coins bigint, save_seq bigint,
                    lease_owner text, lease_epoch bigint, progress jsonb (skills, quests,
                    keybinds, settings), created_at, updated_at, deleted_at
items               uid bigint PK (equipment and any non-stackable), def_id int,
                    location_kind smallint (character, storage, guild_bank, market,
                    mail, escrow), location_id bigint, slot smallint, attrs jsonb
                    (rolls, upgrades, bind state), minted_at, minted_by
                    UNIQUE (location_kind, location_id, slot)
stacks              location_kind, location_id, slot, def_id, count
                    PK (location_kind, location_id, slot)
account_storage     account_id, slots   (the storage NPC; shared by an account's
                    characters, as MapleStory's is)
guilds              id, nakama_group_id, name, level, bank_coins, emblem jsonb
market_listings     id, seller_character_id, item location (escrowed), price, expires_at,
                    state
mail                id, to_character_id, from_character_id, coins, escrow_ref,
                    expires_at, claimed_at
escrow              id, kind, from_*, to_*, coins, created_at, state
item_ledger         id, at, tx_id, uid or (def_id, count), from_kind/id, to_kind/id,
                    reason, actor (character, GM, system)   -- append-only, partitioned
                    monthly
events              at, kind, character_id, data jsonb       -- analytics, partitioned
gm_audit            at, gm_account, action, target, before, after, reason

Why this shape: - Items with unique ids live as rows. Anything that can differ from another copy (equipment, rolled items, cash-shop items) has a uid; a primary key makes a duplicate physically impossible to store. Stackables (potions, materials, coins) are counts. Proposal. - uids are minted from a Postgres sequence in blocks of 10,000 leased to each channel process, so a drop doesn’t wait on the database. Proposal. - def_id is the existing item id (items.gd): append-only, never renumbered. The same rule extends to map ids, monster kinds, skill ids and quest ids. Decided (repo rule). - Character progress that is only ever read and written whole (quests, skills, key bindings) is jsonb with its own save_version and in-code migrations. Proposal. - The client keeps no character of its own. Online play never reads or writes a local save; offline (scenarios, the gate, a bare launch with no server) is a fresh character every run with nothing persisted. The single-player user://world.save and its “New character” button were removed; old save files are left on disk unread, with no migration. Lint rejects user:// under game/. Decided.

As built (worldd v1, 2026-10-04), database delve_world, worldd/migrations/0001_init.sql: accounts; characters (level, xp, brass, map, feet position, hp and max hp, a progress jsonb holding the lantern’s rank, fuel and banked motes, the selected hotbar slot and quest states (string to int; the Lodge induction is lodge, a quest its key and each kill goal’s count <key>.<goal>, D78), save_seq, soft delete); items (uid from the item_uid sequence, def_id, location kind 1 pack or 2 stash plus character id and slot, attrs, minted_by; unique slot, deferred); stacks for everything that stacks; and ledger (character, kind brass or item, def id, uid, delta, reason, save_seq, at). A save is one transaction: the character row, its items and stacks rewritten, a ledger row per brass change and per uid that came (+1) or went (−1). An item stacks to 1 means it has identity (the swords and bows today). The game server sends gear it has no uid for as uid 0; worldd gives it an unreferenced uid of the same item the character already owns before minting, so a save built before the last one’s answer cannot mint twice. Moves inside one character (pack to stash) are row updates, not ledger rows. Not yet built: leases and fencing (§7.2; one process, one connection per character for now), block-leased uids, storage, mail, market and escrow. Trades and mail later move a uid’s row between location kinds in one transaction with a −1 and a +1 ledger row.

7.2 Ownership: one writer per character

While a character is online, its channel process is the only writer of its row and its items. That is enforced, not assumed: - worldd grants a lease when the process loads the character: lease_owner = process id, lease_epoch = epoch + 1. - Every save is UPDATE ... WHERE id = $id AND lease_epoch = $epoch. Zero rows updated means the process lost the lease (a transfer or a GM action took it), and it kicks the player at once. This is a fencing token: a stalled or partitioned process can’t overwrite newer state. - Leases expire if a process stops heartbeating (10 s); worldd then lets the character log in elsewhere from its last committed save.

7.3 Save cadence and crash recovery (proposal)

At 5k CCU that is ~170 periodic saves a second plus events, a few hundred small transactions a second: far inside one Postgres on NVMe.

A crashed process loses at most 30 s of uneventful progress per player. Players reconnect through login, which waits for the lease to expire or for worldd to see the process gone (spawner reports the exit), whichever is first. Target: back in the game within 30 s of a crash.

7.4 Anti-dupe design

The invariant (decided here): an item changes owner only in a database transaction that also commits its removal from the previous owner. Every dupe in MMO history is a violation of this, usually “the receiver saved, the giver rolled back”.

Defenses in depth: - uid primary key and the unique slot constraint turn a logic bug into a failed transaction and an alert, not a dupe. - item_ledger is append-only; a nightly job reconciles: every live uid has exactly one location, and per item def, minted − destroyed = live. Brass likewise (minted − sunk = held). Drift opens a GM case. - Rate and velocity alerts (§9). - A chaos test in staging: kill -9 a channel process and worldd at random points during scripted bot trades and market churn for an hour; the reconciliation must stay exact (spike S5).

7.5 Migrations and backups

• Schema migrations: numbered forward-only SQL files in worldd/migrations/ (embedded in the binary), run by worldd on deploy before it accepts traffic. Expand/contract: add columns and backfill first, switch code, drop later, so a rollback to the previous build works. Proposal.
• Save migrations: progress jsonb carries save_version; code migrates on load. Never delete a migration.
• Backups: pgBackRest, full weekly, differential daily, WAL archived continuously (archive_timeout = 60 s) to object storage in a different provider than the database (e.g. Cloudflare R2 or Backblaze B2). Point-in-time recovery. Retain 35 days. Proposal. Today: nightly pg_dump on the host only (10-operations.md §8, D30).
• Replica: a streaming replica on a second host from open beta; manual promotion runbook (RTO ≤ 1 h; automatic failover with Patroni only if the manual drill is slow).
• Restore drill: monthly, automated: restore last night’s backup into staging and run the reconciliation job against it. A backup that hasn’t been restored isn’t a backup.

8. Client architecture

8.1 Layers (decided shape, extended)

InputFrame source (keyboard/mouse, gamepad, touch)  ->  client.gd (predict, replay,
interpolate)  ->  Sim (never ticks the world on the client; own movement only)
                                                      ->  views (Godot scenes, Node2D)
                                                      ->  UI (Control scenes)

The sim stays pure; game/render/ and game/ui/ are the only scene-tree code; the client copies snapshot state into its Sim and views read it, as client.gd does now. InputFrame is the one input abstraction for every device (decided: gameplay never calls Input).

8.2 Character rendering: cutout rig with runtime bake

Art direction is 05-art-audio.md’s; it defines a cutout rig (painted parts on a skeleton, equipment as parts swapped into slots). The technical shape (proposal, spike S4):

• Rig: one shared skeleton per body type, Skeleton2D or a light custom bone transform in the view; equipment items are painted parts mapped to slots with joint sockets. Animation is bone data, shared by every character, so new gear costs parts, not frames.
• Runtime bake: drawing a rig live is ~10–15 draws and a bone update per character. Instead, when an appearance (body + equipped parts + dye) first enters view, the client renders its animation set once into a shared atlas page through a SubViewport, then draws that character as one sprite, one draw. Budget ~360 KB of compressed atlas per baked appearance at the on-screen size, so 150 distinct appearances is ≈54 MB. Pages are reference-counted and evicted LRU; the local player and party stay live-rigged so equipment changes and effects show at once.
• Bake cost: spread over frames (one appearance per frame, ≤ 2 ms), so a crowded town fills in over a second or two with live-rigged characters until each bake lands.
• Textures: parts in per-item atlases, ETC2/ASTC on mobile, S3TC/BPTC on desktop, Basis Universal on the web where needed; loaded on demand.
• Caps: visible players 60 (mobile default 30, §5.4); beyond that, name tags and minimap dots only.
• Light: a light buffer composites heartfire and coldlight on top of baked sprites; a Lampghost’s stolen ember is a rig point the shader lights (05-art-audio.md), not baked away.
• Renderer: Compatibility (OpenGL ES 3 / WebGL 2) on every platform, so one renderer is tested. Proposal; 2D gains little from Forward+ and web requires Compatibility.

S4 decides bake sizes, page sizes and caps from real devices.

8.3 Performance budgets (proposal)

Web memory matters most: the WASM heap grows but never shrinks, and mobile browsers kill tabs well below desktop limits [5]. Region asset packs (20–60 MB each) download when a player first approaches that region and are cached (IndexedDB on web via user://).

8.4 UI and touch

• UI: Godot Control scenes with one shared Theme, built for a 1920×1080 reference viewport with canvas_items stretch and expand aspect, plus a UI scale setting. project.godot says 1920×1080 with linear filtering and mipmaps (the look pass; the gate’s frames moved to 1920×1080 with it). Separate layouts for touch (bigger targets, fewer open windows) selected at runtime. Proposal.
• Touch input: left-half virtual stick (move_x, move_y, with down+jump as a gesture), right-side jump/attack, 6 skill buttons and 2 contextual buttons (interact, lantern); aim is facing. All produce the same InputFrame. Auto-pickup on touch (MapleStory mobile does). 03-systems.md owns control design; 05-art-audio.md owns the HUD.
• Text: one font family with CJK fallback later; all strings through tr() from day one so localization is not a refactor.

9. Security and anti-cheat

Server authority is the foundation and is already true: the client sends only input frames, clamped by Protocol.read_frame; position, damage, drops and XP come from the server’s sim. Speed, teleport, damage and item hacks have nothing to edit. What remains:

10. Observability

• Metrics: Prometheus. Channel processes keep printing SERVER_METRICS (extended: per-map players and monsters, tick mean/p99/worst, bytes in/out per player, snapshot sizes, sandbox failures, queue depths) every 10 s; Vector tails journald and converts them to Prometheus metrics, so the Godot side stays a print. node_exporter, postgres_exporter, Nakama’s built-in Prometheus endpoint, worldd’s /metrics.
• Logs: journald → Vector → Loki. Structured key=value lines from Godot, JSON from Go.
• Traces: OpenTelemetry in worldd only (login, transfer, market paths). Not in the tick loop.
• Dashboards: CCU by channel and platform, tick p99 per process, RTT distribution (clients report it in INPUT every 5 s), transfer time, save latency and failures, ledger reconciliation status, economy (coins minted/sunk per hour).
• Alerts (Alertmanager → phone): tick p99 > 12 ms for 5 min, process crash loop, save failure rate > 0, lease conflicts spiking, reconciliation drift, Postgres replication lag > 30 s, backup older than 26 h, CCU drop > 30% in 2 min.

11. Ops

11.1 Deploy topology by phase (proposal)

11.2 Process orchestration

The spawner (Go, ~1k lines, one per game host, systemd service) proposal: - Registers the host’s capacity with worldd; worldd asks it to start or stop channel and instance processes. - Starts each as a systemd transient unit (systemd-run) with the same hardening as today’s delve-server.service (own user, MemoryMax, CPUQuota=100%, ProtectSystem=strict), pinned to a core (CPUAffinity), on a local port that nginx routes as /c/<n>. - Restarts crashed processes, reports exits so worldd can expire leases at once. - Server builds become a dedicated-server export (--export-release with the dedicated server mode stripping textures and audio), not the editor binary plus the project tree that deploy.sh ships now. Smaller, faster to start, and no import step on the host. Proposal.

11.3 Environments

11.4 CI and load testing

• The Gate stays the PR arbiter (decided). It gains: worldd Go tests, a map lint (§5.2), a content signing check, and an online stage that also covers a ticketed transfer between two server processes. No tests run locally (repo rule).
• Headless bot load tests (proposal): the client is transport-free and the sim pure, so one headless Godot process can drive ~100–200 bot clients over real WebSockets (each bot runs client.step and a goal policy from the existing scenario bots: zone-tour, slime-fight, grind). Rent 2–4 cloud VMs by the hour near the target DC.
  • Nightly on staging: 300 bots, 30 min.
  • Before each phase gate: 1.5× the phase’s CCU target for 4 hours, plus chaos (kill processes, drop 2% packets, restart worldd). Pass: tick p99 ≤ 12 ms, zero reconciliation drift, zero stuck leases, transfer p95 ≤ 1.5 s.
  • Load bots run against Linux servers, never on macmini4 (it is the only CI box and the servers are Linux).

11.5 Live updates

12. Cost model

Assumptions (proposal, valid only if S1b passes; S2’s numbers replace them): a game host is an OVH Rise-S (8 cores, 64 GB, 1 Gbps unmetered, $77/month) running 7 channel processes at ~300–400 players each. In GDScript today (~60 players per process) a host holds ~400 CCU and hosting costs about 4× the table below, still under $1 per CCU, planned at 1,500 CCU per host with N+1 spares. Bandwidth at the p99 target (12 KB/s) is 1,500 × 12 KB/s ≈ 144 Mbps per host, a seventh of the port, and unmetered. Prices are USD per month, excluding VAT and one-time setup fees (equal to a month on Rise).

Comparison: managed game hosting at ~$1.5–2 per CCU (platform.md, Edgegap) is $3,000–4,000/month at 2k CCU, 7–9× this. Hetzner’s US cloud (CCX33 8 vCPU at ~$166/month with 1 TB included) would cost about twice as much per core before traffic [3]. Not included: people, Apple ($99/yr) and Google ($25 once) accounts, store and payment fees, a commercial anti-DDoS upgrade if attacked, and support tooling. Infrastructure is not where this game’s money goes; the risk is ops time, not hosting bills.

13. Risks and spikes

Ordered by how much of the architecture each one can change. Each spike is small, runs before the dependent work starts, and has a pass line that decides.

Other risks without a spike yet: - godot-sandbox is a small project (noted in platform.md); we pin versions and checksums (tools/sandbox.sh) and could fork. Its Linux teardown abort at exit is already worked around in deploy.sh. - Single DC: one Vint Hill outage takes the world down. Accepted for launch (99.5% target); Hillsboro failover with the replica is the year-two answer. - Bus factor: the whole stack is understood by Foster and agents. Runbooks for every alert are part of each phase’s exit criteria. - Botting is the economic risk MapleStory never solved; the detection pipeline is built for beta, not after.

14. Phased build order

Every phase ends with a bot proving it, as every milestone does now.

06-roadmap.md owns the calendar. Phase 0 (spikes, about 16 weeks: S1 done, S1b, S2, S3, art spikes) and Phase 1 (the vertical slice) come before Phase A.

Phase A: internal alpha (≤ 300 bot CCU, private (D28), web + desktop)

Minimum: 1. S1b, S2 (at 300) and S3 passed in Phase 0; decisions recorded here and in 07. 2. Protocol v2: binary, quantized, deltas, AOI, 30 Hz input, staggered snapshots. 3. Foothold maps, editor plugin export, map lint; the slice’s maps rebuilt. 4. worldd v1: join tickets, character load/save with leases, item uids, ledger, migrations. Postgres with pgBackRest backups. 5. Nakama: device + email + Google login (Apple once iOS is in), friends. 6. Channel processes (2–3 channels) + spawner on one Rise-S; fdhproperty becomes staging. 7. Ticketed channel change; flight recorder; Grafana dashboards and crash alerts. 8. Load bots nightly on staging. Out: market, mail, guilds, mobile, rolling deploys (weekly maintenance is fine).

Phase B: launch readiness (≤ 2,000 bot CCU, + mobile test tracks)

1. S4, S5, S6, S7, S8 run and decided.
2. Multi-host: 2 game hosts, services host, DB replica, all over WireGuard on the public NIC (no private network on Rise-S, §3).
3. Market, mail, storage, guild bank via the escrow path; reconciliation job and economy alerts.
4. Parties across channels, guilds (Nakama groups + worldd state), preset chat.
5. Instance processes for dungeons and the raid.
6. Content signing, hot reload of data and scripts, asset packs on R2 per region.
7. GM tools v1 with audit; report/block queue; bot-detection signals v1.
8. Titan routes and dynamic hold portals; world singletons; event bus; Turning-boundary world changes.
9. Channel rollover deploys; protocol N/N−1.
10. Load test passes at 3,000 bots for 4 hours with chaos.

Phase C: launch (1–5k CCU, all platforms)

1. Store releases (iOS, Android, desktop per D13), IAP via Nakama validation, min_supported_build.
2. 4 + 1 game hosts, 2 services, DB on larger boxes; restore drill green 3 months running.
3. Bot detection actions (ban waves), new-account trade limits.
4. worldd standby with leader lock.
5. SLO dashboards, on-call alerts, runbooks for each alert.
6. Load test at 7,500 bots for 4 hours with chaos.

After launch

Hillsboro failover, ClickHouse analytics, EU region on Hetzner Germany (a second world or a latency-tolerant join, to be decided), GDExtension hot loops as measurements demand, creator pipeline (P4).

15. Decisions

Open decisions are in 07-decisions.md: hosting (D4), Nakama (D5), worldd in Go (D6), skills as data (D7), desktop distribution (D13), maintenance policy (D14) and shared storage with mail-only trade (D15). Settled: channel = one process holding every public map (canon), monster AI as data run natively with the sandbox for hooks (S1, reopened after S1b), and the GDExtension shared core with S1b started (D12).

Sources

1. Hetzner cloud locations: Ashburn and Hillsboro are cloud-only
2. Hetzner price adjustment 2026: AX42 €97.30, AX102 €257.30
3. Hetzner US cloud traffic: 1 TB included, ~€1/TB over
4. OVHcloud US Rise dedicated servers (Rise-S $77, Rise-1 $70, Rise-2 $80; Vint Hill, Hillsboro; unmetered), OVHcloud US Advance
5. Godot: exporting for the web (networking limits, threads), 400 MB heap in default web build (godot #104422)
6. Nakama (Apache 2.0), Nakama Godot 4 client
7. godot-sandbox
8. Measurements: PR #13 (M6b online), PR #15 (M6c sandbox), SERVER_METRICS on fdhproperty.