Living worlds

Let decisions become shared history.

Living worlds is Naevum's design work for studios building shared game worlds, so that one player's choice changes what others find and generated events stay inside the world's rules.

  • Product builders
  • Living world
  • Consequential decisions
  • Simulation
Discuss a living-world collaboration
Inhabited reign, contributions and Chronicle. An illustrative game design: completed contributions change the world and enter its history.
Loading model
Technical descriptionsInteractive model unavailable. The static illustration and descriptions remain available.
Shared reign and world reference
Retain crowns, current world conditions and the next reign context.
Technical data

Inputs

Durably committed world change.

Retained history available to later choices.

Transformation

Retain crowns, current world conditions and the next reign context.

Retained state and outputs

Reign identity and crown/role context.

Durable world/player assets differ from ephemeral coordination.

Constraints

Durable world and player state remain separate from temporary coordination.

Campaign grammar and role distributor
Constrain a royal choice into structured role-specific tasks.
Technical data

Inputs

The Lantern Feast royal choice.

Current kingdom rules and reign identity.

Transformation

Constrain a royal choice into structured role-specific tasks.

Retained state and outputs

Permitted effects, economy limits and server-owned identity.

Distinct player roles and visible wicker stand-ins.

Constraints

The structured campaign follows declared world limits and identity rules.

Contribution work areas
Keep garden, bridge and market tasks independently in progress or complete.
Technical data

Inputs

Separate garden, bridge and market responsibilities.

Independently supplied progress/completion for each identified task.

Transformation

Keep garden, bridge and market tasks independently in progress or complete.

Retained state and outputs

Garden remains unchanged until its completion.

Bridge completion is independent of the other tasks.

Market work and actual contribution event.

Constraints

A proposed task does not complete a garden, bridge or market contribution.

Settlement assembly
Commit actual completed consequences under the authoritative world rules.
Technical data

Inputs

Only the actual completed branch with its task identity.

Server-owned settlement and economy rules.

Transformation

Commit actual completed consequences under the authoritative world rules.

Retained state and outputs

Proposed work and independent completion identity agree.

Pending, settled, refused and unavailable state remain distinct.

Constraints

Only the matching independently completed contribution can settle its consequence.

Chronicle and next-reign memory
Write from retained decisions/consequences and pass world history onward.
Technical data

Inputs

Settled events, not generated descriptions of hoped-for events.

Transformation

Write from retained decisions/consequences and pass world history onward.

Retained state and outputs

Recorded events precede prose; player identity remains separate.

The next reign inherits actual settled state.

Constraints

Recorded events precede the story, and only settled state passes into the next reign.

An illustrative game design: completed contributions change the world and enter its history.

Additional mechanisms are described in the technical reference.

What the research says

Convincing characters need firm rules

Generated characters now sound like real people, and public bodies fund shared simulated worlds. In both, the hard part is one agreed state: Everbloom settles each decision once on the server and retells its history from what was recorded.

Give a decision somewhere to go.

A shared world becomes interesting when choices reach other people and leave consequences they can recognize.

Design roles, responsibilities and persistent state together. Generated events can add variation inside a world grammar; players need to understand what changed and how their participation mattered.

The world needs continuity beneath the story.

Generation, identity and durable state have distinct jobs.

Validate the event

Check the campaign structure, permitted effects and economy constraints.

Commit the consequence

Keep server-owned identity and durable settlement coherent across retries.

Retell from evidence

A shared history should derive from the recorded decisions of that world.

May a generated event change the shared world?

A creative director decides which generated events may change the shared map; the server settles each one once. Illustrative, with a synthetic kingdom.

  1. 1 of 5The creative director sets what generated events may touch: harvests, weather and festivals, and no player's home.Decision: Which parts of the world generated events may change.
  2. 2 of 5A generated event proposes a poor harvest in the eastern villages.
  3. 3 of 5The world rules check finds the event inside its limits, and the server settles it once.
  4. 4 of 5The village map changes for every player on every server, and unrest rises where the harvest fell.
  5. 5 of 5The Chronicle records the event, so players can see what changed and why, and the creative director reviews it there.
Select any part of the drawingScroll to step · Esc to skipFig. 1
  1. 1 of 4A player delivers grain to the eastern villages just as a server restarts.
  2. 2 of 4The server settles the delivery once, and the harvest store rises.
  3. 3 of 4The restart sends the same delivery again; the receipt check finds it already settled, and the store does not rise twice.
  4. 4 of 4The Chronicle records one delivery, and the creative director reads the retry in the record and keeps the rule as it is.Decision: Whether the retry rule needs changing.
Select any part of the drawingScroll to step · Esc to skipFig. 1

Systems behind it

What Living worlds is built from.

Questions about Living worlds.

How do we evaluate a world prototype?

Observe whether participants understand their roles and consequences, whether state remains coherent and whether the intended interaction is compelling. Public retention claims need real player evidence.

Living worlds in the stack.

Product expression

Shared kingdom

A living-world expression of roles and persistent consequences.

Research connection

Reusable mechanisms

Contracts and evidence for simulation systems.

Technical reference1 further section

The world needs continuity beneath the story.

Validate the event. Check the campaign structure, permitted effects and economy constraints.

Commit the consequence. Keep server-owned identity and durable settlement coherent across retries.

Retell from evidence. A shared history should derive from the recorded decisions of that world.

System story

From a changing crown to a living world

An illustrative day in Everbloom’s shared-world design.

Follow the story

Which choice in your world should every player see the consequence of?

Discuss a living-world collaboration