# One World #### 8.1 The Shard Problem Most MMOs are not one world. They are many copies of the same world. Server A's Stormwind and Server B's Stormwind are identical in geography but completely disconnected in population. Players on different servers cannot meet, trade, or fight. A thriving economy on one shard is invisible to another. A legendary battle that happened on Server C might as well not exist for the players on Server D. The community is fragmented—not by design, but by engineering necessity. The reason is simple. A traditional MMO server is simulating a 3D world in real time. Every player's position, every NPC's pathfinding, every physics interaction, every collision check, every projectile trajectory—all calculated server-side, sixty times per second. The server's CPU is the bottleneck. When too many players gather in one zone, the simulation cost spikes. The solution is sharding: split the player base across parallel instances and hope no one notices that half the community is missing. Some games mask this with cross-server matchmaking or instanced marketplaces. But the world itself remains fragmented. The dream of a single shared world—every player in the same space, contributing to the same history, participating in the same economy—has remained largely out of reach. #### 8.2 Why The Continuum Can Do What Others Cannot The Continuum's server is not simulating a 3D world. It does not calculate physics. It does not run collision detection. It does not pathfind for thousands of NPCs. It does not render a single pixel. What the server actually does: * **Serves video files.** Static assets, highly cacheable, distributable via peer-to-peer. A video of a forest path is an MP4 file. Once served, it is cached by every client that traverses that edge. * **Relays state changes through the message bus.** A player moves from one node to another—that is a discrete event, not a continuous coordinate stream. "Player moved to Node OldWatchtower\_04" is a few bytes. It does not need to be calculated. It just needs to be shared. * **Processes combat actions.** Combat is node-locked and real-time, but the actions are discrete events—"Player used heavy attack at timestamp X," "Enemy blocked at timestamp Y." The server validates timing and distributes results. It is not running a physics simulation. It is processing events. * **Runs the economic simulation.** Agent decisions, market clearing, price adjustments—these are computationally meaningful but they do not happen per frame. They happen when economic conditions change. The economy thinks in seconds and minutes, not milliseconds. The heavy lifting—video decoding, compositing, weather post-processing, character layering—all happens on the client. Every player's browser is their own renderer. The server never touches a pixel. This means the server's computational cost per player is dramatically lower than in a traditional MMO. The bottleneck is not CPU cycles spent simulating reality. It is bandwidth and message throughput—problems that scale horizontally with well-understood solutions. #### 8.3 One World, One Community The result is a single shared world for every player. **One economy.** The agent-based simulation operates on global supply and demand. Iron ore mined in the northern mountains affects sword prices in the southern ports. A trade route blockade in one region ripples across the entire world. There is no Server A economy and Server B economy. There is the economy, and every player participates in it. **One history.** The memory system stores events at nodes. A duel at the Old Watchtower. A guild's last stand at Sorrows Bridge. A proposal at the waterfall. These memories are visible to every player who visits those nodes, regardless of when they joined. History is not fragmented across shards. It is shared, cumulative, and permanent. **One community.** Every player can meet, trade, fight, and cooperate with every other player. Guilds recruit from the entire player base. Rivalries span the whole world. A reputation earned on one side of the continent follows you to the other. The community is not a collection of parallel populations. It is one population, inhabiting one world. #### 8.4 Honest Caveats A single world presents real challenges. The Continuum does not pretend they don't exist. It addresses them architecturally. **Combat at scale.** A guild battle with hundreds of players is a significant event for the message bus. But combat in The Continuum is naturally partitioned. Each engagement is an isolated instance between a small number of participants at specific nodes. Five hundred players in a war zone are not five hundred players in a single continuous physics space. They are distributed across dozens of discrete combat instances, each with a handful of combatants. The server load scales with the number of concurrent engagements, not the square of the total player count. This is an easier problem by design. **Video distribution and the peer network.** A single world means every player needs access to every video file. Serving all of this from central servers would be prohibitively expensive at scale. The Continuum uses peer-to-peer distribution within the continuumOS framework. Players who have visited a zone cache its videos. Players visiting for the first time retrieve those videos from nearby peers, not from a central CDN. The more popular a zone, the more peers have it cached, the faster it loads for newcomers. Popularity improves performance. And because serving video to other players is a real service with real costs, players who contribute their upload bandwidth are compensated. A portion of the infrastructure budget—money that would have gone to a CDN—is redirected to players who serve as peers. Your client reports how much data it has shared. At the end of each month, a small payment is calculated based on your contribution. It might cover your subscription. It might be pocket change. But it acknowledges a core principle: in The Continuum, contributing to the world is always rewarded. This is entirely opt-in. Players on fast, unmetered connections who want to support the world can enable peer serving. Players on limited connections or lower-end hardware simply don't. The central CDN remains as a fallback for cold content and non-peering players. The world works either way. But for those who participate, their home connection becomes part of the infrastructure that makes a single world possible. **Node crowding.** A thousand players at the same town square node is technically possible but visually chaotic. The compositor can only layer so many character videos before the scene becomes unreadable. Solutions include transparency reduction with crowd density, culling characters outside the player's field of view, and seamless sub-instancing for very dense gatherings—the marketplace splits into overlapping zones, all part of the same node, all visible to each other at the boundaries. These are user experience challenges, not architectural limitations, and they are solvable without fragmenting the world. #### 8.5 The Precedent EVE Online has run on a single shard for over two decades. Its players inhabit one universe, one economy, one history. This is not a coincidence of EVE's design—it is central to its identity. The stories EVE players tell each other are possible because everyone was there, or could have been. A market manipulation, a betrayal, a war that reshaped the galactic map—these events happened to the community, not to a subset of it. The Continuum aims for the same unity of community, achieved through a fundamentally different technical path. EVE manages its single shard through time dilation—slowing the simulation when too many players occupy one system. The Continuum does not need time dilation because there is no continuous simulation to slow down. The design that makes the world cinematic and node-based is the same design that makes a single shard feasible. The constraints are not obstacles to overcome. They are the reason it works. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://thecontinuum-1.gitbook.io/thecontinuum-docs/one-world.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.