Continuum: AI lore consistency in MMORPG gaming

An engine that keeps a shared game world’s narrative consistent while thousands of players revise it at once.

AAIC built the engine; the interface in these recordings is a technical demonstrator of it, not a production UI.

Motivation

A large online world carries extensive lore — who rules, who has died, who holds the crown — and player quests continually revise it. When many players act concurrently, their revisions can contradict one another: one quest kills the king while another depends on his being alive. At a scale of millions of such actions each day, unmanaged contradictions degrade the narrative into incoherence.

Continuum’s purpose is to preserve the world’s consistency while it continues to change.

Fig. 1The running world. The lore as a graph, with the world clock, the feed of player actions, and the dashboard — the world advancing continuously.

The storage model

Continuum stores the world in two structures. The first is a graph: its nodes are the world’s entities — characters, factions, locations, items — and its edges the relationships among them, together representing the present state. The second is a chronicle, an append-only log of events. State is never overwritten; the world advances only by appending events, so the present graph is exactly the result of replaying the chronicle from its origin.

A set of invariants — the world’s laws — constrains every state: the crown has exactly one bearer, a retired entity initiates no further actions, and no relationship refers to an entity that does not exist.

The formal model

Formally, the world is a state W = (G, C), comprising the graph G and the chronicle C. A player’s action is a delta δ — a patch that transforms G into G′. The laws are predicates that the graph must satisfy.

W consistent \Leftrightarrow \forall l \in Laws : l (G) = true

δ_{1} and δ_{2} conflict \Leftrightarrow write (δ_{1}) \cap write (δ_{2}) \neq \emptyset

or \exists l : l (δ_{2} (δ_{1} (G))) = false

Because most deltas modify disjoint regions of the graph, they commute: their order is immaterial and they may be applied in parallel. Only the minority that overlap, or that would violate a law, require reconciliation.

Reconciliation

Each delta is first classified by blast radius: personal (confined to one player’s instance), regional (a single zone), or global (world canon). A smaller radius is cheaper to process and less likely to collide with other deltas.

When two deltas collide, Continuum ascends a ladder of strategies, halting at the first that restores consistency:

Serialize — the deltas are compatible and are simply ordered.
Merge — one delta is rewritten so that both can hold (slay becomes wound).
Scope down — a change is demoted so that it never reaches canon.
Fork — the timeline is split into two internally consistent worlds.
Reject — the delta is returned to be rewritten.

Fig. 2Resolving a collision. Two quests reach for the same crown simultaneously. A merge is impossible, so the timeline forks into two consistent worlds — one in which the king falls, one in which the heir is crowned.

Fig. 3Authoring a change. Our colleague enters a quest — “slay the king and end the kingdom” — which Continuum classifies, checks against the laws, and reconciles in steps.

Cost and scaling

The system’s cost is governed by the contended core — the small set of mutually overlapping deltas — rather than by the total player count. Personal deltas commute and therefore scale with available hardware. Verifying a law examines only the small subgraph a delta touches, an O(k) operation rather than O(|G|). A million quests in an hour thus reduce to only a handful of genuine conflicts.

Fig. 4Throughput and coherence. The dashboard reports throughput, conflicts resolved, and canon coherence; the coherence line dips as a conflict lands and recovers as Continuum settles it.