DEV Community: Tomás Almeida Garrett

Your Game's World Doesn't Need More Lore. It Needs More Consequences.

Tomás Almeida Garrett — Sun, 01 Mar 2026 17:31:12 +0000

Most game worlds are databases pretending to be ecosystems.

They have immaculate data. Faction tables with twelve columns. Lore documents with proper nouns for every century. Relationship graphs that look impressive on a whiteboard. A thousand-year war with twelve named kings stored across three JSON files and a wiki nobody reads after launch.
And then you play the game.

You walk through a town where nobody reacts to anything. You steal from a merchant and nothing changes. You burn a farm and the economy does not flinch. You pick a side in a civil conflict and the world politely pretends you did not.

The data exists in memory. It just never reaches the game state.
This is the core architectural failure I keep seeing in game worldbuilding — and I am calling it architectural because that is what it is. It is not a writing problem. It is not a content problem. It is a systems design problem. We build worlds with deep static data and shallow dynamic state. We invest in what the world is and underinvest in what the world does when something changes.
Consequences are the narrative. Everything else is documentation.

The data-reality gap
Here is the pattern.
A designer writes a faction bible. It says the Iron Covenant is "paranoid, militaristic, and fiercely protective of their borders." This goes into documentation. Maybe it becomes flavor text. Maybe some dialogue references it.

But in the game, Iron Covenant territory has the same patrol density as everywhere else. Their gates are not harder to pass through. They do not react faster to incursions. Their merchants do not charge outsiders more. Their guards do not escalate to violence quicker. The data says paranoid. The system says default.

This is the data-reality gap. The space between what you have written about your world and what your world actually does.
Every game has this gap. The question is how wide you let it get. In most games, it is a canyon. The lore is rich and the systems are flat. And players feel the flatness, even if they cannot articulate why. They just know the world does not feel real.
Closing the data-reality gap is not about writing less lore. It is about making lore executable.

Why reactive systems are hard
Before I argue for consequences, I want to be honest about why we do not build them.
Lore is a single-author, single-pass problem. One person can write a faction history tonight. It requires no integration testing. It produces no edge cases. It does not interact with the physics engine, the economy, the AI scheduler, or the save system. It is contained.

Consequences are a multi-system, multi-dependency problem. A single meaningful consequence — "the player destroyed a supply convoy, so this town's economy degrades" — touches inventory systems, NPC behavior trees, pricing logic, quest availability, possibly pathfinding if trade routes change, dialogue state, and world event scheduling. One consequence. Six systems.

That is why we default to lore. Not because designers are lazy, but because the engineering cost of reactive worldbuilding is genuinely high, and most project structures do not account for it. The lore team writes. The systems team builds mechanics. The two rarely collaborate at the granularity required for real consequences.
This is a structural problem, not a talent problem. And it has a structural solution.

The consequence stack
I think about consequences in layers. Not because layers are inherently good, but because they let you scope the engineering.
Layer 0: State change. The most basic consequence. Something happened, a flag flipped. The player killed the bandit leader. bandit_leader_alive = false. This is what most games already do. It is necessary but insufficient.

Layer 1: Local propagation. The state change ripples to adjacent systems. The bandit leader is dead, so bandit patrol frequency in this zone drops by 40%. Merchants on this road lower their risk pricing. A new NPC appears at the crossroads offering goods that were previously too dangerous to transport. The change touches 2-3 systems that were watching the original state.

Layer 2: Behavioral adaptation. Entities in the world adjust their behavior based on the new state. The remaining bandits do not just reduce patrols — they change strategy. They consolidate into a single fortified position instead of roaming. A rival bandit group senses weakness and starts encroaching. The town guard, no longer needing to worry about road safety, redeploys resources to an internal problem they had been ignoring. Agents are making decisions, not just reading flags.

Layer 3: Emergent second-order effects. The consequences of the consequences. The rival bandit group's expansion disrupts a different trade route, which affects a different town's economy, which causes a merchant there to relocate, which changes the player's access to certain goods in a region they have not even visited yet. No designer scripted this specific chain. The systems produced it.
Most games live at Layer 0. Good games reach Layer 1. Great games touch Layer 2. Layer 3 is where players start telling stories about your game at dinner.

You do not need to implement all four layers everywhere. You need to pick where in your game the layers matter and build the architecture to support them in those places.

What this actually looks like in practice
Let me get concrete.
You help smugglers move salt into a starving region. Layer 0: quest complete, reputation adjusted. Layer 1: bread prices drop in the local market, militia reduces cart inspections because the tension that was causing unrest has eased. Layer 2: the official guild that controlled salt supply recognizes the disruption. A guild representative appears in the next town you visit, asking questions. Guild-affiliated vendors raise prices for you specifically. Layer 3: the smuggling route you opened becomes known to other smugglers. A month later, a different contraband starts flowing through the same channel, creating a problem you did not intend.

You assassinate a faction officer. Layer 0: officer removed, faction hostility increases. Layer 1: patrol routes change, gate security tightens, night lanterns are added to previously dark streets. Layer 2: the faction begins mass arrests of suspects. An innocent NPC you know gets detained. Collateral damage propagating through the system. Layer 3: the crackdown makes the population resentful. Recruitment for the opposing faction quietly increases. Your surgical strike created a recruitment campaign for the other side.

You flood a mine to stop an extraction operation. Layer 0: mine output drops to zero. Layer 1: the faction that depended on those materials cannot maintain its equipment repair rate. Soldiers start appearing in slightly degraded gear. Layer 2: fortification repair schedules slip. Defensive positions weaken at specific points. Layer 3: three months later, an assault the faction would have repelled succeeds because they lacked the raw materials to prepare. Your action at the mine changed the outcome of a battle you were not present for. The player may never know the connection. But the systems do.

You ignore a request for aid. Layer 0: quest declined. Layer 1: the faction that asked stops offering you intelligence. An information pipeline you relied on goes quiet. Layer 2: quests that would have been generated by that intelligence never trigger. Merchants who gave you discounts based on the faction's endorsement revert to default pricing. Layer 3: the faction, forced to handle the problem without your help, makes compromises that change their political position — they owe favors to a third party now, which reshapes the diplomatic landscape. Your inaction had an opportunity cost that compounds.

Architecture, not content
Here is the shift in thinking I am arguing for.
Most game development treats worldbuilding as a content problem. You solve it by producing more content: more lore entries, more dialogue, more environmental storytelling, more codex pages, more audio logs.
I am arguing it is an architecture problem. You solve it by building systems that propagate state changes in believable ways.
The content question is: "What should this world contain?"
The architecture question is: "When something changes in this world, what else should change?"
The second question is harder, more expensive, and more valuable. A world that answers the second question with even basic consistency will feel more alive than a world that answers the first question with encyclopedic thoroughness.

Designing a consequence system
If you wanted to build this, here is how I would think about the architecture. Not code — the thinking layer above code.
Event bus, not direct coupling. Consequences should propagate through an event system, not through direct function calls between systems. When the player destroys a supply convoy, the combat system should not be calling the economy system. It should emit an event — CONVOY_DESTROYED { route_id, faction, cargo_type, location } — and any system that cares can subscribe. This is the only way to keep consequence chains extensible without turning your codebase into spaghetti.

World state as queryable graph. The world state should be a graph that any system can query. Nodes are entities (people, places, factions, resources). Edges are relationships (controls, trades_with, hostile_to, supplies). When a consequence propagates, it modifies edges and node properties. Any system can ask "what changed?" and adjust its behavior. This is how you get Layer 2 consequences — AI agents querying world state and adapting.

Temporal propagation. Not everything should happen instantly. A mine flooding should not crash the faction's military readiness on the same frame. Consequences need time budgets. Some propagate immediately (the guards at the gate react now). Some propagate over game-days (the economy adjusts). Some propagate over game-weeks (the military degrades). A consequence scheduler that processes pending state changes on a tick cycle gives you this for almost free.
Scope boundaries. Not everything needs to react to everything. Define propagation boundaries. A local event (stealing from a merchant) propagates within the settlement. A regional event (destroying a supply route) propagates within the region. A factional event (assassinating a leader) propagates across faction territory. Global events are rare and dramatic. Boundaries keep the system tractable and prevent absurd butterfly effects where stealing a loaf of bread causes an international incident.

Fallback defaults. When a system receives an event it does not have specific logic for, it should have a default response proportional to the event's severity. This prevents silent failures where a consequence should happen but nothing was implemented. Even a generic "faction trust decreases by X" is better than nothing. You can replace defaults with specific logic as development progresses.

The codex test
Here is a test I like.
Imagine your game shipped with no codex. No lore logs. No wiki. No optional reading. No audio diaries.
Would your world still feel deep?
If the answer is no, you have not built a deep world. You have built deep documentation.
A deep world can be understood through cause and effect. Players should be able to infer who has power, what is scarce, what is sacred, what happens when you break a rule, and how factions actually operate — not because you told them, but because the world behaves accordingly.

If your lore says "this faction is paranoid," I should see paranoia in their system design — more checkpoints, faster alert escalation, civilians being stopped and searched. If your lore says "this city is starving," the economy system should reflect it — empty vendor inventories, inflated prices, rationing mechanics, desperation in the quest economy. If your lore says "the church controls justice," the legal consequence system should bend around religious authority.
Otherwise your lore is comments in code that never compiles. It describes intent without implementation.

A worked example: the corrupt tax collector
Let me walk through a single scenario at full depth, the way I would design it.
The action. The player exposes a corrupt tax collector in a garrison town.
Layer 0. Tax collector removed from post. tax_collector_status = removed. Reputation with the garrison adjusts.
Layer 1. The garrison's commanding officer acknowledges the corruption publicly. garrison_reputation with the local population takes a hit — they were supposed to be overseeing this. The immediate tax burden lifts. NPCs in the market district have slightly more disposable income, which shows up in what they are willing to buy and sell.

Layer 2. The garrison over-corrects. The replacement tax collector is not corrupt but significantly more aggressive. The tax_rate variable goes up, not down. Collection enforcement increases. People who thanked the player last week are now resentful. The player's intervention improved one metric — corruption — and degraded another — livability.
Layer 3. The original corrupt tax collector had relationships that functioned as an informal system. Merchants who bribed him for favorable treatment. Smugglers who operated under his protection. An intelligence network that flowed through his office because people came to negotiate. All of that collapses. The merchants lose their edge and some go bankrupt, reducing market variety. The smugglers scatter, and some get caught, which means the goods they were moving — including medicine — no longer arrive. The intelligence that used to flow through a single corruptible node evaporates, which means the garrison loses information it did not even know it was receiving through the back channel. Crime does not decrease. It becomes less predictable.

One action. Three layers. No branching narrative. No new cutscenes. Just systems that remember and adjust. The event bus emits TAX_COLLECTOR_REMOVED. The economy system, the NPC behavior system, the faction reputation system, and the world event scheduler each handle it according to their own logic. The cascading consequences are not scripted as a chain. They emerge from independent systems responding to shared state.
That is the architecture of a world that feels alive.

The point
Worldbuilding is not a wiki. It is not a database. It is not documentation.
Worldbuilding is a set of systems that produce believable outcomes when state changes.
Players do not need you to tell them your world is complex. They need to feel complexity when they act. They need the world to push back, adjust, remember, and continue operating around the hole their decisions made.
If your world cannot change, it cannot be real.
So no — your game does not need more lore.
It needs more consequences.

A Framework for Consequence-Driven Worldbuilding in Games

Tomás Almeida Garrett — Wed, 25 Feb 2026 18:10:38 +0000

Most game worlds describe their cultures. Few actually build them.

You'll see a faction described as "militaristic" — but their cities, food, and economy are identical to every other region on the map. The description says warrior culture. The world says copy-paste.

This post breaks down a framework I use for building game worlds where one cultural decision creates pressure across multiple systems — economy, architecture, food, religion, labor, and social hierarchy. It's less about writing better lore and more about designing worlds that hold up when players start poking at them.

The core idea: pressure between systems

A world feels deep when one design decision forces consequences in other systems. Not when it has a lot of categories filled in.

Here's what that looks like in practice.

Say you're building a faction that worships fire because their ancestors survived a great conflagration. That's your starting point — a sentence, not a world.

If that event actually shaped the culture, it should show up in daily life. If the fire destroyed forests, fuel becomes scarce. That changes cooking — you stop seeing long-simmered meals and start seeing faster methods, communal ovens, foods that rely on drying and fermentation rather than constant flame.

If open flame is sacred, maybe households aren't allowed to light it freely. Only designated keepers can. Cooking shifts to shared spaces. Meals become public. Food becomes easier to regulate. Now religion isn't just belief — it's social control.

Same initial idea. But now it generates consequences across food, economy, architecture, religion, and class structure.

A real example: Skellige in The Witcher 3

Skellige isn't "Viking culture with swords." The people worship the sea and live by raiding — and that single identity choice pressures everything else:

Economy: Raiding spoils and fishing, not agriculture
Merchants: Ship supplies, whale oil, dried fish
Settlements: Coastal, defensible, built around longship docks
Death rites: Ship burials
Architecture: Heavy timber, wind-battered, practical
Social structure: Clan-based, not merchant-class — mead halls function differently from Novigrad's taverns

One cultural premise touches six systems. That's what pressure looks like.

The food test

Food is the fastest way to stress-test whether a setting is real or decorative, because food is tied to everything: geography, climate, labor, class, religion, trade, war, ritual, scarcity.

You can fake a mythology. You can't easily fake a food system.

Compare two factions with the same "harsh northern land" aesthetic:

Faction A (generic): They eat meat, drink ale, and value strength.

Faction B (consequence-driven): The growing season is short. Grain is unreliable. Fish is abundant in one season but dangerous to harvest in another. Fuel is limited inland. Salt is controlled by one city. Winter feasts are less about abundance and more about proving storage success.

Faction B's food culture might involve preserved fish, dense broths, blood usage, root cellars, and ritual drinking tied to stock counts rather than pure celebration.

That already tells you more than "they are hardy and fierce." It also gives you concrete design hooks: what's expensive in local markets, what soldiers carry on campaign, what a noble table looks like versus a common one, what gets rationed during conflict, what gets stolen first during raids.

Designing for player interaction: location states

If you're building a reactive world, locations need to communicate narrative through their physical form and respond to changes in power.

A market district under different controlling forces:

State	Visual cues	NPC behavior	Economy
Imperial control	Uniform stalls, official banners, regular guard patrols	Orderly, regulated	Taxed, stable
Rebel control	Scattered stalls, makeshift covers, armed sentries	Defensive, paranoid	Black market, rationed
Contested	Mixed aesthetics, barricades going up/down	Nervous, evasive	Near-collapse

The location is recognizably the same place each time. But its character shifts to reflect political reality.

The practical constraint: This requires designing multiple stable states per location, writing varied dialogue for each, and tracking which state each location is in. For smaller projects, start with 2–3 key locations and expand from there.

Consequence cascading

The most reactive worlds don't have isolated consequences. They cascade:

Player helps rebellion
  → Empire marks player as enemy
    → Player can't enter imperial cities
      → Imperial merchants won't trade with player
        → Player depends on rebel supply lines
          → Defection becomes increasingly costly

Now flip it:

Player ignores rebellion
  → Rebellion weakens, Empire consolidates
    → Empire's rules get stricter
      → Neutral zones absorbed into Empire territory
        → Player can't avoid the Empire anyway
          → Forced to choose sides through circumstance, not agency

Different initial choices lead to fundamentally different world states. The key is mapping these cascades before writing dialogue, so consequences feel interconnected rather than arbitrary.

Documentation that actually helps

For this to work across a team (or even across your own sessions), you need lightweight documentation. Here's what I use:

Faction doctrine doc

For each faction: what they believe, what they want (short and long term), how they make decisions, how they react to threats, how they treat other factions, what they value and despise, their resources and limitations.

NPC biography sheet

For each significant NPC: core motivation, competing loyalties, relationships with other NPCs, faction allegiances, perspective on major events, medium-term goals (2–4 in-game weeks), long-term goals, reactions when blocked, reactions when they succeed.

Consequence map

For major events, map out immediate → secondary → tertiary → quaternary consequences. This prevents "orphan consequences" — effects that don't connect to anything else.

Location state checklist

For important locations: what does this place look like under State A vs State B vs State C? What changes in visuals, NPC behavior, dialogue, and economy?

The honest constraints

This is expensive. A quest with one solution takes roughly 5 hours of designer time. A quest with three valid solutions takes 15–25. Multiply across 50 quests and you're looking at hundreds of extra hours.

The realistic approach:

Pick 2–3 solution categories (combat, stealth, social) rather than infinite solutions
Scale consequences by approach — same outcome, different world reaction depending on method
Use environmental storytelling to communicate state changes instead of writing new dialogue for everything
Start with 2–3 deeply reactive locations and NPCs, then expand
Accept that perfect reactivity is impossible — build robust systems, then polish the important moments

The games that feel most alive — Witcher 3, Divinity: Original Sin 2, Hades, Baldur's Gate 3 — don't make everything equally reactive. They make smart choices about where to invest their reactivity budget for maximum impact.

TL;DR

Surface worldbuilding gives you themes. Durable worldbuilding gives you consequences. One cultural decision should create pressure on economy, architecture, food, religion, labor, and social hierarchy. Use food as your stress test. Map consequence cascades before writing dialogue. Document faction doctrine, NPC motivations, and location states. Start small, invest reactivity budget where it matters most.

I write about narrative design and worldbuilding systems. Currently building Aetheris, a dark fantasy world where every faction's identity grows from how their ancestors survived the same catastrophic event differently.