From 9a4dc1c8e35a149a43457d1e0107e304dabbec63 Mon Sep 17 00:00:00 2001 From: Meta Vens Date: Tue, 27 Oct 2026 03:45:20 +0100 Subject: [PATCH] Research: prior art on multiplayer framework ergonomics and scale-out (serves the CultMesh garden-path direction, operator 2026-10-27) Co-Authored-By: Claude Opus 5.5 --- .../prior-art-2026-10-27.md | 224 ++++++++++++++++++ 1 file changed, 224 insertions(+) create mode 100644 research/cultmesh-garden-path/prior-art-2026-10-27.md diff --git a/research/cultmesh-garden-path/prior-art-2026-10-27.md b/research/cultmesh-garden-path/prior-art-2026-10-27.md new file mode 100644 index 00000000..034d5b16 --- /dev/null +++ b/research/cultmesh-garden-path/prior-art-2026-10-27.md @@ -0,0 +1,224 @@ +# Garden-path multiplayer frameworks: developer ergonomics and scaling architecture (prior art) + +Date: 2026-10-27. Read-only Eyes pass. Facts with evidence pointers; no recommendation. + +**Serves** the CultMesh product direction, operator 2026-10-27, verbatim: + +> "the value is in solving the multiplayer scaling problem for indie developers in an ergonomic fashion. Having one authoritative server is fine, up to a point, but there's no real open source playbook on how to ship an MMO, and existing solutions like SpacetimeDB have a huge ergonomics gap. I want CultMesh to feel like magic: as a garden path, you annotate your domain POCOs and simulation code and declare your authority structure (I see no reason why we couldn't support server-authoritative and trusted co-op as a configurable subset of the much harder problem we're aiming at ...), and it'll all just work without the developer needing to understand networking deeply." + +Companion (not repeated here): `F:\Projects\CultLib\research\witness-authoritative-networking\prior-art-2026-10-26.md` (consensus, BFT, P2P anti-cheat). + +## Tags and method + +- VERIFIED: read in a fetched source this pass (URL given). Fetching was through a summarising fetch tool; code snippets are as that tool returned them and some are short fragments, not whole listings. +- SECONDARY: from search-result summaries, forum/HN threads, news, Wikipedia, or vendor-adjacent blogs. +- UNVERIFIED: recalled or inferred; no source read this pass. +- Many official pages returned only tables of contents or 404 (Unreal replication pages, Nakama concept pages, FishNet prediction, NGO NetworkVariable, SpatialOS docs, Veloren ECS chapter). Those gaps are listed per system and not filled from memory unless tagged UNVERIFIED. +- HN comment content is opinion by named commenters, relayed as paraphrase. + +--- + +## 1. SpacetimeDB (Clockwork Labs) + +**What the dev writes.** +- State: tables are annotated structs. Rust `#[spacetimedb::table(accessor = person, public)]` on `pub struct Person`, with `#[primary_key]`, `#[index(btree)]`. C# `[SpacetimeDB.Table(Accessor = "Person", Public = true)] public partial struct Person`, `[SpacetimeDB.PrimaryKey]`, `[SpacetimeDB.Index.BTree]`. VERIFIED (https://spacetimedb.com/docs/tables). +- Logic: reducers are the only way to mutate tables; each is a transaction, rolled back on error. Rust: `pub fn create_user(ctx: &ReducerContext, name: String, email: String) -> Result<(), String>`. TypeScript: `spacetimedb.reducer({ name: t.string(), email: t.string() }, (ctx, {name, email}) => {...})`. VERIFIED (https://spacetimedb.com/docs/functions/reducers). +- Client reads: subscriptions; "Query builders are the recommended default across SDKs, with raw SQL available" e.g. `ctx.subscriptionBuilder().subscribe([tables.user, tables.message])`, `tables.shopItems.where(r => r.requiredLevel.lte(5))`. VERIFIED (https://spacetimedb.com/docs/clients/subscriptions). +- Modules in Rust, C#, TypeScript, C++; app logic is uploaded into the database and clients connect to it directly. VERIFIED (https://github.com/clockworklabs/SpacetimeDB). + +**Infers vs requires.** Infers: wire sync of subscribed rows, rollback on reducer error, persistence (commit log). Requires: restructuring game/simulation code into tables + reducers; the dev writes all netcode above that (prediction, interpolation, lag masking). Reducer rules: no network or filesystem, global/static variables are undefined behaviour, "Never use external random number generators"; context supplies `ctx.sender`, a per-reducer-consistent timestamp, and a deterministic RNG. VERIFIED (reducers and reducer-context docs). + +**Authority.** One model: the database/module is the sole authority; clients call reducers. No trusted-co-op or client-authority mode in what was read. `ctx.sender` identity is the access hook ("Access checks can be asserted at the start of a function", BitCraft article). VERIFIED (https://bitcraftonline.com/news/spacetimedb-and-bitcraft). Peer-authority: not offered (UNVERIFIED beyond what was read). + +**Scaling.** +- "each database is a single-threaded actor"; replication is for availability, "replicated databases achieve the same throughput as unreplicated databases." VERIFIED (https://spacetimedb.com/blog/how-does-spacetime-scale). +- Scale-out is by many databases, developer-chosen: "Databases can be created as children of other databases"; "transactions against different databases can execute concurrently without coordination." Same source. +- Inter-database calls: async IDC and tiered storage slated 2026-10-31 (planned, not shipped as of this pass); sync IDC with two-phase commit, read replicas, and intra-database partitions are "planned." Same source. Table data lives in memory on the leader. Same source. +- BitCraft: "many SpacetimeDB databases which handle a spatial partition in the world"; partitioning is built on top of SpacetimeDB, not within it; each database limited to one machine's memory. VERIFIED (BitCraft article above). Peak concurrency under 5,000 players per an HN commenter (Rohansi) — SECONDARY (https://hn.svelte.dev/item/49563772). +- Interest management: the subscription query is the mechanism; docs warn overlapping/non-indexable filters (`ne`) cost extra. VERIFIED (subscriptions doc). No built-in spatial AOI primitive was seen (UNVERIFIED that none exists). +- Authority handoff between databases: none in shipped form (see IDC above). + +**Determinism.** Only within reducers (RNG, timestamp from context). No client-side replay requirement because there is no client prediction. VERIFIED. + +**Prediction.** None built in. Open issue "Client-side prediction" (4 reactions/comments) and "testing reducers" in the issue list. VERIFIED (https://github.com/clockworklabs/SpacetimeDB/issues sorted by reactions; the numbers might be comment counts, the tool could not tell). HN: commenter gafferongames called planning lag-masking netcode as a TODO "a bad sign" and said adoption means "restructuring the game server and simulation to fit the database's programming model"; manas96 said networked physics needs prediction. SECONDARY (https://hn.svelte.dev/item/43631822). + +**Persistence / schema evolution.** Persistence default (WAL, in-memory working set; 2.0 holds subscription updates until durable by default, opt out `withConfirmedReads(false)`). VERIFIED (GitHub README). Auto-migration allows adding tables/indexes/reducers, appending columns with defaults; `spacetime publish --break-clients` for breaking changes; no general schema-modifying migrations: docs recommend adding a new table and lazily migrating rows from the old one. SECONDARY (search summary of https://spacetimedb.com/docs/databases/automatic-migrations and /incremental-migrations; pages themselves not read). + +**License.** BSL 1.1, converts to AGPLv3 with linking exception "after a few years" (4-year period cited; change date not on the page; HN commenter magicmicah85 says each release converts 5 years after publication). Commenters: BSL limits production to one instance (themgt, _huayra_) — SECONDARY. README license text VERIFIED; instance-limit claim SECONDARY. + +**Known complaints (all SECONDARY, HN/forums):** +- 2.0 thread (https://hn.svelte.dev/item/49378933): reducers run under a lock (cmrdporcupine confirms from source); nemothekid "2015-era React Flux in Rust around a mutex"; Devont: vendor lock-in, feature churn, weak migration tooling, no LTS track; toolslive: user code in the DB raises crash/infinite-loop trust problems; benchmark credibility disputed (slopinthebag, Tostino, sabot90260). +- 2025 thread (https://hn.svelte.dev/item/43631822): beders objected to schema defined by struct annotations; hesdeadjim called $0.28/GB egress brutal (gafferongames: non-starter at 100k CCU); LarsDu88/bob1029 on scaling. +- Scaling thread (https://hn.svelte.dev/item/49563772): horizontal story is "separate databases the developer chooses" (search summary); durability disputed by rockwotj, rebutted by cloutiertyler. +- Issue list top entries: Golang support, QUIC transport, Godot SDK, Dart, Elixir (https://github.com/clockworklabs/SpacetimeDB/issues). VERIFIED. +- Which of these the operator means by "ergonomics gap" is not stated in sources; the gap as documented above is: client prediction/interpolation not provided, game code must be re-shaped into reducers, scale-out partitioning is the developer's own design. + +--- + +## 2. Croquet / Multisynq + +**What the dev writes.** Model (replicated, deterministic) and View (local) classes: +```js +class MyModel extends Multisynq.Model { init() { ... } } +MyModel.register("MyModel"); +class MyView extends Multisynq.View { constructor(model){ super(model); } update(time){ ... } } +``` +Events: `publish(scope, event, data)` / `subscribe(scope, event, handler)`; `this.future(100).step()` schedules in simulation time. VERIFIED (https://multisynq.github.io/multisynq-client/). + +**Infers vs requires.** Infers: state replication (no state on the wire; every client runs the Model), snapshots for late joiners, ordering. Requires: Model self-contained, no functions stored (must be snapshot-serialisable), no async, Views never write the Model; `Math.random()` in Model is seeded identically on all replicas. `init()` runs only on first creation; joiners restore from snapshot, so classes must `register()`. VERIFIED (same page; https://github.com/multisynq/multisynq-client). + +**Authority.** Not authority-by-node: the reflector is a clock/sequencer, "timestamps every event and advances simulation time"; heartbeats 20/s by default. VERIFIED (docs page above). All replicas are peers of equal standing; no designated state owner. Cheating: patents/mailing list say replicas stay in sync only if all run identical code (SECONDARY, USPTO filings and squeak-dev). + +**Scaling.** Single session = single replicated island; reflector hosted on a "DePIN network" server near the first user. VERIFIED (README). Large-world / model-size / snapshot-cost limits: not found (UNVERIFIED). Every client must hold and simulate the entire Model (follows from design; VERIFIED as description). + +**Determinism.** The whole Model; enforced by JavaScript VM conventions, not compiler. Origin Croquet used a bit-identical VM (SECONDARY, patents). + +**Prediction.** None needed: input events are sequenced by the reflector, and clients run ahead of the sequence by simulating only known-ordered messages (no rollback; SECONDARY, squeak-dev post says "without need for rollbacks or consensus"). + +**Persistence / schema.** Snapshot is the persistence unit (VERIFIED as join mechanism). Schema evolution: not found. + +**License.** `multisynq-client` repo Apache 2.0 and **archived read-only**. VERIFIED (https://github.com/multisynq/multisynq-client). Why archived: not stated in the page. + +**Complaints.** None found in this pass beyond the archival status. + +--- + +## 3. Photon Fusion 2 and Photon Quantum + +**Fusion what the dev writes.** Attribute-annotated properties on `NetworkBehaviour`; logic in `FixedUpdateNetwork`; input as `INetworkInput` struct: +```csharp +public class PlayerBehaviour : NetworkBehaviour { + [Networked] public float Health { get; set; } = 100; + public override void FixedUpdateNetwork() { Health -= Runner.DeltaTime; } +} +``` +RPC: `[Rpc(RpcSources.InputAuthority, RpcTargets.StateAuthority)]`. VERIFIED (https://doc.photonengine.com/fusion/current/manual/data-transfer/networked-properties and /fusion-intro). Rules: leave `[Networked]` as auto-property, change state in `FixedUpdateNetwork`, only supported blittable-ish types, collections need `[Capacity]`. VERIFIED. + +**Fusion authority.** Same API, three topologies ("Modes"): Dedicated Server (server has exclusive State Authority), Client Host (host holds it, "price of the state authority's trustworthiness"), Shared Authority (each client has State Authority over what it spawns; the Photon Room "controls changes of state authority and holds a complete copy"). VERIFIED (https://doc.photonengine.com/fusion/current/manual/network-topologies). The page says Server and Host share one programming approach; Shared has its own tutorial series. VERIFIED. Interest-management differences per mode exist: Behaviour Interest `ReplicateTo()` not available in Shared; one AOI per player in Shared. VERIFIED (https://doc.photonengine.com/fusion/current/manual/interest-management). So: one API, behaviour diverges by mode. + +**Fusion scaling/prediction.** Client-side prediction and lag compensation "out of the box"; configurable area-of-interest ("Scheduling and Interest Management" feature flag; `Runner.AddPlayerAreaOfInterest()`; per-object `ObjectInterest` Area/Global/Explicit). VERIFIED. Scale-out past one room/server: not described in pages read (UNVERIFIED). Handoff of state authority within Shared mode is room-controlled (VERIFIED above). + +**Quantum what the dev writes.** Data in `.qtn` DSL generated into C#: `component Resources { Int32 Mana; FP Health; }`; stateless systems `Update(Frame frame)` with `frame.Filter<...>()`. VERIFIED (https://doc.photonengine.com/quantum/current/quantum-intro). +- Determinism tax: "Be stateless: no mutable fields should be declared in systems"; "Quantum only guarantees determinism if all (mutable) game state data is fully contained in the Frame instance"; events must not drive gameplay; use provided fixed-point math, RNG, physics, pathfinding; no heap allocation at runtime. VERIFIED (https://doc.photonengine.com/quantum/current/manual/quantum-ecs/systems and intro). Explicit "no floats" sentence not found in fetched text. +- Model: input-only exchange, local prediction, rollback by re-simulation, game-agnostic server component syncs clocks; an authoritative "referee" simulation can be added. VERIFIED (intro). Anti-cheat mechanism: not read. + +**License/cost.** Both "free for development", paid beyond a free tier; terms not read. A forum post reports differing free-CCU numbers between web and Asset Store (20 vs 100) — SECONDARY, undated. Source availability of Fusion/Quantum: UNVERIFIED (not stated in pages read). + +**Complaints.** Not researched beyond the above (UNVERIFIED). + +--- + +## 4. Unity Netcode for GameObjects (NGO) and Netcode for Entities (N4E) + +**NGO.** What dev writes: `NetworkBehaviour`, `NetworkVariable`, RPCs (code not retrieved; the NGO pages 301-redirected and returned landing text). The following is VERIFIED from https://mp-docs.dl.it.unity3d.com/netcode/current/basics/ownership/: default is client-server where the server holds authority (`IsServer`); an optional **distributed authority** topology where "authority over NetworkObjects isn't bound to a single server, but distributed across clients", "there's no concept of an authoritative server" and `HasAuthority` is the check; state should live in NetworkVariables with owner-write/everyone-read; ownership flags `None`, `Distributable` (auto-redistributed on join/leave), `Transferable`, `RequestRequired`, `SessionOwner`; `SetOwnershipLock`. So: one component API, two topologies chosen at session creation, where code written for one must use `IsServer` vs `HasAuthority` (VERIFIED statement that `IsServer` works only in client-server). A Unity issue-tracker report (SECONDARY) says NetworkVariable values can be lost when ownership is transferred immediately after a write in distributed authority. License: repo points to LICENSE.md; type not read (UNVERIFIED; commonly MIT). Distributed-authority hosting service pricing: not found. + +**N4E.** "a server authoritive with client prediction framework", built on ECS. VERIFIED (landing page). Ghosts: server-simulated entities; `[GhostField(Quantization=1000)] public float MyFloatField;` only marked fields replicate; Supported/Default Ghost Mode (Interpolated, Predicted, Owner predicted); Importance, Static/Dynamic optimisation. VERIFIED (https://docs.unity3d.com/Packages/com.unity.netcode@1.3/manual/ghost-snapshots.html). Interest: **Relevancy** (`GhostRelevancyMode` Disabled/SetIsRelevant/SetIsIrrelevant; "Use Relevancy to avoid replicating entities that the player can neither see, nor interact with") plus distance-based **importance scaling** per chunk; snapshot size caps `NetworkStreamSnapshotTargetSize`, `MaxSendEntities`, etc. VERIFIED (.../optimizations.html). Prediction: the dev opts per ghost via mode and writes predicted systems in ECS (details of the prediction loop not read; UNVERIFIED). Authority handoff between servers: none seen. + +--- + +## 5. Mirror and FishNet + +**Mirror.** Dev writes `NetworkBehaviour` with `SyncVar`, `[Command]`, `[ClientRpc]`, `[TargetRpc]`; snippet: an `Enemy` with `[SyncVar] int health = 100`, `CmdShoot` reducing it on the server. VERIFIED (https://mirror-networking.gitbook.io/docs/manual/guides/synchronization/syncvars; listing summarised by tool). Authority: server-authoritative by default; client authority via flags (UNVERIFIED on this page). Interest management components added to the NetworkManager: Spatial Hashing, Hex Spatial Hashing, Distance, Scene, Scene Distance, Team, Match, Custom. VERIFIED (https://mirror-networking.gitbook.io/docs/manual/interest-management). Scaling claims (vendor, self-reported, no methodology): Inferna >1,000 CCU across multiple instances, Another Dungeon 5,000 CCU, benchmarks 400–800 CCU. VERIFIED as claims (https://github.com/MirrorNetworking/Mirror). Prediction listed "Researching", Lag compensation/Cheat detection Beta, Bitpacking researching. VERIFIED (same page). License MIT. VERIFIED. Cross-server handoff: none (multiple instances, no migration documented). + +**FishNet.** Dev writes `[ServerRpc]` / `[ObserversRpc]` (benchmark snippet) plus SyncTypes; server-authoritative by design with host mode; its own movement tutorial uses client-authoritative `NetworkTransform` and warns of speed hacks/teleports. VERIFIED (https://fish-networking.gitbook.io/docs/llms-full.txt, first 100k chars of 427k read). Built-in client-side prediction and rigidbody prediction; AOI with multiple conditions; paid Pro tier lists lag compensation, LOD, code stripping, extrapolation, Yak. VERIFIED. "no limit on concurrent users" for free use. VERIFIED. License type: not shown (UNVERIFIED). Prediction V2 details: not in fetched portion. + +--- + +## 6. Unreal replication and Iris + +**What the dev writes.** `UPROPERTY(Replicated)`, `GetLifetimeReplicatedProps`, RPC specifiers Server/Client/NetMulticast, `HasAuthority`, `NetUpdateFrequency`, dormancy (the replication-basics page returned only a table of contents; names VERIFIED as headings). Description: "The server ... holds the one, true, authoritative game state"; replicated, RepNotify properties; actors need `bReplicates`; creation, destruction and basic movement replicate automatically, everything else must be designated. VERIFIED (https://dev.epicgames.com/documentation/en-us/unreal-engine/networking-overview-for-unreal-engine). Authority model: server only; listen-server host is the same model (UNVERIFIED on page). + +**Interest.** Generic system: per-connection **relevancy**, dormancy, priority. Iris: "filtering controls the connections an actor replicates to" plus prioritisation, quantised full copy of replicated state, opt-in, labelled **Experimental**, toggle `-UseIrisReplication=1`; claims larger worlds and higher player counts, built from Fortnite Battle Royale experience (100 players/instance). VERIFIED as claims (https://dev.epicgames.com/documentation/en-us/unreal-engine/introduction-to-iris-in-unreal-engine). Opting in requires game code to use new engine APIs; existing properties/RPCs compatible with minor modifications. VERIFIED. + +**Prediction.** Overview page does not describe it beyond pointing to Character Movement; Network Prediction plugin page returned only headings (UNVERIFIED status). **Scale-out:** no multi-server world in engine; Pax Dei (below) builds zone servers on Kubernetes around it (SECONDARY, vendor FAQ). Licensing: UNVERIFIED this pass (source-available EULA with royalty, from memory). + +--- + +## 7. Colyseus + +Dev writes: schema classes and rooms. +```ts +import { Schema, type } from "@colyseus/schema"; +export class MyState extends Schema { @type("string") currentTurn: string; } +``` +Room has `maxClients`, `state = new MyState()`, `onCreate/onJoin/onLeave/onDispose`, a `messages` handler object. VERIFIED (https://docs.colyseus.io/state/schema and https://docs.colyseus.io/). Sync: assign state to room, changes sent as tick patches, full state on join; a Schema holds at most 63 synchronisable fields (nest to exceed). VERIFIED. Authority: server-authoritative rooms (page says implied, not stated). Scale: "Rooms are equally distributed across the available processes", each room lives in one process, Redis presence/driver required for multi-process, load balancer entry point; per-process max players left to FAQ. VERIFIED (https://docs.colyseus.io/scalability). No cross-room shared state documented (page silent). No prediction, no spatial interest management (room = interest scope; UNVERIFIED that none exists). MIT; "10 to 10,000+ CCU" is a vendor claim; roadmap to 1.0 linked; sustainability via Colyseus Cloud. VERIFIED (https://github.com/colyseus/colyseus). + +--- + +## 8. Nakama (Heroic Labs) + +Dev writes server modules in Go, Lua or TypeScript/JS ("recommends the JavaScript VM") and an authoritative **match handler** with seven functions: Match Init, Join Attempt, Join, Leave, Loop, Terminate, Signal; the loop runs at a developer-set tick rate (e.g. 10/s = 100 ms budget; if loops fall behind the server catches up, then ends the match). VERIFIED (https://heroiclabs.com/docs/nakama/concepts/multiplayer/authoritative/). Dev owns match state and all sync/prediction in code; framework supplies accounts, storage, matchmaking, chat, leaderboards. VERIFIED (README). Scale: "A single Nakama node hosts each match and its state"; clustering "Enterprise only" replicates presences, balances matches, migration needs no code change. VERIFIED (same page). Apache-2.0, Go, requires CockroachDB/Postgres. VERIFIED (https://github.com/heroiclabs/nakama). Interest management, prediction: none documented in what was read. + +--- + +## 9. Roblox + +Dev writes Luau scripts against a replicated DataModel; "The Roblox server is the ultimate authority for maintaining the game's state"; replication covers the data model, physics, chat; client-to-server, server-to-client, server-to-all flows. VERIFIED (https://create.roblox.com/docs/projects/client-server). Interest management: `Workspace.StreamingEnabled` (default for new places): `StreamingMinRadius` 64, `StreamingTargetRadius` 1024, models Nonatomic/Atomic/Persistent/PersistentPerPlayer, replication focus defaults to the character; dev must make client scripts tolerate parts streaming in/out (`WaitForChild`, `PersistentLoaded`); `StreamingIntegrityMode` can pause gameplay in unloaded areas. VERIFIED (https://create.roblox.com/docs/workspace/streaming). Network ownership: unanchored parts auto-assigned to nearby clients; `SetNetworkOwner`; "Roblox cannot verify physics calculations when a client has ownership"; server must validate. VERIFIED (https://create.roblox.com/docs/physics/network-ownership). Prediction: not read. Scale-out: each place instance is one server (UNVERIFIED this pass; not in pages read). Not open source (UNVERIFIED). + +--- + +## 10. Improbable SpatialOS + +- Concepts (workers that each see and update a subset of the world, entities of components with schema-defined data, authority over components moved between workers, platform handles load balancing and persistence; locality of reference between virtual and datacenter proximity). SECONDARY (gamedev.net thread https://gamedev.net/forums/topic/689484-spatialos-single-shard-mmo, 80.lv, Cambridge talk abstract, a patent on handover). The official docs were not reachable; interest/checkout/zoning terms not confirmed. +- Timeline: 2017 open beta, $502m Series B, Worlds Adrift and Lazarus cancelled 2019, Unity ToS dispute 2019 (Improbable said managed services breached Unity's new terms; $25m Epic/Improbable fund), GDK for Unity repo archived 2022-01-18 with existing users pointed to a migration to "SpatialOS running on zeuz". VERIFIED (https://github.com/spatialos/gdk-for-unity) for the archive; timeline VERIFIED from https://en.wikipedia.org/wiki/Improbable_(company) (Wikipedia, so effectively SECONDARY). +- Why it failed commercially: no official postmortem found. Candidate factors in sources, all SECONDARY: the Unity ToS block (Variety, HN https://news.ycombinator.com/item?id=18874400); cloud lock-in to Google and unpublished per-use pricing, a developer (Soulbound Studios) moving to its own engine (HN, GDC coverage); forum judgments "almost unusable" and synchronous cross-entity waits being a "deal killer" for real-time (gamedev.net, informal). Improbable later pivoted to studios, defence, and Web3 (Wikipedia). +- Handoff/determinism/prediction: not documented in reachable sources. + +--- + +## 11. Hadean / MetaGravity + +- Hadean Aether Engine: "world's first distributed simulation engine", each core manages a chunk, neighbouring chunks communicate, runs on Azure; used for EVE: Aether Wars at GDC 2019 (3,852 human players, 14,274 total ships incl. AI clients, 10,412 peak combatants, 88,988 ships destroyed in one hour); partitioning details not given. VERIFIED as claims (https://fenris.com/news/2019/eve-aether-wars-successfully-achieves-groundbreaking-14-000-ship-battle); engine description SECONDARY (search summary of PR). +- MetaGravity: London, target 1M+ concurrent users; CEO Rashid Mansoor (earlier Hadean founder) contrasts "spatial partitioning" with its own "causal partitioning" algorithm. SECONDARY (job-board page and press summaries). Technical documentation: not found. Current status of both: UNVERIFIED. + +--- + +## 12. EVE Online and Dual Universe + +**EVE Online.** Tranquility "is split into a series of nodes"; solar systems are redistributed across nodes at daily downtime; busy systems (Jita) get dedicated capacity; spare nodes held in reserve for planned battles; a node overloaded by one system slows other systems on it. VERIFIED (https://www.eveonline.com/news/view/fleet-fight-notification-tool). Time dilation: per-node, slows "almost all in-space actions", floor 10% speed, timers like skill training unaffected. SECONDARY (EVE University wiki https://wiki.eveuniversity.org/Time_Dilation). The CCP page does not say "single shard"; the Python/SQL stack and node/proxy split were not confirmed (UNVERIFIED). Handoff: a solar system is the indivisible unit; moving between nodes happens only at downtime (VERIFIED), and a ship jumping between systems moves between their nodes (UNVERIFIED mechanics). + +**Dual Universe.** Server tech called **CSSC** (Continuous Single-Shard Cluster), not "CSSA"; "all players in one shared world, no instancing or zoning"; Lua scripting by players in-world; released 2022-09-27; delisted from Steam 2025-07-25, servers shut down 2025-08-27. VERIFIED (https://en.wikipedia.org/wiki/Dual_Universe) / SECONDARY. No internal architecture write-up found; a French report attributes closure to economy/content problems, not tech (SECONDARY). MyDU player-hosted server exists (SECONDARY). + +--- + +## 13. Open-source MMO server playbooks + +| Project | What it is | Evidence | Coherent playbook? | +|---|---|---|---| +| Astron | Distributed object server suite from Disney's OTP (2001–2013): DistributedObjects with fields, shared "DC file" protocol description with keywords (`ram`, `required`, `db`, `broadcast`, `clsend`, `ownsend`...), roles Message Director, Client Agent, State Server, Database Server, Database-State Server; hierarchy of zones with client "interest" requests. Modified BSD. "Development on Astron has been discontinued." VERIFIED (https://github.com/Astron/Astron). | Declarative state + routing keywords + interest by zone + persistence flag is the closest ancestor to the "annotate your POCOs" idea in this survey. | A coherent architecture, but discontinued and not a shipped-game playbook documented end to end. | +| AzerothCore / TrinityCore | WoW 3.3.5a emulators: separate auth server, world server, three MySQL databases (auth, world, characters), DB worker threads, modules. AGPLv3 / GPLv2 mix. SECONDARY (search summaries, https://trinitycore.atlassian.net, localtonet blog). | A forum thread on 15k+ CCU server topology had only speculation. Map-thread design not found. | Architecture of one monolithic realm per world server; reproduces a closed game, not a reusable playbook. | +| Ryzom Core | Open-source MMORPG framework with pre-built "shard framework meant to scale", since 2001, powers the commercial Ryzom. SECONDARY (search summary; wiki page returned empty). | | Possibly; not read. | +| Folia (Paper) | Minecraft server fork: nearby loaded chunks grouped into independent regions with own 20 TPS tick on a thread pool; no cross-region data access, cross-region work via RegionScheduler/EntityScheduler; plugin API broken (`teleportAsync`). VERIFIED (https://github.com/PaperMC/Folia). | Concrete evidence on the cost of regionised multithreading to existing user code. | A single-process technique, not a playbook. | +| Veloren | Open-source Rust voxel RPG; crates `server`, `client`, `common`, `network`. VERIFIED crate list (https://book.veloren.net/contributors/developers/codebase-structure.html); authority and scaling not covered by the page. | | Not shown. | +| Pax Dei (commercial, FAQ only) | Shards as independent world copies in one datacenter; zones simulated by dedicated Unreal servers on Kubernetes; zone transition moves connection to the adjacent zone server; ~150 players per zone server; overflow split into instances; no cross-boundary visibility. VERIFIED as claims (https://playpaxdei.com/en-us/faq/tech; the FAQ states conflicting shard-capacity figures). | Real zone-handoff design disclosed. | Not open source. | +| Others named in search results | ScalaMo (research), Free-MMORPG Unity framework (community). Project Darkstar/RedDwarf, Atavism, Open Match, Agones: searched, no results read. | | UNVERIFIED. | + +No source found that presents an end-to-end open-source recipe for shipping an MMO (state model, authority, interest, handoff, persistence, deployment). Astron is the closest architectural description; none was found that is current and maintained. + +--- + +## 14. Design-question matrix + +"-" = not found in sources read (not a claim of absence). + +| Question | SpacetimeDB | Multisynq | Fusion 2 / Quantum | NGO / N4E | Mirror / FishNet | Unreal / Iris | Colyseus | Nakama | Roblox | SpatialOS | EVE / Astron | +|---|---|---|---|---|---|---|---|---|---|---|---| +| Declaring state | Annotated struct = table (`#[table]`, `[Table]`) | Model class fields, `register()` | `[Networked]` property / `.qtn` DSL component | NetworkVariable / `[GhostField]` | `[SyncVar]` / SyncTypes | `UPROPERTY(Replicated)` | `@type` Schema (max 63 fields) | Dev-defined match state (code) | Instances in DataModel | Schema-defined components (SECONDARY) | Astron: DC file dclass fields with keywords; EVE: - | +| Declaring authority | Implicit: DB module; reducer checks `ctx.sender` | None: all replicas equal, reflector orders | Mode: Server / Host / Shared (State Authority, Input Authority) | NGO: client-server or distributed authority + ownership flags; N4E: server | Server default; client-auth flags/NetworkTransform | Server; `HasAuthority` | Room server | Match handler on server | Server; network ownership of physics | Workers hold authority per component (SECONDARY) | Astron: field keywords `clsend/ownsend/broadcast`; EVE: node owns system | +| Prediction / rollback opt-in | None; open issue | None needed (sequenced input) | Fusion: built in; Quantum: mandatory rollback | N4E: per-ghost mode + predicted systems; NGO: - | FishNet: built in; Mirror: researching | Character movement; Network Prediction plugin status - | None | None | - | - | - | +| Interest management | Subscription queries | None (all state everywhere) | AOI (`ObjectInterest`, `AddPlayerAreaOfInterest`), limited in Shared | N4E: relevancy + importance; NGO: - | Mirror: spatial hash/distance/scene/team; FishNet: observer conditions | Relevancy, Iris filtering | Room = scope | Match presences | StreamingEnabled radii | Worker checkout (not confirmed) | Astron: zone interest | +| Authority handoff between shards | Planned IDC (2026-10-31, async); sync IDC planned | None | Shared-mode room reassigns state authority | NGO distributed authority ownership transfer; N4E: - | - | - (Pax Dei: zone transition on connection) | Rooms don't hand off | Match pinned to one node | - | Authority handover (patent, SECONDARY) | EVE: system fixed to node, rebalanced at downtime | +| Persistence | Built in WAL, in-memory | Snapshot | - | - | - | - | - | Storage + DB backend | Roblox services (-) | Platform persistence (SECONDARY) | Astron: `db` keyword + DB server | +| Schema evolution | Auto-migrate subset, `--break-clients`, new-table pattern | - | - | - | - | - | - | - | - | - | Astron: DC file id order = 16-bit ids (VERIFIED) | +| Determinism tax on dev code | Reducers: no I/O, context RNG/time | Whole Model: no I/O/functions/async | Fusion: tick-based code; Quantum: stateless systems, fixed-point, all state in Frame | N4E: prediction systems rerun | Low | Low | Low | Low | Low | - | - | +| Past one server | Many DBs, developer partitions | One session | Photon Room / server | Not described | Multiple instances | One instance (Pax Dei adds zones externally) | Processes + Redis, one room per process | Enterprise cluster | One server per place (UNVERIFIED) | Workers across machines | EVE nodes; Hadean chunks per core | +| One model or products | One model | One model | Fusion: one API, 3 modes; Quantum separate product | NGO: two topologies in one package; N4E separate stack | Separate libs | Single model | Single | Single | Single | Single | - | + +--- + +## 15. Facts bearing on the "configurable subset" claim (server-auth + trusted co-op as subsets) + +- Photon Fusion is a shipped example of server, client-host and shared-authority modes under one API, with documented divergences (Behaviour Interest absent in Shared; one AOI per player; the Shared tutorial series is separate). VERIFIED. +- NGO ships client-server and distributed authority in one package; the check you write changes (`IsServer` vs `HasAuthority`), and variable write permissions are configured per mode. VERIFIED. +- Multisynq/Croquet has no authority concept; Quantum's authority is input-driven determinism with an optional referee. VERIFIED. +- SpacetimeDB and Colyseus offer only the single-authority model. VERIFIED.