Shared World Technology

Living World uses the real shape of Earth as its Blank Earth. Coastlines, mountains, rivers, water, terrain, and real distances remain, but human-made history starts blank. Cities, roads, borders, and companies appear in the simulation only where Living World players create them in each era.

The project may use several licensed data sources or map services rather than assuming one provider can supply everything. If a travel map still shows modern names or roads that cannot be removed, the interface must explain that only Living World markers and player-built records represent the game's actual settlements and infrastructure.

Detail follows the players

The map does not need maximum detail everywhere at once. A lightweight global view can handle choosing a region or following a long journey, while detailed terrain and local geometry load only around places a player visits, develops, or needs to inspect closely.

When someone settles an area, the service creates or retrieves the area's detailed world data and keeps the parts needed for lasting construction. Empty regions can remain inexpensive until players arrive, while developed regions retain their cities, roads, claims, history, and era-specific changes.

The map source is a technical and licensing choice, not the authority for Living World's history. The central world records decide what players have actually built, even when an external map image is temporarily used to help them navigate the planet.

Many games create supplies that cities need: food, tools, mail, drink, building materials, or other goods. Living World combines their results into manageable city totals instead of tracking every individual apple, plank, or parcel forever.

A producing game reports what kind of contribution it made and where it belongs. The central service checks and groups those results, then tells city, shop, or transport games only the shortages, opportunities, and conditions they need to play.

Transport links the local economies

Basic transport always moves some goods slowly, so a city cannot be ruined simply because no one currently plays a transport game. Player-run transport companies can do much better by studying what connected cities have, what they need, and which routes are worth serving.

A maintained road may let a company move more goods faster, while that company's traffic can make the road more valuable to the city builder. A transport player might even help fund an improvement, but the city developer remains responsible for accepting and carrying out work within that city's game.

The shared world presents these exchanges as modest bonuses and problems rather than one enormous spreadsheet. A baker may simply receive flour more reliably, while the transport player sees a profitable route and the city builder sees growing demand for a better road.

The central Living World service does the difficult work: it keeps track of Earth, eras, settlements, markets, roads, history, and the combined results of many players. Individual games remain focused on their own play and communicate through small, stable agreements about what they may send and receive.

Games ask; the world decides

A game sends a request such as a delivery result, a proposed city claim, or a completed road improvement. The central service checks the request, records the accepted fact once, updates the relevant part of the world, and prepares new information for the games that need it.

For example, a shop game might receive "more wealthy customers this evening" instead of the entire history of the city, every trade route, and thousands of raw scores. A city builder may receive a road-demand indicator, while a later-era game receives only the historic trace that survived.

The service updates the world in clear steps so games see a coherent state rather than half of one calculation. Read-only views can be rebuilt from accepted history if a temporary copy is lost, and delayed requests keep their honest status instead of being rewritten as if they always succeeded.

This separation keeps each game simpler and safer. A minigame can be repaired, replaced, or temporarily unavailable without rebuilding the world, and the world can change its heavy calculations without forcing every game app to download all of its internal data.

In one era, one active builder has City stewardship for a city location. The central service decides whether a proposed city footprint is free, suitable, and far enough from conflicting claims; the game cannot reserve land merely by drawing a marker.

A player begins with one builder-mode city for that account and era. Demonstrated success may later earn a capped mandate to manage another city. Other games may govern a wider county, run companies, open shops, or contribute services around it, but those roles do not quietly grant ownership of the city itself.

Cities outlive their current steward

The city belongs to the shared world rather than disappearing with its player. Stewardship can be transferred, handed over through an agreed process, placed into dormancy, lost after sustained abandonment, or opened for reclamation while the city's history remains.

Decline depends on what was built and how long it was maintained. A small settlement may leave little more than rubble, while a successful old city may survive as an unclaimed settlement that another player can repair and develop with newer technology.

Later-era players may clear ruins, build on old foundations, or choose a different nearby plan. A well-developed ancient city can provide a modest head start and story, but it cannot permanently reserve a future location for an absent player or destroy a smaller game attached to the place.

Living World's cities can be run by different players while a mayor or regional player handles wider policy. City stewards may send their real priorities to that political layer, or stay out of politics and let the world summarize what their city appears to need.

Power can be used badly—this is still a game

Political and company players may attempt fictional corruption, hide evidence, favour friends, or accept an improper deal. Lawful institutions, auditors, rivals, later administrations, and evidence from connected cities can discover it. Concealment may delay exposure, but never guarantees safety.

A finding can damage trust, policy, or efficiency and may open a separate investigation into another role held by the same player. It does not prove every connected city corrupt, and consequences eventually end. The objective is interesting political trouble, not a second career as a permanently disgraced municipal filing cabinet.

A player's phone, browser, clock, saved score, and network messages cannot be trusted automatically when they would change a world shared by everyone. They may be mistaken, edited, replayed, automated, or sent by a modified client.

The central service checks important results, limits their possible effect, and refuses suspicious or repeated submissions. Each game is allowed to request only the narrow kinds of change it owns; a tavern game cannot suddenly claim a city, move a road, or grant itself unlimited goods.

Protect the world without punishing ordinary play

Offline play remains useful and enjoyable. A player can keep local progress, practise, and unlock appropriate local rewards, but an unchecked result cannot quietly give a city, clan, company, or region an unfair world advantage.

Location features use the least precise information the game actually needs. Regional play and nearby cooperation should not expose a player's exact home, regular movements, or private location history to friends, neighbours, rivals, or other games.

Moderation and recovery actions must leave evidence and stay limited to their purpose. Security is not an excuse for hidden staff powers, secret pay-to-win influence, or collecting information merely because it might be interesting later.

Protect children first, without creating a secret surveillance state

Every player chat has accessible report and personal block or mute controls. Child-accessible chat receives stronger safety defaults and proportionate, disclosed automated screening. Credible grooming, exploitation, threats, or child endangerment can trigger an immediate account-wide emergency lock, urgent human review, evidence preservation, and lawful reporting to the appropriate authorities.

An automated flag is not a permanent sentence. Players can appeal, reviewers can reverse mistakes, and restored accounts may receive clear temporary guardrails. Deliberately weaponising the report system is also misconduct, but a good-faith report is protected even when the evidence does not establish a violation.

What it is

Players should be able to try a suitable Living World game without creating an account first. Guest play can keep local progress while someone decides whether the game deserves a permanent place on their device. A shared account becomes useful later for moving supported saves between devices, connecting several Living World games, and using features that genuinely need an online identity.

Why it matters

One account should reduce repeated sign-ins without becoming a silent permission slip. Signing in through Apple, Google, Steam, or another provider may prove control of that provider account, but it does not automatically approve chat, location features, purchases, data sharing, or access intended for an older age group.

What a player might see

If a phone contains guest progress while the chosen account already has an online save, linking must never silently overwrite either save or quietly pick a winner. The player sees a clear comparison, a tested merge where that is genuinely safe, or a choice between the two histories. A failed or interrupted link keeps both saves intact, and world-facing rewards are never duplicated merely because the same request was sent twice.

The same account can provide an overview of a player's own games, saves, and eligible conversations while each game receives only the access information it needs. A small game may know that chat is unavailable, for example, without receiving a birthday, identity document, guardian record, or private moderation history.

Where it honestly stands today

This is a planned safety and continuity design. Living World does not yet operate a live shared account service or hold real player accounts. The first prototypes can use local guest progress while the account boundary, data responsibilities, recovery rules, and family controls are tested before any real service is opened.

Living World may include small games for broad audiences and larger games with very different content or social features. Each game therefore receives its own honest age rating and feature rules instead of pretending that one birthday question solves every safety problem.

Start with the least information needed

A suitable game may allow local guest play without asking for a real name. Connected features can ask for stronger evidence only when the feature genuinely needs it. An app-store age band or supervised-account signal can help, but it does not automatically grant Living World permission to use location, enable chat, make purchases, or combine data across games.

Where a child needs guardian permission, that permission is specific and understandable. A guardian can approve one feature, refuse another, review what is active, and withdraw approval later. The child should still have a useful age-appropriate experience wherever that is safe and lawful.

Games receive only the small answer they need, such as whether chat is currently allowed. They do not receive a child's birthday, identity documents, provider secrets, guardian evidence, or the private reason behind a restriction.

Living World games may have their own local conversations: a city council talks about city business, a transport company discusses routes, and a small arcade game may need nothing more complicated than a friendly group chat.

When games cooperate, an eligible conversation can appear in more than one of them. The messages are not copied into several competing histories. Each game displays the same conversation through its own interface, with the same members, blocks, retention rules, and moderation protections. Inside a particular game, the player sees only conversations related to that game.

Players can also sign in to their Living World account and see one combined inbox for all conversations they are currently entitled to access across their games. Every entry explains where the conversation came from and why it is available. A shared inbox is convenient; it is not a master key to everyone else's city hall, clan cupboard, or suspiciously well-organised pigeon committee.

Every Living World chat gives players a clear way to report a conversation and to block or mute another account. Reports preserve enough of the conversation to understand what happened, instead of asking a reviewer to judge one carefully cropped sentence and a dramatic pointing finger.

Protect first; decide carefully

Automated screening can identify harassment, threats, grooming, exploitation, and repeated abuse. It may place a short safety lock on the reported account across Living World when delay would put people at risk. A human then reviews every adverse flag, and only a human can impose a permanent account lockout.

Players can appeal and explain their case. A restored account may return with temporary guardrails such as slower chat, limited contact, or a probation period. These restrictions have a reason, duration, and clear way out. Repeated deliberate misuse of reports is also misconduct, but an honest report does not become punishable simply because a reviewer could not prove it.

Several earlier reports that were not upheld may cause an extra “please check the rule” prompt, but never close the report button. If the current text separately suggests serious distress, the player may receive a private, voluntary offer of support. That suggestion is not a diagnosis and does not make the report less credible.

Child safety receives the fastest route. Credible grooming, exploitation, or danger triggers immediate protection, evidence preservation, urgent human review, and lawful contact with the appropriate authorities.

Living World will use the backup and recovery features supplied by its eventual hosting provider, but it will not trust one enormous emergency button as its entire recovery plan. The service also needs its own way to recover one account, one city, one area, one game, one system, or a complete world at a chosen point in time.

A backup is not proven until it restores

Selected backups are restored into an isolated mirror that cannot write to the live world. The restored records, histories, links, and rebuilt game views are compared with the matching point-in-time snapshot. Differences are recorded and investigated; a cheerful green message from a supplier is useful, but it is not the same thing as proving that Amsterdam still owns all of its roads.

Even a fully verified mirror is not pushed into production by the recovery tool. Living World must separately accept the evidence and, if a real cutover is needed, authorize that destructive step through another controlled process.

Living World starts web-first for its game collections and smaller 2D games. The same underlying game can run in an ordinary browser, as an installable web app where supported, and as a carefully reviewed Android or Apple app.

The interface adapts rather than merely shrinking. A phone may use large touch targets and a focused portrait layout, while a tablet or desktop can show more information, wider maps, and keyboard or mouse controls without becoming a different game with different rules.

Several small games may share one collection app so players do not need to install a separate store app for every short activity. The collection handles common sign-in, updates, accessibility, world connections, and navigation while each minigame keeps its own play loop.

Early prototypes will test which web approach works best before the project settles on one. A larger 3D or performance-heavy game may still use an engine built specifically for its target platforms when real testing shows that the web version cannot provide good controls, performance, reliability, or store integration.