Research date: October 24, 2026.
The objective is an independent engine with comparable capabilities and a similar creation experience. Spawn's proprietary implementation is not available in this workspace. Public documentation supports a capability target and several architectural clues; it does not establish a complete reproducible specification.
#Evidence categories
Current documentation means the page was opened or downloaded during this research. Indexed technical material means a first-party page's technical text was available in search results, while the current page omitted some or all of that detail. Inference identifies an interpretation. These categories must remain distinct when making implementation decisions.
| Subject | Evidence and confidence | Implication for this project |
|---|---|---|
| World format | Current documentation describes Git-backed worlds, YAML object definitions, behavior modules, HTML UI, and separately uploaded assets. Authoring reference | Own a versioned, data-driven world format and a documented SDK. |
| Running edits | Current authoring documentation describes pushes reaching open development sessions. The current version 6 announcement distinguishes editing from published versions. Authoring reference, version 6 | Separate source revisions, live development revisions, and immutable releases. |
| Renderer | Current Lume announcement confirms an in-house renderer. Indexed first-party material calls it WebGPU-only. Lume, indexed technical description | A custom WebGPU backend is a credible architectural target; exact algorithms and current fallback behavior remain unverified. |
| Simulation ownership | Indexed first-party material describes one simulator per entity, running in an owner's browser or a browser holding a shared simulation role, with a relay that does not simulate gameplay. It names a default 30 Hz step and deterministic TypeScript Mantle physics. Technical description | Implement a browser-owned relay profile and test its failure modes explicitly. Do not assume it provides trusted competitive outcomes. |
| Data organization | Indexed version 5 notes describe sparse-set ECS columns, change tracking, and component-specific replication. Version 5 | Use component metadata and a single mutation path to serve simulation, replication, and presentation. |
| Worker separation | Indexed technical notes describe simulation-to-renderer messaging and renderer-side composition of bone attachments. Version 5.2.10 | Keep presentation independent of simulation cadence; attach equipment to the displayed skeleton pose. |
| Recovery | Indexed technical notes describe relay journal sequences, checkpoint pointers, and periodic announcements that repair missed updates. Version 5.2.11 | Recovery needs a durable baseline and repeatable convergence, beyond reconnecting a socket. |
| Broad capabilities | Current version 6 describes streamed places, visible portals, persistent state, terrain editing, vehicles, physics, touch controls, and collaborative authoring. Version 6 | Track these as separate acceptance targets. Their announced scale is not a benchmark for our engine. |
| Hosting | Indexed notes mention workerd DO and relay-do.ts. Version 5.2.11 |
Cloudflare Durable Objects are a plausible implementation detail, not a verified production topology or a requirement for this project. |
#Material uncertainties
Spawn's public material spans engine versions and different execution paths. Older technical notes discuss server/client correction; other material describes browser-owned simulation. They must not be combined into one supposedly verified architecture. The exact engine pin and authority profile of the user's linked world were not established.
The versioned engine reference URL required authentication during a read attempt. No account was created and no authenticated source was obtained. The published API schema is an integration contract, not the internal engine or relay protocol. API schema
Unknowns include the complete component schema, physics solver, material compiler, relay protocol, host election algorithm, production database layout, asset processing infrastructure, and cost per concurrent player. This plan makes explicit choices for each relevant responsibility rather than attributing invented choices to Spawn.
The initial explanation in this conversation overgeneralized conventional prediction and WebGL. The corrected interpretation is that multiple designs exist in the published record, including WebGPU rendering and browser-owned simulation. The implementation plan supports the desired behavior without depending on an unverified private design.
#Standards and reusable implementation references
These are engineering references, not evidence that Spawn uses the same libraries.
- WebGPU API: browser GPU interface and capability detection.
- OffscreenCanvas: worker-compatible canvas rendering.
- SharedArrayBuffer: shared memory and deployment prerequisites.
- WebSocket: reliable browser transport; application queues still need bounds.
- glTF: standard delivery format for models, materials, and animation.
- Rapier determinism: deterministic physics requires identical versions, construction order, inputs, and compatible surrounding math.
- Colyseus synchronization, prediction, and visibility: useful comparisons for the engine's own protocol and authority contracts.
- Cloudflare WebSocket architecture: a possible later relay adapter. It is not the initial deployment dependency.
#Research policy during implementation
Use public specifications, documented interfaces, and independently written code. Preserve upstream notices for dependencies and assets. Do not depend on Spawn accounts, private endpoints, copyrighted art, branding, or copied behavior scripts for the engine to function. A newly obtained architectural fact changes a design only when it improves the stated requirements and passes an explicit decision review.