Open-World RTS/RPG Settlement Sim

You are not controlling pawns. You are choosing when ordinary lives become stories.

The project is currently a concept and preproduction design target, not an implementation plan with committed engine or code architecture.

• real-time strategy style direct unit control
• cozy citybuilder and settlement growth
• open-world RPG exploration and events
• colony/life simulation with autonomous people
• emergent narrative driven by traits, memory, relationships, and consequences

The player builds and grows a settlement, assigns labor, gathers resources, upgrades structures, and handles the familiar strategic loops of an RTS. At any moment, the player can also select individuals or small groups and directly steer them through journeys, hunts, quests, diplomacy, exploration, or crisis response.

The world continues living even when the player is not looking. Villagers work, travel, form bonds, suffer losses, develop habits, and react to danger. The player's role is not to manufacture all meaning from above, but to step into an already-living simulation and bend key moments into memorable stories.

It is closer to:

• an RTS camera and unit interaction model
• layered on top of a selective simulation world
• where autonomous lives produce ambient story
• and player intervention turns ambient story into playable story

The project should be evaluated by whether it delivers this fantasy:

• build a settlement that feels inhabited
• care about the people inside it
• zoom into specific people or groups
• personally guide decisive moments in their lives
• watch those moments permanently change the settlement and the world

• rule and grow a living frontier settlement
• become attached to the people who live there
• step into important moments instead of only issuing abstract orders
• feel that logistics, politics, danger, romance, loss, and ambition all belong to the same world

The intended player sensation is not pure efficiency optimization and not pure hero-centric RPG adventuring. It is the feeling of governing a settlement whose inhabitants are people, not anonymous worker tokens.

#6.1Macro Role

At the settlement level, the player:

• assigns units to gather resources
• places and upgrades buildings
• sets up production and storage chains
• manages growth, expansion, and infrastructure
• responds to threats and shortages
• shapes the strategic development of the settlement

#6.2Micro Role

At the human or party scale, the player:

• directly selects units
• steers small groups through the world
• hunts, scouts, escorts, trades, and rescues
• handles tactical encounters
• responds personally to world events
• participates in quests, diplomacy, and high-stakes journeys

This micro control is not decorative. It is how the player authors turning points in the lives of individuals who otherwise live autonomously.

1. Grow and sustain a settlement through labor, building, and logistics.
2. Let villagers autonomously carry out work and life routines.
3. Notice risks, opportunities, shortages, and emerging stories.
4. Intervene directly by selecting people or parties for important actions.
5. Resolve those actions through real-time movement, combat, travel, and event participation.
6. Feed the consequences back into the settlement simulation.
7. Watch people and institutions change as a result.

The loop should support both:

• ambient life the player can observe
• decisive episodes the player can personally shape

#8.1RTS Layer

• direct unit selection
• immediate move/attack/gather/build orders
• visible workers and logistics
• tactical response to danger
• real-time pacing

#8.2Colony/Citybuilder Layer

Borrow from cozy builder and colony sim design:

• autonomous workers
• storage and job chains
• homes, families, routines, and infrastructure
• gradual settlement identity
• planning rather than constant micromanagement

#8.3RPG Layer

Borrow from RPG design:

• open-world travel
• quests and narrative events
• stats and traits
• personal progression
• story consequences tied to who was involved

#8.4Life Sim / Emergent Narrative Layer

Borrow from life sim and systemic narrative design:

• relationships
• memory of past events
• habits acquired through experience
• social consequences
• household and lineage development

Key principles:

• the world should be streamable
• the world should remain persistent
• the world should not simulate every entity at full detail at all times
• different areas should consume different simulation budgets

The world is expected to contain:

• player settlement(s)
• towns and cities later
• wilderness and hunting grounds
• wildlife and monsters
• resource sites
• roads and trade routes
• events, quests, and discovery locations

At the current concept stage, AI-controlled rival factions are intentionally out of scope, though the architecture should allow them later.

The project needs a world model that supports:

• large continuous space
• selective simulation fidelity
• actor persistence across distance
• route and region logic that spans local map tiles

The key idea is:

• chunks exist for local spatial detail
• regions exist for broader simulation meaning

The architecture should not confuse those two jobs.

#10.1Architectural Goal

The world partition system should:

• let the player move through a broad seamless world
• load only the local detail that matters right now
• preserve offscreen causality across long distances
• give the simulation stable containers for routes, danger, resources, and settlement influence

It should be possible for the player to:

• leave a work site
• travel elsewhere
• return later
• find a believable evolved state

without requiring every local object in the entire world to stay fully active in memory.

#10.2Core Spatial Layers

The world should likely be represented through several nested layers.

#10.2.11. Tile or Nav Cell Layer

Use for:

• walkable space
• obstacles
• terrain cost
• local pathfinding
• local placement and collision

This layer matters most when a scene is fully embodied and nearby.

#10.2.22. Chunk Layer

Use for:

• local streaming unit
• local scene ownership
• terrain and static object batching
• nearby actor embodiment
• local resource nodes
• local creature spawning anchors

Chunks should be small enough to stream comfortably and large enough to avoid pathological churn when the camera or player moves.

A chunk is a local detail container, not a narrative or economic unit.

#10.2.33. Region Layer

Use for:

• route and corridor identity
• risk fields
• ecological pressure
• settlement influence
• broad resource patterning
• event relevance
• low-fidelity offscreen simulation

Regions should group multiple chunks into spaces that matter to human-scale reasoning.

Examples:

• north forest outskirts
• river crossing corridor
• settlement hinterland east
• quarry ridge district
• old shrine valley

A region is a simulation and meaning container, not just a geometry bucket.

#10.2.44. World Layer

Use for:

• global seed and generation rules
• climate or biome belts
• known settlements
• travel networks
• faction territories later
• long-range discovery and event routing

#10.3Chunk Schema

Each chunk should carry data that is primarily local and spatial.

Likely chunk contents:

• chunk_id
• world bounds
• terrain and elevation references
• biome mix
• local nav data
• static props and obstacles
• resource node instances
• building instances within bounds
• embodied actor references currently loaded
• local creature presence state
• local scene flags

Chunk records should prefer references to stable world objects rather than duplicating the full truth of those objects.

#10.4Region Schema

Each region should carry data that is primarily systemic and durable.

Likely region contents:

• region_id
• member chunk ids
• region type
• travel corridors and route references
• threat fields
• ecological profile
• settlement influence values
• known sites of interest
• active regional incidents
• ambient traffic intensity
• depletion and recovery state
• visibility or familiarity state for the player

This is where the world can remember that:

• wolves have become more active along a corridor
• quarry traffic is heavy this month
• a shrine rumor belongs to this valley
• a road is becoming safer due to watchtower coverage

#10.5World Objects Versus Partition Containers

Important rule:

Chunks and regions should not "own" all gameplay truth inside them.

Instead:

• actors are their own persistent records
• buildings are their own persistent records
• routes are their own persistent records
• events are their own persistent records

Chunks and regions should index, host, or contextualize those records.

This prevents world state from becoming impossible to reconcile when an object spans boundaries or changes scale.

#10.6Streaming Responsibilities

Streaming should primarily decide:

• what local geometry is loaded
• what actors are embodied
• what nearby AI runs at full fidelity
• what VFX, animation, and scene props exist

Streaming should not decide whether the broader world exists.

A good mental split is:

• streaming controls presence in local memory and scene detail
• simulation layers control continued world truth

#10.7Focus and Simulation Heat Model

The project needs something more explicit than a vague loaded versus unloaded split.

The world should likely be managed through a heat model:

• focused
• hot
• warm
• cool
• cold background

This heat should not be purely visual. It should drive:

• streaming persistence
• actor representation tier
• update cadence
• AI reconsideration frequency
• interruption sampling depth
• UI surfacing priority

This is how the game can preserve parity where the player cares without pretending the whole world runs at the same granularity.

#10.8Focused Zone

The focused zone is the space of immediate player agency.

Typical focus anchors:

• camera center
• currently selected villagers
• directly controlled parties
• opened inspectors that pin a person, household, job chain, or site
• active dialogue, combat, hunt, or rescue scenes

Inside the focused zone:

• chunks stay loaded
• actors stay fully embodied
• local nav and collision are exact
• combat, conversation, and manipulation resolve in immediate detail
• needs and affect can update at short cadence
• fine-grained interruptions are allowed to emerge

This is where the player should be able to trust what they are seeing at a moment-to-moment level.

#10.9Hot Zone

Hot zones are not necessarily on screen, but they are still under strong scrutiny or near-term consequence.

Typical hot-zone causes:

• recently focused area
• selected actor traveling just offscreen
• dangerous encounter chain in progress
• settlement core logistics area
• expedition route the player is actively monitoring
• aftermath of direct control or crisis

Inside a hot zone:

• chunks may remain partially loaded or be cheap to rehydrate
• actors remain individual and highly inspectable
• travel advances by short route segments
• task progress advances by local milestones
• interruptions are still sampled specifically rather than only statistically
• relationship and household reactions may still update on short cadence

Hot is the tier that should make "I just looked away for a minute" still feel honest.

#10.10Warm Zone

Warm zones are offscreen spaces with elevated narrative or economic relevance, but not immediate hand-on control.

Typical reasons to stay warm:

• the player was there recently
• a named villager is active there
• a quest thread is unresolved there
• a route bottleneck or shortage is centered there
• infrastructure, trade, or defense significance is high
• repeated incidents have made the area notable

Inside a warm zone:

• local chunks do not need to remain fully loaded
• actors may use compressed active representation
• plans advance by milestones and decision checkpoints
• route checks happen at segment or transition boundaries
• incidents resolve with participant-specific logic
• memory, reputation, and household effects still propagate with identity intact

Warm is where the world should still feel personal, even when it is not being watched second by second.

#10.11Cool Zone

Cool zones are part of the living world, but they are not presently important enough for dense individualized updates.

Typical cool-zone characteristics:

• no immediate player attention
• no selected actors
• no urgent incident chain
• no core settlement bottleneck
• stable ambient conditions

Inside a cool zone:

• actors are mostly regional participants
• travel advances in coarse steps
• encounter checks draw from regional opportunity fields
• household and social life advance on scheduled summaries or thresholds
• ecology, depletion, traffic, and route safety update in aggregate

Cool should preserve causality and trend direction, not every gesture.

#10.12Cold Background

Cold background space still exists, but it should be handled by the cheapest durable model the game can trust.

Use cold background for:

• remote wilderness with no active relevance
• long-stable regions far from settlement influence
• low-interest travel corridors with no named participants
• dormant ecological recovery or seasonal drift

At cold background:

• no embodied chunk state needs to remain live
• actor state may rest until the next meaningful checkpoint
• systems update through event-driven triggers, coarse pulses, or time-skip math
• only durable consequences and broad pressure fields are preserved

The cold tier is not fake world deletion. It is deliberate non-obsessive bookkeeping.

#10.13Heat Promotion and Demotion Rules

Heat should change through explicit causes, not constant noisy reevaluation.

Promotion causes:

• camera or player movement
• unit selection
• direct control
• severe danger
• quest activation
• player pinning a person or site in the UI
• shortage, attack, or blockage crossing an importance threshold
• multiple meaningful actors converging on the same route or site

Demotion causes:

• time since last attention grows
• active danger resolves
• no selected or story-important actor remains
• local logistics return to normal
• no unresolved incident chain persists

Important rule:

Demotion should usually be delayed and hysteretic.

The system should avoid:

• hot to cool snap-downs the moment the camera moves away
• actors flipping tiers every few seconds at a boundary
• quest or aftermath scenes losing coherence because interest briefly dropped

#10.14Heat Is More Than Distance

Distance should matter, but it should not be the only input.

A better heat score should combine:

• distance to camera or control anchor
• player selection and pin state
• actor importance
• recent direct control
• current danger
• quest relevance
• settlement economic centrality
• infrastructure criticality
• intersection density

This matters because:

• a merchant convoy one region away may need to stay hot
• an empty nearby hillside may be safe to cool
• a grieving spouse in town may matter more than a random deer on screen edge

#10.15Granularity Rules by Heat Tier

The design should explicitly define what each heat tier is allowed to do.

focused

• exact local movement
• immediate sensing and reactions
• granular need drift
• tactical interruption handling
• fine animation and action state

hot

• short-segment travel
• milestone-based task progress
• identity-specific interruption resolution
• short-window emotional and social aftermath
• rapid but not frame-bound reconsideration

warm

• checkpoint-based plan advancement
• route transition checks
• named participant incident resolution
• summarized household and relationship propagation
• compressed but actor-specific consequence writes

cool

• region-level traffic and labor flow
• aggregate opportunity and danger updates
• periodic social and household summaries
• broad stock and pressure propagation

cold background

• sparse checkpoint math
• season, depletion, and recovery drift
• dormant state retention until new relevance appears

If a system cannot say what changes at each heat tier, it is not ready to scale.

#10.16Route Schema

Routes are important enough to deserve explicit representation rather than existing only as temporary paths.

Likely route fields:

• route_id
• source and destination refs
• traversed region ids
• segment list
• road quality
• terrain class
• safety rating
• traffic volume
• escort expectation
• seasonal modifiers

Routes are where:

• hauling lives
• escorts matter
• predator pressure becomes gameplay
• missing people become plausible

#10.17Site Schema

Important sites should also have persistent identity.

Examples:

• quarry clusters
• hunting grounds
• ruins
• shrines
• bridges
• camps
• dens
• watchtowers

Likely site fields:

• site_id
• site type
• chunk or region placement
• ownership or influence
• resource profile
• danger profile
• discovery state
• event hooks
• depletion state

Sites are the anchors that connect terrain to labor, risk, and story.

#10.18Visibility and Knowledge Model

The player's knowledge of the world should be partially separate from the world's actual state.

Useful knowledge layers:

• unseen
• discovered
• currently visible
• stale knowledge
• freshly reported knowledge

This allows:

• uncertainty
• scouting value
• rumors and delayed information
• routes that have changed since last visit

The world may know a bridge is damaged before the player does.

#10.19Generation Versus Persistence

The world architecture should separate:

• generated baseline content
• persistent modified state

Generated baseline includes:

• terrain
• base biome layout
• initial site placement
• broad ecological assumptions

Persistent modified state includes:

• harvested resources
• built structures
• cleared dens
• changed roads
• discovered ruins
• new settlements or outposts
• event consequences

This lets the world stay large without requiring every untouched detail to be explicitly stored forever.

#10.20Region-Level Simulation Responsibilities

Regions should be the natural home for many offscreen systems, including:

• predator density
• weather pressure
• ambient traffic
• road safety drift
• forage abundance
• rumor propagation
• low-fidelity encounter chance
• background task continuity

This is why region design matters so much. A region is the bridge between the map and the simulation.

#10.21Boundary Crossing Rules

Actors, jobs, and events will constantly cross chunk and region boundaries.

The system should therefore treat boundaries as administrative, not magical.

Crossing a boundary should not:

• reset a task
• break a route
• lose a reservation
• detach an event from its participants

Instead, crossing should update references while preserving continuity.

#10.22Save/Load Requirements

The partition model must serialize cleanly.

At minimum, save state should preserve:

• chunk modification state
• region systemic state
• route state
• site state
• embodied actor locations
• compressed actor location abstractions
• active events and jobs tied to partition references

This is especially important if the world later grows into a long-running campaign save.

#10.23Anti-Goals

Avoid these partition mistakes:

• making chunks too semantically important
• making regions so large they lose specificity
• tying actor identity to loaded chunk presence
• storing the same truth redundantly in too many layers
• assuming infinite world means equal simulation everywhere
• making route logic depend on full offscreen pathfinding every second

#10.24Recommended First Implementation

The first implementation only needs to prove a modest partition model:

• a bounded map
• chunk streaming for local detail
• a handful of meaningful regions
• one or two persistent routes
• a few persistent sites
• actor promotion and demotion across those boundaries

If that works and remains understandable, the world can scale outward later without changing the core mental model.

Sources of pressure and texture:

• wildlife hunting and predation
• dangerous monsters
• weather and travel hardship
• distance and logistics
• disease, poisoning, injury, and scarcity
• diplomacy and institutional requests
• household needs and social consequences
• exploration and event discovery

This allows the project to focus on systemic life and settlement drama before adding enemy civilizations.

Good uses of direct control:

• a hunt for food or rare reagents
• escorting a merchant
• answering a diplomatic summons
• investigating danger on a route
• scouting unknown territory
• defending against predators or monsters
• participating in key quest moments

Direct control should not be mandatory for every ordinary task. If manual play is always strictly optimal, the autonomous life-sim layer collapses into a micromanagement burden.

Target balance:

• autonomy should handle daily life competently
• player control should matter most in risky, emotional, rare, or high-stakes situations

It is not enough for the game to merely allow the player to click on a villager and move them around. The simulation needs a consistent rule for how player intent, villager identity, and world consequences interact.

#13.1Core Rule

Direct control should be treated as authoritative tactical guidance layered on top of an existing person, not as possession by a totally different game system.

That means:

• the player can override immediate action
• the villager keeps their identity, stats, traits, condition, and memories
• outcomes are still filtered through who the villager actually is
• once direct control ends, the villager returns to autonomous life carrying the consequences

The villager is not replaced by a puppet. They are being forcefully or cooperatively steered through a decisive period of life.

#13.2What Direct Control Should Change

When a villager is directly controlled, the game should allow the player to control:

• movement and path choice
• target priority
• combat engagement
• interaction timing
• party composition for expeditions
• whether to investigate, flee, press forward, or retreat
• who responds to a situation

In practical terms, direct control should alter:

• short-term action selection
• short-term route choice
• tactical risk tolerance
• task sequencing in the immediate scene

#13.3What Direct Control Should Not Change

Direct control should not erase or bypass the villager's underlying personhood.

It should not directly change:

• base stats
• innate traits
• learned tendencies already earned
• relationship history
• physical limitations
• reputation already established
• emotional condition already in effect

If a weak villager is player-controlled, they do not become secretly strong.

If a talkative fool is player-controlled, they may still embarrass the player in court.

If a cautious forager is player-controlled, they may still be slow to enter obvious danger.

#13.4Recommended Control Model

The best-fit model for this project is probably:

Strong player override on action, soft persistence on interpretation and outcome.

In other words:

• the player can tell the villager what to attempt
• the villager's identity determines how well they do it, how they emotionally process it, and what consequences stick

This protects both sides of the game:

• the RTS fantasy of meaningful command
• the living-world fantasy of people remaining themselves

#13.5Command Authority Levels

It may help to think of control as several authority bands rather than one binary switch.

#13.5.11. Assignment Authority

The player sets a task or destination, but the villager executes autonomously.

Examples:

• gather from this forest
• deliver goods to that town
• patrol this route

This is normal RTS/citybuilder control.

#13.5.22. Guided Control

The player directly steers moment-to-moment behavior, but the villager still expresses soft resistance through performance and outcome.

Examples:

• lead three villagers on a boar hunt
• escort a merchant through dangerous terrain
• investigate a cave entrance

This is likely the project's default "micro adventure" mode.

#13.5.33. Hard Crisis Override

In emergencies, the player can issue immediate must-follow commands that suppress hesitation long enough to survive the scene.

Examples:

• run now
• fall back
• attack this predator
• carry this wounded person home

Even here, the villager's identity should still affect:

• execution speed
• morale aftermath
• injury chance
• memory formation

#13.6Control State Transitions

Villagers should have an explicit control-state transition model.

Useful states:

• autonomous
• assigned
• directly_controlled
• crisis_override
• released_from_control

The transition out of direct control matters as much as the transition in.

When released, the villager should:

• re-evaluate needs
• re-evaluate safety
• update memory and stress state
• decide whether to resume prior duty, recover, report, or change behavior

This is how direct control episodes become biography instead of disconnected mini-games.

#13.7Direct Control and Plan State

A directly controlled villager should still retain a plan record, but the plan should be marked as temporarily superseded.

Suggested behavior:

• store the prior autonomous plan
• attach a temporary player-led plan or objective
• allow interruptions and local tactical decisions during control
• on release, reconcile old plan with new reality

Possible outcomes on release:

• resume prior plan
• abort prior plan
• switch to recovery plan
• switch to new opportunity plan
• trigger settlement report or alert

#13.8Party Control

The design should assume that direct control often applies to small groups, not just single people.

A party should have:

• a leader or player focal unit
• member roles
• cohesion rules
• follow distance or formation behavior
• shared travel intent
• local assist logic

This matters because "select 3 villagers and go hunting" is a core use case, not an edge case.

Party members should still remain individual people with:

• separate inventory
• separate fear and injury
• separate memory formation
• separate relationship reactions to what happened

The party is a temporary coordination structure, not a merged unit.

#13.9Dialogue, Diplomacy, and Social Events

Direct control should not guarantee social success.

The player chooses:

• who is present
• what broad action to attempt
• whether to push, flatter, threaten, apologize, or withdraw

The villager determines:

• how well they express the intent
• whether the other side is persuaded
• whether an awkward trait creates a surprise outcome
• what reputation consequences follow

This is important for preserving the "send the wrong villager to the king" fantasy.

Direct control lets the player pick the emissary and steer the scene. It should not erase the social risk of picking a fool, coward, brute, or motormouth.

#13.10Combat and Hunt Semantics

In combat or hunting, direct control should improve tactical precision but not guarantee clean execution.

Player control should help with:

• positioning
• target focus
• retreat timing
• formation spacing
• use of terrain

Villager identity should still affect:

• aim quality
• reaction speed
• panic under pressure
• stamina burn
• willingness to commit to danger

This creates a satisfying split:

• player skill matters
• villager capability still matters

#13.11Resistance, Obedience, and Tone

The game should probably avoid heavy-handed refusal for ordinary direct control, because constant "no" from villagers would feel terrible in an RTS-like interface.

A better approach is:

• villagers usually obey
• villagers differ in how effectively they obey
• villagers may accumulate stress, fear, resentment, or admiration based on what the player puts them through

So the friction is mostly:

• consequence friction
• performance friction
• aftermath friction

Not:

• UI refusal spam

#13.12Memory Formation Under Control

Events that happen during direct control should be especially likely to become durable memories.

Examples:

• first successful hunt
• near-death escape
• diplomatic humiliation
• heroic rescue
• witnessing a friend's death
• carrying home the food that saved winter

This matters because direct control is where the player most strongly authors identity-shaping moments.

#13.13Direct Control and Story Priority

A villager who has been directly controlled should receive a temporary increase in story importance and simulation warmth.

Reasons:

• the player is more likely to care what happens next
• immediate aftermath is often narratively rich
• relationships and memory updates are more likely to fire soon after

This supports the desired feeling of:

• lead someone through an important episode
• release them back into the world
• later see how that episode changed their life

#13.14Offscreen Continuity After Control

Once the player stops controlling a villager, the simulation should continue with elevated fidelity for a while rather than instantly demoting them to generic abstraction.

That window should preserve:

• short-term emotional aftermath
• injury and exhaustion consequences
• reporting or return behavior
• household and relationship reactions
• any newly altered route or danger preference

This is how the world avoids feeling hand-wavey after dramatic player action.

#13.15Failure and Fairness

Direct control must not become a trap where the player feels cheated because systemic identity overrides obvious tactical decisions too often.

Good fairness rules:

• player input should matter immediately
• trait and stat influence should be legible
• bad outcomes should usually be explainable in hindsight
• villagers should fail in-character, not arbitrarily

The player should be able to say:

• I chose a risky plan
• I sent the wrong person
• they were exhausted
• we entered predator territory unprepared

Not:

• the game just decided no

#13.16Recommended First Implementation

The first implementation of direct control only needs to prove a few cases:

• leading a villager or small party to a hunt
• escorting a carrier or merchant across a risky route
• simple direct combat against wildlife or monsters
• a basic social event where the chosen villager's stats and traits affect the result

If these feel good, the rest of the system can expand from there.

Examples:

• two villagers meet and grow close
• a trader is delayed by danger on the road
• a worker becomes more cautious after injury
• a household struggles after losing a provider
• a diplomatic mistake damages a political relationship

However, not every event deserves equal screen time. The game should distinguish between:

• ambient story
• playable story

#14.1Ambient Story

Things the world does on its own:

• bonding
• conflict
• daily routines
• small acts of aid
• learned habits
• household formation

#14.2Playable Story

Moments that become foreground because the player intervenes or consequences become important:

• selected units are taken on a hunt
• a named villager is sent to court
• a dangerous trip becomes a rescue
• a missing person matters to a family and supply chain

The player does not create all story. The player chooses where to place attention and force of will.

Offscreen continuity should preserve causality, not necessarily every footstep.

The player should be able to leave a villager on a task, return later, and find a consistent, inspectable situation:

• resources have been moved
• travel took time
• interruptions could have happened
• danger could have changed the outcome
• the person remains where their actions say they should be

The player does not need a frame-perfect replay of everything that happened offscreen. They need a world state that is believable, persistent, and derived from real rules.

#16.1Tier 1: High-Fidelity Simulation

Use for:

• on-screen units
• nearby chunks
• selected units
• recently observed or emotionally important entities
• active combat or crisis

Tracked at rich detail:

• exact position
• pathing
• animation or action state
• inventory
• current task step
• nearby interactions
• line-of-sight or local awareness
• immediate combat and interruption behavior

#16.2Tier 2: Mid-Fidelity Simulation

Use for:

• offscreen but still relevant individuals
• recently interacted entities
• units carrying out player-relevant work
• routes and missions likely to be revisited soon

Tracked as individual actors, but not frame by frame:

• destination and route intent
• estimated travel progress
• current task state
• carried inventory
• local risk exposure
• interruptible milestones

These entities still exist as individuals. They can still be interrupted by meaningful events. They are compressed, not discarded.

#16.3Tier 3: Low-Fidelity Regional Simulation

Use for:

• deep offscreen areas
• low-importance wildlife and traffic
• broad route and risk modeling
• large world persistence beyond the active area

Simulate:

• regional traffic and labor flow
• predator or threat density
• depletion and replenishment
• weather and travel pressure
• abstracted route use
• background outcomes that can promote upward if they become meaningful

This tier should operate on regions of chunks rather than single chunks when necessary, because meaningful activity such as "village to quarry route" spans multiple local spaces.

Entities and events should move between tiers based on importance, not just a blunt timer.

Possible weighting factors:

• recently seen by player
• currently selected or recently controlled
• belongs to the player settlement
• in danger
• carrying important cargo
• involved in a social or political event
• part of a household the player knows
• connected to a quest, crisis, or unusual event
• near active frontier or infrastructure

This keeps meaningful people and actions "warm" longer than irrelevant background motion.

Prefer:

• role
• current goal
• current plan
• current state
• constraints
• memory
• interruptibility

Example:

Instead of a long hard-coded event queue like:

• walk to rock
• arrive
• mine
• fill inventory
• return
• unload
• repeat

Represent:

• role: laborer
• goal: maintain stone supply
• plan: harvest at quarry A and return to stockpile B
• state: traveling / harvesting / returning / fleeing / idle
• constraints: hunger, safety, load, daylight, orders

This allows replanning when:

• the rock is exhausted
• danger appears
• inventory priorities change
• the villager becomes injured or distracted

#19.1HTN Value

HTN-style decomposition gives legible intent:

• I am hungry
• I need food
• nearest known safe source
• inspect if needed
• eat

This matters because the player should be able to understand behavior, infer motives, and trust that the world runs on readable rules.

In this project, HTN decomposition should usually begin from active needs, obligations, or emotionally charged motivations rather than abstract job labels alone.

Examples:

• I am hungry -> acquire food -> choose safe nearby source -> inspect -> eat
• I am exhausted -> find bed or shelter -> return home if practical -> sleep
• I am lonely and off duty -> seek bonded person -> visit household or tavern -> socialize
• I am angry and recently insulted -> confront target if safe -> vent, escalate, or withdraw depending on temperament
• I am curious and near an unknown site -> investigate if risk is tolerable -> mark discovery or retreat

#19.2Dijkstra / Influence Field Value

Use field-based pressures as decision context rather than a single totalizing AI system.

Examples of useful fields:

• food attractiveness
• safety
• shelter
• social pull
• authority pull
• profit opportunity
• fear
• curiosity
• comfort or home pull

Different people weight the same world differently based on who they are.

These fields should not only represent external resources or threats. They should also serve as the spatial expression of internal need.

Examples:

• high hunger increases attraction to known food sources, kitchens, and households with meals
• high fatigue increases shelter pull, home pull, and avoidance of long exposed travel
• loneliness increases social pull toward bonded actors and populated safe spaces
• irritability lowers tolerance for crowding, delays, and hostile social presence
• curiosity raises attraction to unknown sites, rumors, tracks, and recent disturbances

The important design rule is:

internal state creates pressure, world fields provide options, and HTN chooses interpretable plans from their overlap.

The project should avoid treating "thoughts" as freeform hidden text or magical black-box cognition.

Instead, model internal life as:

• needs
• affect
• appraisals
• focus

This gives enough depth to drive behavior while remaining inspectable and CPU-safe.

#20.11. Needs

Needs are ongoing pressures tied to body, comfort, social life, and meaning.

Candidate baseline needs:

• hunger
• thirst later if the survival model wants it
• warmth
• cooling or heat relief
• rest
• sleep
• safety
• social contact or loneliness relief
• autonomy or frustration tolerance
• comfort
• curiosity
• duty or obligation fulfillment

Important rule:

not every need must be equally simulation-critical.

For example:

• hunger, temperature, sleep, health, and safety directly affect survival and work
• loneliness, curiosity, comfort, and frustration shape behavior tone and story texture

#20.22. Affect

Affect is the villager's short- to medium-term emotional state.

Useful affect channels:

• happiness
• sadness
• anger
• fear
• irritability
• shame
• confidence
• grief
• hope

Affect should be influenced by:

• unmet or fulfilled needs
• recent events
• memories
• bonds
• traits
• current success or failure

Affect is not the same thing as trait.

Examples:

• a humble villager can still become angry
• a timid villager can still become hopeful
• a talkative villager can still become withdrawn during grief

#20.33. Appraisals

Appraisals are the lightweight "thought-like" interpretation layer.

They are not full natural language thoughts. They are structured judgments such as:

• this place is unsafe
• that person is comforting
• this task is urgent
• I am too tired for this
• this unknown site is tempting
• the player is forcing a risky decision

Appraisals should be generated from:

• current needs
• affect
• memory
• role obligations
• nearby world conditions
• relationship state

This is the layer that makes villagers feel understandable instead of random.

#20.44. Focus

Focus is what currently dominates attention.

At any moment, a villager should usually have one or a few top active concerns, such as:

• satisfy hunger
• return to household
• finish assigned hauling job
• avoid predator corridor
• find company
• cool down before collapse
• investigate suspicious tracks

Focus helps:

• choose between competing HTN roots
• explain visible priorities to the player
• compress offscreen decisions without storing every mental step

#20.5Practical Decision Flow

A useful actor loop is:

1. update needs and affect
2. generate appraisals from internal state + world state
3. rank current focus candidates
4. pick or revise HTN root goal
5. use influence fields and local context to choose a concrete plan
6. execute until interrupted, fulfilled, or reprioritized

This gives "thoughtful" behavior without pretending every villager is running a giant cognition simulator.

#20.6Need Categories

The model will likely work best if needs are grouped.

#20.6.1Survival Needs

• hunger
• warmth
• cooling
• sleep
• rest
• health preservation
• immediate safety

These needs deserve the strongest behavioral authority.

#20.6.2Social Needs

• loneliness relief
• belonging
• affection
• status sensitivity later if class/politics deepen

These needs make people feel alive and help relationships matter offscreen.

#20.6.3Psychological Needs

• curiosity
• comfort
• autonomy
• emotional regulation

These should add variation and story rather than constantly overriding settlement function.

#20.6.4Duty Needs

• obey command
• fulfill household duty
• maintain role identity
• answer urgent institutional demands

These needs are important because villagers are not solitary animals. They live inside social structures.

#20.7Behavior Authority Rules

Not every need should be allowed to break plans equally.

A useful authority hierarchy is:

1. acute survival crisis
2. severe safety or health danger
3. hard player or institutional override
4. urgent body maintenance
5. active assigned duty
6. social and emotional needs
7. curiosity and ambient preference

This lets villagers feel alive without making them impossible to rely on.

Example:

• mild loneliness should not cancel a hauling task
• severe exhaustion may absolutely cancel it
• curiosity may reroute a scout near ruins, but not a starving laborer carrying winter food

#20.8Need Thresholds and Curves

Needs should not behave as flat bars with simple linear importance.

Prefer threshold bands such as:

• nominal
• elevated
• urgent
• critical

This makes behavior easier to tune and explain.

Example hunger effects:

• nominal: no major plan disruption
• elevated: food sources gain more attraction
• urgent: villager seeks food soon unless under strong duty pressure
• critical: villager may abandon nonessential work

The same principle applies to sleep, heat, cold, fear, and grief.

#20.9Affect and Memory Feedback

The point of the model is not only to satisfy needs. It is to let life experiences alter future inner state.

Examples:

• repeated hunger increases food anxiety and hoarding tendencies
• repeated cold exposure increases shelter-seeking and firewood sensitivity
• repeated loneliness may deepen sadness or attachment-seeking
• successful hunts may increase confidence and reduce fear on future expeditions
• public humiliation may increase shame, irritability, or noble avoidance

This is where memories, learned tendencies, and current affect lock together.

#20.10UI and Explainability Requirement

The player should never need to guess blindly why someone did something strange.

Inspectors should be able to surface:

• dominant needs
• current mood or affect
• active focus
• top appraisals
• why a plan changed

Example readable explanations:

• Hungry and tired. Returning home before resuming quarry work.
• Avoiding the north road because of prior wolf attack.
• Curious about nearby ruins, but staying on route due to escort duty.

#20.11CPU Safety Rule

This inner-life model must remain cheap.

Do not run full expensive reevaluation every frame for every villager across the world.

Instead:

• embodied actors update frequently
• compressed actors update at decision checkpoints
• regional actors update only when meaningful thresholds, route milestones, or intersections occur

The game should preserve motivational continuity, not perpetual brain simulation.

#21.11. Core Stats

Slow-changing capability values:

• strength
• dexterity
• intelligence
• charisma or social grace
• endurance
• perception

These should affect:

• labor speed
• combat performance
• survival odds
• crafting quality
• social event outcomes
• task suitability

#21.22. Innate Traits

Stable or semi-stable personality tendencies:

• brave
• timid
• gluttonous
• humble
• talkative
• stubborn
• sharp-eyed
• frail

These shape preferences, interpretations, and event modifiers.

#21.33. Learned Tendencies

Habits or heuristics gained from experience:

• checks fruit for rot
• avoids wolf territory
• prefers roads
• distrusts nobles
• keeps distance in combat

This is the "life changed me" layer. It should emerge from real events rather than arbitrary level-up menus alone.

#21.44. Needs and Drives

Ongoing motivational pressures:

• hunger
• warmth
• cooling
• rest
• sleep
• safety
• loneliness
• curiosity
• comfort
• duty

These should act as the main root inputs for plan selection and replanning.

#21.55. Affect

Short- to medium-term emotional condition:

• happiness
• sadness
• anger
• irritability
• fear
• shame
• confidence
• grief

Affect should alter judgment, not replace personality.

#21.66. Memories

Concrete remembered experiences:

• was poisoned by rotten fruit
• survived a boar hunt
• fled from a tiger
• impressed the king
• lost a spouse in winter

Memories should influence future behavior and support narrative surfacing.

#21.77. Bonds

Relationship state with people, families, groups, and institutions:

• affinity
• trust
• fear
• duty
• resentment
• attraction
• loyalty

#21.88. Role

Settlement or social role:

• laborer
• hunter
• merchant
• envoy
• parent
• commander

Role shapes what the settlement expects from a person, even when their personal inclinations differ.

#21.99. Reputation

How broader groups perceive someone:

• court reputation
• household reputation
• village reputation
• trade reputation

#21.1010. Condition

Current physical and emotional state:

• hungry
• sick
• injured
• grieving
• confident
• exhausted

Condition should be treated as the live operational layer produced by needs, affect, health, and temporary circumstance.

The goal is not to lock in an exact save-file format yet. The goal is to define the data domains that must exist if villagers are to behave like persistent people rather than disposable worker units.

#22.1Schema Design Goals

The villager schema should:

• preserve identity across simulation tiers
• support both autonomous and directly controlled behavior
• distinguish stable personality from temporary state
• support causality, biography, and story surfacing
• remain compact enough to scale beyond a tiny population

#22.2Schema Categories

The schema is easiest to reason about if grouped into stable categories rather than one giant flat object.

#22.2.11. Identity

Defines who this villager is at the most basic level.

Suggested fields:

• villager_id
• display_name
• sex or gender presentation if the game needs it
• birth_time or age band
• origin_settlement_id
• culture_id or social background later, if relevant
• family_line_id if heredity matters
• is_named or story-surfaced flag

Purpose:

• supports uniqueness
• supports biography
• supports relationship references
• supports inheritance or household lineage later

#22.2.22. World Affiliation

Defines where the villager belongs socially and politically.

Suggested fields:

• current_settlement_id
• household_id
• faction_id
• residence_building_id
• work_group_id
• command_group_id
• formal_role
• informal_role_tags

Purpose:

• tells the sim who claims the villager
• supports job assignment and lodging
• supports diplomacy and loyalty

#22.2.33. Capability Stats

Defines baseline capability rather than mood or personality.

Suggested fields:

• strength
• dexterity
• intelligence
• charisma
• endurance
• perception

Optional derived stats:

• move_speed
• carry_capacity
• gather_efficiency
• combat_rating
• craft_quality
• social_confidence

Purpose:

• supports task performance
• supports combat and survival
• supports event resolution and role fit

#22.2.44. Stable Traits

Defines relatively persistent personality or temperament.

Suggested fields:

• innate_traits
• temperament_flags
• quirk_tags

Example values:

• brave
• timid
• humble
• talkative
• stubborn
• gluttonous
• sharp-eyed
• frail

Purpose:

• modifies decision weighting
• influences social outcomes
• creates personality distinction

#22.2.55. Learned Tendencies

Defines habits and heuristics acquired through life experience.

Suggested fields:

• learned_tendencies
• learned_risk_biases
• learned_preferences
• learned_avoidances

Example values:

• checks fruit for rot
• avoids north forest road
• prefers guarded routes
• distrusts nobles
• keeps distance in combat

Purpose:

• lets life reshape future choices
• creates legible adaptive behavior without requiring opaque machine learning

#22.2.66. Needs and Current Condition

Defines the villager's present body and emotional condition.

Suggested fields:

• needs_state
• affect_state
• health
• injuries
• illnesses
• active_conditions
• recent_shocks
• dominant_focus
• recent_appraisals

Example needs_state values:

• hunger
• warmth
• cooling
• rest
• sleep_pressure
• safety_urge
• social_need
• comfort_need
• curiosity_drive
• duty_pressure

Example affect_state values:

• happiness
• sadness
• anger
• fear
• irritability
• confidence
• grief

Purpose:

• drives moment-to-moment priorities
• constrains task suitability
• explains replanning and strange-looking behavior
• affects direct control and autonomy alike

#22.2.77. Relationships and Social Bonds

Defines the villager's connection to other people and institutions.

Suggested fields:

• bond_map
• household_relations
• romantic_interest_ids
• dependents
• guardians
• institution_reputation

A bond record might include:

• target actor or group id
• affinity
• trust
• fear
• resentment
• attraction
• duty
• recent interaction markers

Purpose:

• makes loss and favor meaningful
• allows unscripted household formation
• affects diplomacy, loyalty, and social event outcomes

#22.2.88. Memory and Biography

Defines what the villager has lived through and what the game may later surface.

Suggested fields:

• memory_entries
• biography_flags
• notable_firsts
• trauma_markers
• reputation_moments

A memory entry might include:

• memory_id
• type
• timestamp
• location_ref
• other_actor_refs
• intensity
• effects
• visibility

Purpose:

• explains why behavior changed
• supports narrative surfacing
• supports player inspection of who someone has become

#22.2.99. Role and Duty State

Defines what the settlement expects from the villager right now.

Suggested fields:

• primary_role
• secondary_roles
• assigned_job
• priority_overrides
• restricted_duties
• mobilization_status
• current_order_source

Purpose:

• separates personal inclination from social obligation
• supports chain-of-command and reassignment
• lets the player understand why a villager is doing what they are doing

#22.2.1010. Task and Plan State

Defines what the villager is actively trying to do.

Suggested fields:

• goal
• plan_id
• plan_summary
• current_state
• next_milestone
• fallback_plan
• interruptibility
• last_replan_time

Purpose:

• supports the intent-driven actor model
• survives simulation tier changes
• allows offscreen continuity without storing every tiny action

#22.2.1111. Spatial and Travel State

Defines where the villager is and how location should be interpreted.

Suggested fields:

• location_mode
• chunk_id
• region_id
• local_position when fully embodied
• route_id
• route_progress
• destination_ref
• travel_state

Purpose:

• supports tier promotion and demotion
• lets offscreen travelers remain locatable without exact constant pathing

#22.2.1212. Inventory and Equipment

Defines what the villager carries and uses.

Suggested fields:

• inventory_slots
• equipped_items
• carried_resources
• currency
• food_on_person
• tools
• weapons
• armor
• quest_items

Purpose:

• affects work, travel, combat, trade, and survival
• creates continuity between player-led missions and autonomous routines

#22.2.1313. Story and Control Metadata

Defines how "hot" this villager is from the game's point of view.

Suggested fields:

• story_importance_score
• player_interest_score
• recently_controlled
• selected_favorite
• protected_history_window
• last_on_screen_time
• last_significant_event_time

Purpose:

• helps determine simulation priority
• helps choose what events surface to the player
• helps decide promotion and demotion timing

#22.3Minimal Required Record

Even the leanest villager record should probably include at least:

• unique identity
• affiliation
• stats
• stable traits
• current condition
• current role
• current plan state
• spatial abstraction
• inventory summary
• relationship references
• at least a lightweight memory log

Without those fields, the villager stops being a person and starts collapsing back into a generic worker token.

#22.4Example Logical Shape

This is not final serialization, just a reference shape for discussion:

{
  "villager_id": "villager_00182",
  "display_name": "Joren",
  "current_settlement_id": "settlement_riverbend",
  "household_id": "household_fen_03",
  "primary_role": "laborer",
  "stats": {
    "strength": 6,
    "dexterity": 4,
    "intelligence": 3,
    "charisma": 5,
    "endurance": 7,
    "perception": 4
  },
  "innate_traits": ["humble", "talkative"],
  "learned_tendencies": ["checks_fruit_for_rot", "avoids_north_road_at_night"],
  "condition": {
    "health": 0.91,
    "needs_state": {
      "hunger": 0.34,
      "warmth": 0.12,
      "cooling": 0.08,
      "rest": 0.42,
      "sleep_pressure": 0.37,
      "safety_urge": 0.21,
      "social_need": 0.29,
      "comfort_need": 0.24,
      "curiosity_drive": 0.18,
      "duty_pressure": 0.63
    },
    "affect_state": {
      "happiness": 0.41,
      "sadness": 0.12,
      "anger": 0.06,
      "fear": 0.19,
      "irritability": 0.14,
      "confidence": 0.38
    },
    "dominant_focus": "return_stone_before_resting",
    "recent_appraisals": [
      "work_is_important",
      "getting_tired",
      "north_road_feels_unsafe_after_dark"
    ],
    "active_conditions": ["minor_limp"]
  },
  "relationships": {
    "bond_map": [
      {
        "target_id": "villager_00077",
        "affinity": 0.72,
        "trust": 0.66,
        "attraction": 0.41
      }
    ]
  },
  "task_state": {
    "goal": "maintain_stone_supply",
    "plan_id": "plan_quarry_cluster_north",
    "current_state": "returning",
    "next_milestone": "unload_at_stockpile_02",
    "interruptibility": "high"
  },
  "spatial_state": {
    "location_mode": "compressed_active",
    "region_id": "region_riverbend_north",
    "route_id": "route_village_to_quarry_n1",
    "route_progress": 0.63,
    "destination_ref": "stockpile_02"
  },
  "inventory": {
    "carried_resources": [
      { "resource": "stone", "amount": 14 }
    ],
    "tools": ["iron_pick"],
    "food_on_person": 1
  },
  "memory_entries": [
    {
      "memory_id": "mem_18822",
      "type": "wolf_attack_survived",
      "intensity": 0.62,
      "effects": ["risk_bias_north_road_up"]
    }
  ],
  "story_importance_score": 0.58,
  "recently_controlled": true
}

#22.5Design Notes

Important schema rules:

• do not store everything as a trait
• do not store every tiny past action forever
• keep temporary condition separate from personality
• keep needs and affect separate from stable traits
• keep appraisals and focus lightweight rather than trying to store full prose thoughts
• keep memory separate from reputation
• keep plan state separate from role
• keep direct-control metadata separate from diegetic identity

This separation is what makes the schema scalable and interpretable.

• inherited or generated baseline tendencies
• life-acquired tendencies and memories
• numeric capability and progression

If heredity is added later, likely inheritable components include:

• stat tendencies
• some stable temperament traits
• family resemblance markers

Likely non-heritable components include:

• specific memories
• learned situational heuristics
• current relationships
• temporary conditions

This separation keeps the system legible and prevents "everything is DNA" from becoming an unusable category.

Example relationship stages:

• strangers
• acquaintance
• favorable impression
• recurring contact
• attachment
• courtship
• partnership
• shared household
• children

These states should be influenced by:

• proximity and repeated encounters
• compatible traits
• mutual aid
• shared adversity
• household needs
• player intervention

This is not intended to be a dating sim. It is meant to make households, families, and emotional stakes feel real.

Avoid:

• infinite bespoke branching authored for every possible person

Prefer:

• structured event templates
• parameterized by who is involved
• filtered through traits, memories, stats, reputation, and current politics

Example:

The king summons the player's settlement.

Relevant evaluated inputs:

• who is sent
• what force accompanies them
• prior reputation
• envoy intelligence and charisma
• traits such as humble or motormouth
• current mood of the court
• chance or fate modifiers

Possible outcomes:

• court intimidation
• offense
• amusement
• respect
• unexpected trust
• political suspicion

The narrative layer should present the result clearly, but the underlying logic should remain systemic rather than fully hand-authored.

The project should not treat quests as a separate disconnected content track pasted on top of the world. Quests and events should arise from, react to, and permanently alter the same systems that govern villagers, routes, resources, danger, and relationships.

#26.1Architectural Goal

The quest/event system should:

• generate meaningful story from simulation state
• allow authored content to enter the world without breaking systemic continuity
• support both ambient incidents and player-centered adventures
• preserve consequences after the "event scene" ends

The system should feel like:

• the world is producing events
• the player is stepping into some of them
• authored beats are shaping possibilities, not suspending reality

#26.2Three Narrative Sources

The game should likely support three main sources of quest/event content.

#26.2.11. Pure Systemic Events

These are generated directly from world state and simulation intersections.

Examples:

• a villager is attacked on a road
• a household runs short on food
• two people form a bond after mutual aid
• predators begin stalking a trade corridor
• a worker goes missing

These require little or no authored narrative framing to exist.

#26.2.22. Structured World Events

These use templates triggered by conditions in the simulation.

Examples:

• the king sends a summons
• a merchant requests escort
• a shrine is discovered in the woods
• a traveler arrives with a rumor
• a nearby town asks for aid

These are partially authored but still parameterized by:

• who is involved
• where it happens
• what the current political and economic context is
• what traits or memories the actors bring into the scene

#26.2.33. Handcrafted Quest Arcs

These are rarer authored sequences with stronger bespoke structure.

Examples:

• slay the dragon
• investigate a cursed ruin
• recover a lost banner tied to a local lineage
• negotiate a treaty with a nearby power later

Even these should still read and write to the same world state rather than operating in a sealed narrative bubble.

#26.3Event Model

An event should not simply be a pop-up. It should be a stateful world object or record with:

• trigger conditions
• participant rules
• location or region relevance
• urgency
• visibility rules
• possible resolutions
• world consequences

At minimum, an event record should answer:

• what is happening
• why it is happening
• who can respond
• how long it remains relevant
• what changes if ignored
• what changes if completed, failed, or diverted

#26.4Quest Model

A quest should be understood as a durable chain of related event states rather than a single scripted mission blob.

A quest may contain:

• one or more event nodes
• one or more travel segments
• optional combat or social scenes
• branching consequences
• persistent state across pauses and interruptions

This matters because the player may:

• leave mid-quest
• send different people than originally intended
• allow autonomous continuation or neglect
• return later to an evolved situation

#26.5Event Lifecycle

A useful event lifecycle is:

1. dormant
2. triggered
3. surfaced or hidden
4. engaged
5. resolved
6. persisted as aftermath

#26.5.1Dormant

The template exists as a possibility but is inactive.

#26.5.2Triggered

World conditions satisfy the activation rules.

#26.5.3Surfaced or Hidden

The event may become:

• player-visible
• locally visible only
• background-only for now

Not every triggered event should immediately interrupt the player.

#26.5.4Engaged

The event becomes actively processed by:

• direct player response
• autonomous villager response
• timed world escalation

#26.5.5Resolved

The event reaches an outcome state.

#26.5.6Persisted as Aftermath

Its consequences remain in:

• memory
• reputation
• resources
• relationships
• geography
• future event eligibility

#26.6Trigger Types

Events and quests should be able to trigger from multiple classes of conditions.

Useful trigger classes:

• location discovery
• actor state thresholds
• relationship thresholds
• settlement need thresholds
• time or season
• route danger
• prior event completion
• institutional request
• rumor propagation
• rare chance under specific conditions

Examples:

• entering a ruin region with a perceptive scout
• food stores falling below winter reserve
• a villager surviving repeated predator attacks
• the court hearing of your settlement's rise
• repeated merchant traffic making a road a bandit target later

#26.7Participant Selection

Events should not assume a fixed hero.

They should define who may participate through selection rules such as:

• any villager
• any envoy-capable villager
• party with hunting tools
• adult household member
• settlement leader or designated delegate later
• anyone physically present when the event fires

This is essential to the project's promise that:

• who you send matters
• who happened to be there matters
• ordinary people can become story people

#26.8Event Input Domains

When evaluating an event, the system should read from real simulation domains.

Useful inputs:

• actor stats
• traits
• learned tendencies
• memories
• relationships
• reputation
• current condition
• inventory and tools
• travel route and region danger
• settlement status
• season or weather
• prior event history

This prevents event outcomes from feeling detached from the rest of the game.

#26.9Resolution Modes

Events should support more than one type of resolution.

Useful resolution modes:

• direct control scene
• tactical combat
• social choice or diplomacy scene
• autonomous resolution
• timer-based world outcome
• deferred follow-up event

Examples:

• a boar hunt becomes a direct control encounter
• a court summons becomes a social resolution scene
• a missing person alert may resolve autonomously if not personally followed
• a discovered ruin may sit dormant until someone chooses to explore it

#26.10Ambient Versus Foreground Events

The event architecture should strongly distinguish between:

• ambient events
• surfaced events
• foreground quests

#26.10.1Ambient Events

These shape the world but may never get a full UI moment.

Examples:

• two villagers become closer
• a worker starts avoiding a road
• a household falls into mild stress

#26.10.2Surfaced Events

These deserve player awareness but not necessarily immediate manual intervention.

Examples:

• merchant asks for escort
• route becomes unsafe
• local shrine rumor spreads

#26.10.3Foreground Quests

These are events the player actively takes ownership of.

Examples:

• take three villagers to hunt the boar
• send an emissary to answer the king
• follow the trail to the missing worker
• investigate a dragon threat

This layering keeps the world story-rich without spamming the player.

#26.11Escalation and De-Escalation

Events should be able to move up and down in dramatic intensity.

Examples of escalation:

• rumor becomes request
• request becomes crisis
• crisis becomes quest
• offscreen danger becomes on-screen encounter

Examples of de-escalation:

• ignored event expires quietly
• resolved danger becomes reputation or memory only
• unfinished expedition returns to ambient state

This allows the narrative system to breathe instead of only ever increasing drama.

#26.12Event Consequence Model

Every meaningful event should be able to write consequences into at least one simulation domain.

Possible consequence domains:

• actor memory
• relationship change
• reputation change
• injury or death
• inventory and resources
• settlement need or pressure
• route risk
• institutional stance
• unlocked future events
• biome or site state

This is the heart of the whole system.

If an event does not alter the ongoing world in some meaningful way, it is probably flavor text rather than a quest/event worth simulating deeply.

#26.13Rumors, Discovery, and Information Spread

The player should not necessarily know every event the moment it triggers.

Information should sometimes arrive through:

• direct witnessing
• returning participants
• household gossip
• merchants or travelers
• scouts
• formal messages

This supports a world that feels larger than the player's immediate camera.

It also gives room for:

• partial information
• false confidence
• delayed response
• mystery and discovery

#26.14Failure, Neglect, and Divergence

Quests and events should support meaningful non-completion.

Possible non-success states:

• ignored
• expired
• failed
• partially completed
• redirected into a new event

Examples:

• you ignore the summons and court opinion worsens
• you fail to escort the merchant and trade trust drops
• you arrive late and find only evidence of what happened
• the dragon kills livestock before the hunt begins

The system should not assume the player must or can do everything.

#26.15Direct Control Integration

The event architecture should explicitly support handoff into direct control.

A foreground event may:

• nominate preferred participants
• suggest a party composition
• reserve travel goals
• warm nearby simulation
• create encounter nodes along a route

When direct control ends, the event should:

• re-read participant state
• update consequences
• continue, branch, or resolve

This is how the quest system and villager biography stay welded together.

#26.16Job System Integration

Events and quests should be able to create, suppress, or reprioritize jobs.

Examples:

• a summons creates an envoy preparation job
• a missing person event creates a search job
• a dragon threat increases livestock protection jobs
• a trade request creates gather and hauling jobs

This prevents the narrative layer from floating above settlement life.

#26.17Persistence Requirements

Quest and event state must persist cleanly across:

• save/load
• simulation tier changes
• camera departure
• participant reassignment
• partial completion

An unresolved event should not forget:

• who was involved
• what has already happened
• what deadlines still matter
• what world facts have changed so far

#26.18Anti-Goals

Avoid these traps:

• quests that ignore who the participants actually are
• event popups detached from simulation state
• endless urgency spam
• authored arcs that reset world consequences when complete
• events that require a chosen hero and break if normal villagers are used
• flavor events that produce no lasting effect

#26.19Recommended First Implementation

The first quest/event architecture only needs to prove a small set of event types:

• one route danger event
• one social summons event
• one missing-person or rescue event
• one discovery event
• one larger expedition-style hunt or monster threat

If those can all:

• trigger from real world state
• use real participants
• support direct control when appropriate
• leave permanent consequences behind

then the architecture is on the right track.

#27.1Ambient Story

Generated without direct player action:

• friendships
• route habits
• background romances
• family struggles
• work injuries
• quiet social changes

These should mostly surface through summaries, notifications, and world-state changes rather than constant interruption.

#27.2Playable Story

Generated when the player steps in or when stakes cross a threshold:

• taking three villagers on a boar hunt
• escorting a merchant
• saving someone from danger
• personally resolving a diplomatic visit
• choosing who answers a summons

These should feel interactive, memorable, and identity-shaping.

The player should not need to read an endless feed of trivial life updates.

Needed categories:

• ambient digest
• important settlement alerts
• relationship or household changes
• route danger or disappearance
• quest and event prompts
• selected-character biography and history

Examples of acceptable surfacing:

• Tomas and Elira have grown close.
• Mira now avoids the north road after a wolf attack.
• Bren returned injured from the boar hunt.
• The court remembers Joss as insolent.
• The Weaver household is struggling since Coren has not returned.

The system should help the player notice consequences without drowning them.

This project is not only a simulation design problem. It is also a legibility problem.

If the UI fails, the player will experience the game as:

• random
• noisy
• overcomplicated
• emotionally flat
• harder than it actually is

The interface must therefore do more than present commands. It must act as the translation layer between:

• simulation truth
• player intention
• emotional attachment

#29.1Architectural Goal

The UI should make a deep simulation feel:

• readable
• governable
• personal
• actionable

without flattening villagers into abstract icons or drowning the player in internal state.

The player should almost always be able to answer:

• what is happening
• why it is happening
• why it matters
• what I can do about it

#29.2Core UI Philosophy

The UI should be built around three simultaneous lenses:

#29.2.11. Settlement Lens

Use for:

• stockpiles
• jobs
• shortages
• building and upgrades
• route safety
• broad labor pressure

This is the macro governance layer.

#29.2.22. Person Lens

Use for:

• villager biography
• current plan
• traits and condition
• memories
• bonds
• recent notable events

This is the attachment layer.

#29.2.33. Episode Lens

Use for:

• direct control
• hunts
• escorts
• crises
• tactical incidents
• quests and negotiations

This is the intervention layer.

The player should be able to move between these lenses fluidly, without feeling like they entered separate games.

#29.3Required Player Questions

Every important system should be surfaced so the player can answer a few recurring questions quickly.

#29.3.1Settlement Questions

• what does the settlement need right now
• what is blocked
• what is dangerous
• what is falling behind
• which people or households are under strain

#29.3.2Person Questions

• what is this villager doing
• why did they choose that
• what are they like
• what happened to them recently
• why are they refusing, failing, or struggling

#29.3.3World Questions

• what changed while I was away
• which route is unsafe and why
• what event happened here
• who knows about this
• what opportunity is emerging nearby

If the interface cannot answer those well, the design will feel much more opaque than it really is.

#29.4Primary Information Layers

The game should probably surface information in layered bands rather than one universal feed.

#29.4.11. Constant HUD Layer

Should include only the most important persistent information, such as:

• current stockpile pressure
• selected entity or group summary
• active alerts count
• current direct-control state
• time, season, and perhaps weather context

This layer should stay calm. It is not the place for life-story spam.

#29.4.22. Notification Layer

Used for:

• urgent threats
• major completions
• significant injuries or deaths
• missing-person alerts
• diplomatic summons
• surfaced event opportunities

Notifications should be priority-ranked and style-coded so the player can tell:

• urgent now
• important soon
• notable but not interrupting

#29.4.33. Digest Layer

Used for ambient life updates that matter but do not require interruption.

Examples:

• two villagers formed a bond
• a household is under strain
• a route is becoming feared
• someone learned a new tendency

This should feel like a town chronicle, not a chat log flood.

#29.4.44. Inspector Layer

Used when the player clicks a villager, route, site, building, or event.

This is where the game earns trust. Inspectors should explain:

• state
• cause
• blockers
• history
• likely next step

#29.4.55. Map Overlay Layer

Used for:

• route danger
• work zones
• regional warmth
• settlement influence
• known incidents
• search areas
• infrastructure value

The map should help the player reason spatially, not just aesthetically.

#29.5Selection and Control UX

The player should be able to select:

• one villager
• a small party
• a building
• a route
• a site
• a household

Each selection type should expose a different but consistent inspector.

#29.5.1Villager Selection Should Reveal

• current action
• current plan
• role
• condition
• key traits
• important memories
• social ties
• current obligations
• recent events

The goal is not to dump every stat. The goal is to help the player understand who this person is and why they are behaving as they are.

#29.5.2Party Selection Should Reveal

• members
• readiness
• supplies
• current goal
• route risk
• morale or confidence summary later if used

This inspector should support hunts, escorts, and expeditions without becoming a full RPG hotbar mess unless the eventual combat design truly needs that depth.

#29.5.3Building and Site Selection Should Reveal

• current function
• supply needs
• labor assigned or claimed
• blockages
• connected routes
• recent throughput or inactivity

This keeps the builder side explainable.

#29.6Explainability Rules

Whenever possible, the UI should explain outcomes in plain causal language.

Good examples:

• Quarry work slowed: north road unsafe after wolf attack.
• Joren refused escort job: exhaustion severe and confidence low.
• Oven idle: no grain delivered from west field.
• Court distrust persists: steward insult remembered and repeated by rumor.

Bad explanations:

• efficiency -14%
• task failed
• AI reprioritized
• route invalid

Numbers can support understanding, but plain-language causality should lead.

#29.7Event Surfacing Model

The UI should not present every event at the moment it happens.

Instead, events should pass through surfacing tiers:

#29.7.1Ambient

Logged quietly into digest or biography surfaces.

Use for:

• low-stakes relationship shifts
• repeated route routines
• minor learned tendencies
• household texture changes

#29.7.2Surfaced

Shown as a player-readable update or option, but not hard-pausing attention.

Use for:

• a route becoming unsafe
• a worker failing to return
• a merchant request
• a household entering visible stress

#29.7.3Foreground

Presented as an active, emotionally or strategically significant moment.

Use for:

• death or disappearance
• hunt or rescue opportunity
• diplomatic summons
• major construction blockage tied to world conditions
• direct-control crises

This lets the world feel alive without forcing the player to babysit every heartbeat.

#29.8Biography and History Presentation

The project needs a strong biography surface for important villagers.

A villager profile should likely contain:

• identity and household
• role and current duty
• short trait summary
• important memories
• major life events
• notable bonds
• reputation notes
• player-led episode history

This should read less like a spreadsheet and more like a compact living record.

Possible presentation style:

• short descriptor line
• recent life events
• current concerns
• known relationships
• notable past turning points

This is one of the main places where "ordinary lives become stories" becomes tangible.

#29.9Route and Region Observability

Routes and regions need their own inspectability because so much of the game's world logic lives there.

Selecting a route or corridor should reveal:

• safety level
• known recent incidents
• travel volume
• infrastructure condition
• weather or environmental pressure
• current active users if locally relevant

Selecting a region should reveal:

• nearby sites
• settlement influence
• known threats
• notable recent intersections
• warmth or simulation attention level if the player is allowed to reason about it indirectly

The UI does not need to expose raw simulation tier names, but it should expose the consequences of those tiers.

#29.10Household and Social Readability

Households are one of the main bridges between abstract settlement management and personal life.

The UI should make it possible to inspect:

• who belongs to a household
• who is absent
• whether the household is stable, strained, grieving, or thriving
• what shortages affect it
• what recent events shaped it

This is important because many of the game's most memorable consequences are not just resource losses. They are social absences.

#29.11Temporal Readability

The game should help the player understand change over time, not only current state.

Useful temporal surfaces:

• recent event timeline for selected villager, household, or settlement
• "since you were away" summaries after camera shifts or time compression
• route incident history
• building throughput changes

The player should be able to tell not just:

• what is true now

but also:

• what changed
• what caused it
• whether the trend is getting better or worse

#29.12Alert Discipline

Alerts should be treated as a precious resource.

Strong alert rules:

• interrupt only when player action may reasonably matter
• downgrade repeated similar alerts into grouped summaries
• avoid re-alerting the same blocked condition every few seconds
• prefer escalation when a condition worsens, not when it merely persists

Examples:

• good: North route now unsafe after second wolf incident.
• good: Three households now short on firewood.
• bad: Joren still walking.
• bad: Quarry still blocked.

Poor alert discipline will destroy the cozy side of the game faster than almost anything else.

#29.13CPU-Aware UX Strategy

The UI can help preserve performance by not demanding pointless precision from the simulation.

For example:

• route risk can be shown as a band or story-backed status rather than exact hidden dice math
• offscreen progress can be shown as believable state milestones rather than literal frame replay
• social drift can be surfaced as notable changes rather than constant percentage churn

In other words, the UI should ask the simulation for:

• meaningful summaries
• recent causes
• actionable blockers

not full raw telemetry for every actor all the time.

This is one of the quiet ways UX and performance reinforce each other.

#29.14Developer Observability Requirements

The game will likely need robust internal debug surfaces during development.

Useful debug overlays and inspectors:

• actor simulation tier
• actor heat score
• current plan and milestone
• job claim ownership
• route segment timing
• interruption trigger reason
• event surfacing tier
• memory write-back log
• rumor propagation path
• settlement pressure sources

The shipping game may hide most of this, but the team will need it constantly.

#29.15Anti-Goals

Avoid these UI failures:

• turning the game into a scrolling event inbox
• hiding simulation reasons behind vague flavor text
• exposing so much raw state that the player feels they need a spreadsheet
• making direct control feel detached from the same inspectors used in normal play
• burying personhood under macro-only resource panels
• requiring constant menu-diving to understand blocked labor

#29.16Recommended First Implementation

The first UI/observability pass only needs to prove:

• one good villager inspector
• one good building/job inspector
• one route danger overlay
• one digest surface for ambient life
• one urgent alert surface
• one small event/episode prompt flow

If those pieces feel clear, the rest can expand from them.

The key idea is:

the world should not only produce danger. it should produce intersections.

An intersection happens when actors, routes, sites, needs, timing, and conditions overlap in a way that could plausibly generate a meaningful outcome.

That outcome might be:

• hostile
• social
• economic
• environmental
• exploratory
• institutional

This is a broader and more accurate framing than "combat and danger," because the same underlying architecture should support:

• a tiger attack
• a merchant asking for escort
• two villagers falling in love on a repeated route
• a lost child being discovered
• a shrine being found by accident
• a desperate traveler pleading for help
• a worker finding a richer vein of ore

#30.1Architectural Goal

The encounter/intersection system should:

• detect meaningful overlaps in world activity
• convert those overlaps into plausible incidents
• decide whether they stay ambient or escalate
• preserve consequences afterward

It should feel like:

• the world is constantly full of possibility
• only some possibilities become incidents
• only some incidents become surfaced events
• only some surfaced events become direct-control scenes

#30.2Core Model

An intersection should emerge from the meeting of several domains:

• actor state
• route state
• site state
• region state
• timing
• social context
• chance

You do not need a fully bespoke rule for every story beat.

Instead, you want a system that can answer:

• who was where
• why they were there
• what else was active nearby
• what conditions were favorable to an incident
• whether that incident mattered enough to escalate

#30.3Intersection Inputs

The most useful input domains are likely:

• actor plans
• actor traits and condition
• relationship state
• route usage
• site properties
• region danger and opportunity fields
• time of day
• season and weather
• current quests or incidents
• settlement pressures

Examples:

• an exhausted laborer on a night route through predator-heavy woods
• a talkative merchant arriving in a politically tense town
• two unmarried villagers repeatedly assigned to the same gathering loop
• a perceptive scout moving through shrine-rich wilderness
• a hungry child near an unsafe forest edge

#30.4Intersection Categories

The system should classify intersections by type so they can share logic without all becoming combat.

#30.4.11. Hostile Intersections

Examples:

• predator attack
• monster ambush
• territorial confrontation
• pursuit
• road harassment later

Typical consequence domains:

• injury
• death
• fear
• route avoidance
• reputation for bravery or failure

#30.4.22. Social Intersections

Examples:

• chance conversation
• plea for help
• romance seed
• argument
• reconciliation
• awkward court impression

Typical consequence domains:

• affinity
• resentment
• attraction
• trust
• future invitations or exclusions

#30.4.33. Economic Intersections

Examples:

• trade opportunity
• blocked delivery
• shared hauling opportunity
• found surplus
• missing cargo

Typical consequence domains:

• resources
• job creation
• stockpile pressure
• market access
• trust in routes or partners

#30.4.44. Discovery Intersections

Examples:

• shrine found
• tracks discovered
• cave entrance noticed
• herb patch revealed
• hidden shortcut identified

Typical consequence domains:

• map knowledge
• quest availability
• region familiarity
• new jobs or expeditions

#30.4.55. Environmental Intersections

Examples:

• storm exposure
• fire spread
• spoiled food discovery
• sickness exposure
• flood crossing failure

Typical consequence domains:

• health
• travel time
• household stress
• infrastructure damage

#30.4.66. Institutional Intersections

Examples:

• royal summons delivered
• tax collector arrives
• town request for aid
• messenger spreads warning
• ritual obligation is invoked

Typical consequence domains:

• diplomacy
• deadlines
• settlement obligations
• future event chains

#30.5Intersection Pipeline

A useful high-level pipeline is:

1. background opportunity scan
2. candidate intersection generation
3. plausibility filtering
4. intensity evaluation
5. resolution mode selection
6. aftermath write-back

#30.5.11. Background Opportunity Scan

The world identifies where overlapping conditions exist.

This should usually happen at:

• route level
• site level
• region level
• active actor cluster level

#30.5.22. Candidate Intersection Generation

The system proposes a small set of possible incidents.

Examples:

• wolf attack candidate
• romance interaction candidate
• found object candidate
• rumor arrival candidate

#30.5.33. Plausibility Filtering

The system rejects candidates that do not make sense.

Filters may include:

• wrong time
• wrong participants
• incompatible current conditions
• event cooldowns
• repetition control
• insufficient narrative value

#30.5.44. Intensity Evaluation

The system asks how meaningful this incident is.

Factors may include:

• danger
• rarity
• participant importance
• player relevance
• consequence potential
• current quest entanglement

#30.5.55. Resolution Mode Selection

The incident becomes:

• ambient background change
• surfaced notification
• autonomous resolution
• event record
• direct-control scene

#30.5.66. Aftermath Write-Back

The incident updates the world through memory, jobs, routes, relationships, resources, or event state.

#30.6Ambient, Surfaced, and Embodied Intersections

Not every intersection should produce an encounter scene.

There should be at least three outcome bands:

#30.6.1Ambient

The incident resolves quietly and only alters simulation state.

Example:

• two villagers become friendlier after repeated work overlap

#30.6.2Surfaced

The incident becomes visible to the player but may still resolve without direct control.

Example:

• north route increasingly unsafe due to predator activity

#30.6.3Embodied

The incident becomes a richer local scene.

Example:

• the player-controlled hunting party is actually attacked by the boar

This helps keep the world lively without overwhelming the player with constant scene changes.

#30.7Repetition and Novelty Control

Intersection systems can become noisy if they fire too often.

The architecture should therefore track:

• local repetition
• participant repetition
• recent similar outcomes
• incident fatigue
• novelty weight

This prevents:

• endless wolf attacks on the same road every day
• every repeated route producing identical conversations
• all discovery moments feeling interchangeable

#30.8Opportunity Fields

Just as regions can have risk fields, they can also have opportunity fields.

Useful opportunity fields:

• social density
• trade activity
• mystery density
• forage opportunity
• institutional attention
• romance opportunity
• discovery richness

These do not guarantee incidents. They simply make certain types of intersections more plausible in certain places.

#30.9Path Intersections

One of the most important sub-systems is path intersection.

Any time actors or parties share:

• a route
• a site
• a checkpoint
• a travel window

the system should have a chance to ask whether something happens.

Examples:

• merchant meets villager in distress
• two couriers exchange rumor
• hunter crosses predator track
• search party finds evidence left by missing laborer

This is likely one of the strongest sources of emergent story in the whole project.

#30.10Site Intersections

Sites should also act as opportunity magnets.

A shrine, quarry, bridge, market, den, ruin, or river crossing should each bias toward different incident types.

Examples:

• bridge: blockage, toll demand, rescue, accident
• ruin: discovery, danger, omen, artifact
• market: trade, rumor, insult, recruitment
• den: attack, tracks, cub discovery, territorial shift

This makes geography feel meaningful rather than decorative.

#30.11Timed Intersections

Some intersections should only become possible at certain times.

Examples:

• wolves hunt more boldly at dusk
• a court only receives envoys during formal hours
• certain flowers bloom after rain
• travelers camp at night and share stories

This helps the world feel patterned rather than random.

#30.12Multi-Step Intersections

Some incidents should chain into follow-up intersections.

Examples:

• tracks found -> search begins -> body or survivor found
• flirtation begins -> repeated meetings -> courtship
• unsafe route report -> escort request -> ambush or safe passage

The system should support this without requiring every chain to be a fully handcrafted quest line.

#30.13Intersections and Direct Control

Direct control should strongly bias the system toward embodied resolution, because the player is explicitly saying:

• this moment matters to me

So when directly controlling a party, the architecture should be more willing to:

• instantiate local encounters
• preserve exact route context
• surface intermediate discoveries
• make consequences immediate and legible

This is one of the major rewards for zooming into people.

#30.14Intersections and Offscreen Continuity

Offscreen intersections should still be capable of changing lives.

The system should support offscreen outcomes such as:

• someone is injured
• someone falls in love
• someone discovers a clue
• someone never returns
• a route becomes more feared
• a household gains or loses hope

This is where the world starts to feel alive rather than paused when unseen.

#30.15Anti-Goals

Avoid these traps:

• treating every intersection as combat
• resolving all offscreen life through pure dice without context
• surfacing every small interaction to the player
• making incidents feel random instead of situated
• allowing no peaceful or surprising intersections in dangerous places

#30.16Recommended First Implementation

The first implementation only needs to prove a few intersection classes:

• one hostile route encounter
• one social chance meeting
• one discovery intersection at a site
• one environmental setback
• one institutional arrival or summons

If those all work through the same general pipeline, the architecture is probably sound.

The game should not stop at:

• something happened
• outcome resolved
• scene ended

It should continue into:

• who remembers it
• how strongly they remember it
• what they tell others
• what institutions record or infer from it
• how future behavior and social standing change

This is the system that turns incidents into history.

#31.1Architectural Goal

The memory and reputation layer should:

• preserve the personal meaning of lived events
• spread socially relevant knowledge outward when appropriate
• let institutions react without omniscience
• create delayed consequences that feel earned

The world should feel like it has a social afterlife, not just immediate outcomes.

#31.2Three Main Consequence Layers

A useful framing is three linked layers:

1. personal memory
2. social propagation
3. reputation state

#31.2.11. Personal Memory

What an actor privately carries forward from experience.

Examples:

• fear of a route
• affection for a rescuer
• shame from a public insult
• confidence after a successful hunt
• grief after a family death

#31.2.22. Social Propagation

What travels from one actor to others.

Examples:

• gossip
• rumor
• household report
• survivor testimony
• merchant retelling
• formal message

#31.2.33. Reputation State

What groups, settlements, and institutions come to believe about a person, party, or settlement.

Examples:

• this villager is brave
• this household is unreliable
• this settlement ignores obligations
• this envoy is charming but foolish
• this road is unsafe

#31.3Core Principle

Memory should not automatically equal reputation.

Just because one villager knows something happened does not mean:

• everyone knows
• the story is accurate
• the court believes it
• the settlement records it formally

The architecture should separate:

• lived experience
• transmitted account
• accepted social truth

That separation is where a lot of interesting story comes from.

#31.4Memory Formation

Not every action deserves a durable memory.

The system should form or strengthen memory based on factors such as:

• emotional intensity
• danger
• novelty
• repetition
• social significance
• player involvement
• life-stage importance

Examples of memory-worthy incidents:

• first hunt
• first kill
• near-death escape
• diplomatic humiliation
• birth of a child
• loss of a spouse
• being saved by another villager
• discovering a sacred site

Examples of low-memory incidents:

• carrying one more stack of wood
• taking a routine walk
• everyday idle chatter with no consequence

#31.5Memory Structure

Memory records should probably stay lightweight but meaningful.

A memory entry may include:

• memory id
• category
• timestamp
• location or region ref
• involved actors
• intensity
• valence
• tags
• behavior effects
• social shareability
• decay profile

Useful categories:

• danger
• achievement
• loss
• relationship
• discovery
• institution
• survival
• humiliation

Valence can help express whether the memory is:

• positive
• negative
• mixed
• unresolved

#31.6Memory Effects

Personal memories should be able to affect several downstream systems.

Examples:

• route avoidance
• courage gain or loss
• attraction or resentment
• food caution
• trust in a leader
• willingness to accept future assignments
• social confidence
• superstition or sacred behavior

This is how "life changed me" becomes systemic rather than purely cosmetic.

#31.7Memory Decay and Persistence

Not all memories should last forever at equal strength.

The architecture should support:

• fading intensity
• persistent scars
• reinforcement through repetition
• reactivation through reminders

Examples:

• a trivial embarrassment fades
• repeated wolf attacks harden into a strong route fear
• a spouse's death remains important for years
• seeing the same shrine again refreshes an old discovery memory

This keeps memory meaningful without storing every detail forever as equally live.

#31.8Shareability Rules

Memories should vary in how likely they are to be shared.

Useful shareability dimensions:

• private
• household
• social
• public
• institutional

Examples:

• private: secret attraction, shame, grief
• household: illness, missing provider, home shortage
• social: rescue story, insult, romance rumor
• public: public duel, official envoy behavior, market incident
• institutional: failed tribute, honored service, treaty insult

This is a critical distinction. Some things are remembered but not widely known.

#31.9Propagation Channels

Information should move through concrete channels, not universal instant knowledge.

Useful channels:

• direct witness
• participant retelling
• household conversation
• workplace spread
• traveler gossip
• merchant networks
• official messenger
• written or formal record later

Each channel can differ in:

• speed
• reach
• distortion
• credibility

#31.10Propagation Rules

When an incident happens, the system should ask:

• who directly knows
• who is likely to be told
• how quickly it travels
• how much detail survives
• who believes it

This can depend on:

• relationship strength
• trait tendencies like talkative or secretive
• institutional importance
• remoteness
• communication routes
• elapsed time

#31.11Rumor Versus Report

The architecture should distinguish between:

• rumor
• witness account
• accepted report
• official record

#31.11.1Rumor

Low-certainty socially spread information.

Can:

• be incomplete
• be distorted
• spread widely

#31.11.2Witness Account

High-certainty from someone directly involved or present.

Can still be biased, frightened, confused, or self-serving.

#31.11.3Accepted Report

Information a community more or less believes.

This is often what matters for practical social consequences.

#31.11.4Official Record

Information recognized by a formal institution.

This may matter for:

• diplomacy
• law
• taxation
• honors
• punishment

#31.12Reputation Domains

Reputation should not be one universal score.

It should exist in domains.

Useful domains:

• personal reputation
• household reputation
• settlement reputation
• trade reputation
• court or institutional reputation
• route reputation
• military or bravery reputation later

Examples:

• loved at home, distrusted by court
• known as brave locally, unknown abroad
• excellent trader, poor diplomat
• settlement respected for aid, feared for strength

This supports more interesting outcomes than a single fame meter.

#31.13Reputation Carriers

Reputation can attach to different entities:

• individual villager
• household
• party
• settlement
• route
• site

Examples:

• Joren is brave
• the Fen household is unlucky
• the north road is cursed
• Riverbend keeps its promises

This lets social meaning exist at multiple scales.

#31.14Reputation Update Triggers

Reputation should usually change on notable actions, not routine noise.

Examples:

• public success or failure
• visible bravery or cowardice
• betrayal or loyalty
• trade fulfillment or default
• insulting a court
• rescuing someone important
• neglecting an obligation

Routine labor should mostly influence reputation only through accumulated pattern, not every single act.

#31.15Distortion and Bias

Propagation should not always preserve truth perfectly.

Distortion sources may include:

• fear
• pride
• faulty memory
• gossip exaggeration
• political framing
• incomplete witness perspective

This gives room for:

• misunderstood heroism
• unfair suspicion
• local myths
• conflicting stories about the same event

That said, distortion should be used carefully. Too much uncertainty becomes noise.

#31.16Household Propagation

Households should act as a special propagation unit.

Within a household, important information should spread quickly:

• injury
• death
• absence
• food shortage
• affection
• grief
• conflict

This matters because households are where many emotional and logistical consequences become real first.

#31.17Settlement Propagation

Settlements should have slower, broader social spread.

Likely drivers:

• shared workplaces
• market spaces
• guard posts
• taverns later
• formal notices
• returning expeditions

Not every villager needs to know every story, but the settlement should gradually accumulate a sense of:

• who is reliable
• what routes are feared
• which families are thriving or struggling
• what external powers are asking of them

#31.18Institutional Propagation

Courts, towns, trade partners, and other institutions should have their own information filters.

Institutions may learn through:

• envoys
• written records
• official witnesses
• repeated trade behavior
• public incidents

Institutional reputation should generally change slower than household gossip, but hit harder when it does.

#31.19Memory and Reputation Feedback

Memory and reputation should reinforce one another without collapsing into one thing.

Examples:

• a villager remembers humiliation and becomes cautious
• others hear about it and trust them less as envoy
• future poor performance then reinforces both memory and reputation

or:

• a hunter rescues a child
• the child remembers the rescue
• household spreads gratitude
• village views the hunter as dependable
• hunter gains confidence and future opportunities

This feedback loop is where lives begin to feel storied.

#31.20UI and Explainability Requirements

The player should be able to inspect why a belief or reputation exists.

Useful outputs:

• recent notable memories for a villager
• known rumors affecting a route or place
• why a settlement distrusts an envoy
• which event changed a household's standing

Examples:

• Joren avoids the north road after surviving a wolf attack.
• Court distrust increased after Mara insulted the king's steward.
• The Fen household is grieving after Coren failed to return.

If reputation changes feel unexplained, they will feel arbitrary.

#31.21Anti-Goals

Avoid these traps:

• turning memory into an infinite event scrapbook
• making reputation update instantly everywhere
• collapsing private feeling and public belief into one value
• making all rumors true
• making all rumors false
• forgetting that some stories never leave a household

#31.22Recommended First Implementation

The first version only needs to prove a few propagation chains:

• predator attack -> survivor memory -> route fear
• rescue -> household gratitude -> village reputation boost
• diplomatic mistake -> official distrust -> future summons tone shift
• missing worker -> household grief -> settlement concern

If those chains feel believable, the propagation layer is doing its job.

Regional or route-level risk can model:

• predator density
• territorial hostility
• monster presence
• patrol pressure later
• travel safety
• weather danger
• road quality

When an actor crosses a risky route:

• low-stakes outcomes may resolve abstractly
• meaningful threats may promote into richer simulation

This preserves both believability and performance.

Examples:

• roads reduce travel time and danger
• watchtowers improve route safety
• escorts protect valuable trips
• outposts keep regions warm and visible
• cleared predator dens make trade routes viable

This is one of the cleanest bridges between the cozy-builder and the systemic-world layers.

The architecture should answer four questions:

• what data exists persistently
• what systems advance that data over time
• when an actor is simulated in detail versus abstractly
• how offscreen outcomes stay believable without full-time micro simulation

#34.1Architectural Goal

The simulation should behave like a persistent causal world with selective fidelity.

That means:

• the world state keeps moving when the player looks away
• not every entity is updated at the same resolution
• actors can move between detailed and compressed forms without losing identity
• the system can explain how outcomes happened, even when they happened offscreen

The architecture should favor legibility over theoretical perfect realism.

#34.2Core Runtime Layers

The runtime should likely be divided into cooperating layers rather than one monolithic update loop.

#34.2.11. World Partition Layer

Responsible for:

• chunk streaming
• region grouping
• terrain, biome, and site ownership
• loading and unloading local detail
• visibility and proximity relevance

Chunks are for local spatial detail.

Regions are for broader simulation control, such as:

• route safety
• predator pressure
• depletion and recovery
• settlement influence
• travel corridor relevance

The architecture should not treat chunk boundaries as meaningful simulation boundaries for long-form tasks. A villager gathering from multiple nearby rock sites is performing one regional labor pattern, not several unrelated chunk actions.

#34.2.22. Actor Simulation Layer

Responsible for:

• person and creature identity
• current goals and plans
• state transitions
• local movement and interaction
• task execution
• interruptions and replanning

This is where villagers, wildlife, monsters, and later faction agents actually "do things."

#34.2.33. Regional Simulation Layer

Responsible for:

• low-fidelity offscreen persistence
• route and traffic modeling
• environmental pressure
• abstract resource flow
• encounter opportunity generation
• escalation triggers

This layer should be capable of saying:

• how risky a road is
• whether quarry traffic is active
• whether predator activity is increasing
• whether a missing worker is plausible and why

#34.2.44. Event and Narrative Layer

Responsible for:

• turning simulation changes into surfaced events
• maintaining notable event records
• deciding what becomes ambient story versus alert-worthy story
• supplying structured event templates with simulation inputs

This layer should not own truth. It should present and interpret truth produced by the sim.

#34.2.55. Persistence Layer

Responsible for:

• saving actor state
• saving settlement state
• saving region state
• preserving unresolved events
• restoring the world without contradictions

The persistence layer must preserve causal continuity, not just position snapshots.

#34.3Simulation Cadence Bands

The simulation should not use one universal tick rate.

Cadence should be tied directly to heat tier and activity type.

Useful cadence bands:

• frame or sub-frame updates for focused embodied actors
• short fixed steps for hot actors and hot-zone incidents
• checkpoint or milestone updates for warm actors
• coarse regional pulses for cool zones
• event-driven or time-skip pulses for cold background space

This matters because CPU cost grows less from actor count alone and more from how often each actor is reconsidered in full.

The ideal shape is:

• nearby combatants think often
• selected travelers update often enough to stay legible
• offscreen workers advance at decision milestones
• remote quiet regions mostly advance when thresholds or timers matter

The engine should think in terms of:

• how much granularity does this situation deserve

not:

• how many equal ticks can we afford to burn

#34.4Actor Lifecycle Across Heat Tiers

Each actor should move through a lifecycle of representation rather than a binary loaded/unloaded state.

Possible lifecycle:

1. focused embodied actor
2. hot embodied or near-embodied actor
3. warm compressed active actor
4. cool regional participant
5. re-materialized actor

#34.4.1Focused Embodied Actor

The actor exists with:

• exact coordinates
• path state
• local targets
• animation or action phase
• immediate sensory context
• collision or combat context

Use this when the player can see or meaningfully affect the actor directly.

#34.4.2Hot Embodied or Near-Embodied Actor

The actor still exists individually and can still be inspected as a person in motion, but does not need full frame-rate cognition all the time.

Useful properties:

• persistent exact or near-exact route position
• short-horizon next action
• high-priority interruption watch
• recent emotional and physical aftermath
• strong continuity with last focused state

This tier is important for:

• just-offscreen escorts
• monitored expeditions
• dangerous return trips
• aftermath scenes after direct control

#34.4.3Warm Compressed Active Actor

The actor still exists individually, but their behavior is advanced through:

• route segments
• task milestones
• next-decision checkpoints
• estimated arrival and completion windows

This is the correct representation for a worker still "really doing the job" without paying full simulation cost every frame.

#34.4.4Cool Regional Participant

The actor is represented primarily by:

• identity
• purpose
• affiliation
• route membership
• risk exposure
• expected next meaningful state

At this level, not every second matters. What matters is whether the actor:

• progresses
• gets delayed
• suffers interruption
• causes downstream consequences

#34.4.5Re-Materialized Actor

When an actor becomes important again, the sim should recreate a local representation from persistent state rather than inventing a fake teleport-style result.

The actor should come back with:

• a plausible location
• a consistent inventory
• a meaningful condition
• the correct consequences of what happened while offscreen

Re-materialization should preferentially restore from:

• last known route segment
• most recent valid local anchor
• current task milestone
• current companions or escorts
• current local danger or event context

The system should not spawn actors from nowhere just because attention returned.

#34.5Task Execution Model

Tasks should be represented as plans with milestones, not giant fragile command tapes.

A good task record should include:

• task type
• intent
• assigned actor or actors
• target site or person
• source and destination when relevant
• progress state
• next milestone
• interruption rules
• fallback or replanning rules

Example gathering chain:

• maintain stone supply
• use quarry cluster north of village
• walk to available node
• extract until full, exhausted, threatened, or interrupted
• return to valid stockpile
• repeat until order is replaced or constraints fail

This lets the system resume, compress, or re-evaluate the task at any fidelity tier.

#34.6Travel Model

Travel is one of the most important architectural systems because it connects:

• logistics
• exploration
• danger
• infrastructure
• disappearance and return

Travel should likely be modeled as route segments with contextual metadata rather than continuous offscreen pathfinding.

Useful segment properties:

• distance
• terrain cost
• road quality
• visibility
• threat exposure
• weather exposure
• escort status
• region transitions

At high fidelity, an actor walks the route.

At medium fidelity, the actor advances through segments with timing and interruption checks.

At low fidelity, the route contributes to regional traffic, danger, and timing outcomes.

#34.7Encounter and Interruption Model

Offscreen life only feels real if plans can be interrupted.

Interruptions should be produced by intersections between:

• actor intent
• route risk
• local region state
• nearby event candidates
• personal traits and conditions

Common interruption classes:

• attack or chase
• resource exhaustion
• injury or sickness
• weather delay
• social encounter
• discovery event
• task reprioritization from settlement need

Important rule:

The system should not roll random chaos every update just because it can. Interruption frequency should feel explainable and tied to world conditions.

#34.8Escalation Rules

Not every interruption deserves full simulation.

The architecture needs explicit escalation rules for when a low- or mid-fidelity event becomes a high-fidelity scene.

Likely escalation triggers:

• player camera approaches
• selected actor is involved
• severe danger occurs
• named or important actor is affected
• unusual event chain begins
• combat starts near a player-interest route
• a quest or diplomatic event activates

Escalation should instantiate richer detail from already-existing state, not overwrite that state.

#34.9Settlement-Level Simulation

The settlement itself should not just be a pile of buildings plus independent villagers. It needs a layer of aggregate simulation that produces pressure on individuals.

Settlement-level concerns include:

• stockpile demand and surplus
• job priority
• housing pressure
• household stress
• defense readiness
• route dependency
• diplomatic obligations

This layer should create demand signals that individual actors respond to.

Example:

• stone is low
• quarry work priority rises
• laborers with suitable role and availability re-evaluate
• a worker adopts or resumes quarry plan
• route danger may then reshape the specific execution

This is one of the most important architectural bridges in the project, because it connects:

• citybuilder-style planning
• RTS-style assignment
• villager autonomy
• logistics and infrastructure
• offscreen continuity

If this layer is weak, the settlement will either feel like:

• a spreadsheet that resolves magically
• or a click-heavy RTS where villagers have no real inner life

The target is something in between:

• the player sets intent, priorities, and structure
• the settlement generates real labor demand
• villagers pick up or are assigned work through understandable rules
• those rules produce observable, persistent behavior in the world

#35.1Core Model

The settlement should not directly issue tiny commands like:

• move here
• swing hammer
• walk back
• unload now

for every ordinary task.

Instead, the settlement should produce:

• needs
• jobs
• task chains
• role pressure
• priority signals

Villagers then bind themselves to those opportunities based on:

• role
• skill
• availability
• location
• condition
• dominant needs and active focus
• current orders
• personality and learned behavior

#35.2Four-Layer Labor Stack

A useful mental model is a four-layer labor stack:

1. settlement needs
2. jobs
3. actor plans
4. local actions

#35.2.11. Settlement Needs

These are high-level demands or shortages such as:

• food is low
• stone stockpile is below target
• a building site needs logs
• a household has no firewood
• a road needs repair
• a watch post is unmanned

Needs should come from real world state, not arbitrary timers.

Need sources include:

• stockpile thresholds
• building construction queues
• household deficits
• infrastructure decay
• seasonal preparation
• defense alerts
• diplomacy and trade obligations

#35.2.22. Jobs

Jobs are concrete units of labor created in response to needs.

Examples:

• harvest berries from patch east_04
• transport 18 stone to stockpile_02
• repair bridge segment south_crossing
• cook grain at kitchen_01
• escort merchant caravan route_north
• stand guard at tower_03 until relief

Jobs should be:

• specific enough to execute
• abstract enough to survive simulation tier changes

They are not animation scripts. They are actionable labor opportunities.

#35.2.33. Actor Plans

When a villager commits to a job, they generate or adopt a plan.

Examples:

• travel to berry patch, harvest until full, return to pantry
• collect stone from quarry node B, deliver to storage
• bring repair tools to bridge, perform repairs until interrupted or complete

The plan belongs to the actor, not the settlement.

This distinction matters because:

• the villager may get interrupted
• the villager may reprioritize due to hunger or danger
• the villager may reprioritize due to sleep pressure, loneliness, heat, grief, or irritability if the job is not urgent
• the villager may fail, flee, or die
• the settlement may still continue to need the job done

#35.2.44. Local Actions

These are immediate embodied behaviors:

• walking
• gathering
• dropping inventory
• swinging weapon
• entering shelter
• speaking to another actor

The lower layers should be able to change without invalidating the upper layers.

#35.3Jobs Versus Roles

Roles and jobs should not be the same thing.

Roles answer:

• what kind of work this person is generally expected or allowed to do

Jobs answer:

• what specific piece of work needs doing right now

Example:

• role: laborer
• available jobs: haul wood, mine stone, repair road, collect reeds

Example:

• role: hunter
• available jobs: hunt boar, scout predator den, escort forage group

This separation allows:

• flexible labor allocation
• role-based filtering
• personality and skill differences inside the same broad role

#35.4Job Lifecycle

A settlement job should likely move through a predictable lifecycle.

Suggested lifecycle:

1. created
2. visible to eligible actors
3. claimed or assigned
4. in progress
5. blocked or interrupted
6. resumed, abandoned, or replaced
7. completed

#35.4.1Created

The world state generates the job from a need.

#35.4.2Visible to Eligible Actors

The job enters the local or settlement labor market.

#35.4.3Claimed or Assigned

Either:

• a villager autonomously claims it
• the player explicitly assigns someone
• a supervisor later could assign it

#35.4.4In Progress

The actor is executing the plan generated from the job.

#35.4.5Blocked or Interrupted

Causes might include:

• target resource exhausted
• route danger
• no valid storage destination
• hunger or exhaustion
• weather
• attack

#35.4.6Resumed, Abandoned, or Replaced

The job may:

• stay attached to the same villager
• return to the settlement pool
• split into follow-up jobs
• escalate into a player-facing issue

#35.4.7Completed

The underlying need is reduced or fulfilled, and downstream systems update accordingly.

#35.5Push Versus Pull

The labor architecture should combine both push and pull, not rely purely on one.

#35.5.1Pull

Villagers look for jobs they can do.

Good for:

• organic autonomy
• believable daily routines
• reducing player micromanagement

#35.5.2Push

The player or settlement explicitly assigns work.

Good for:

• urgent priorities
• strategic intention
• scarce specialists
• defense and crisis response

The best model for this game is likely:

• pull by default
• push when the player cares

This fits both the cozy-builder and RTS layers.

#35.6Job Visibility and Eligibility

Not every villager should evaluate every job globally all the time.

Eligibility should be filtered first by:

• settlement affiliation
• role compatibility
• skill or equipment requirement
• current availability
• current control state
• distance or region relevance
• social restrictions later if needed

Then ranked by:

• priority
• proximity
• efficiency
• safety
• urgency
• villager preference or habit

This avoids expensive global reevaluation and keeps choices interpretable.

#35.7Priority Architecture

Job priority should likely be a composite score rather than one integer.

Useful priority dimensions:

• survival criticality
• settlement urgency
• spoilage sensitivity
• travel cost
• danger exposure
• player override weight
• social obligation
• downstream dependency

Example:

• food hauling before winter may outrank cosmetic road repair
• emergency medical carry may outrank routine gathering
• a player-pinned construction project may outrank ordinary hauling

This allows the player to influence outcomes without manually issuing every step.

#35.8Labor Markets by Scope

The settlement may need more than one job pool.

Useful scopes:

• household scope
• building scope
• settlement scope
• expedition scope
• regional infrastructure scope

Examples:

• household scope: fetch water for home, care for child, cook meal
• building scope: bring logs to sawpit, operate kiln
• settlement scope: haul stone, repair palisade
• expedition scope: escort caravan, carry camp supplies
• regional infrastructure scope: clear road obstacle, rebuild bridge

This keeps the labor model from flattening everything into one giant undifferentiated queue.

#35.9Reservation and Claiming

The system needs reservation logic so multiple villagers do not repeatedly choose the same work in silly ways.

Reservations should likely apply to:

• resource nodes
• transport loads
• build slots
• workstations
• destination capacity
• escort or party positions

A claim should probably include:

• actor id
• job id
• target ref
• claim time
• expiry or heartbeat

Claims should expire cleanly if:

• the villager dies
• the villager flees
• the plan becomes invalid
• the actor is manually reassigned

#35.10Transport and Hauling Architecture

Hauling should be treated as a first-class system, not an afterthought.

Many believable settlement problems come from transport friction, not resource absence.

The system should distinguish between:

• resource existence
• resource accessibility
• resource reservation
• resource movement
• destination acceptance

This allows important gameplay consequences such as:

• wood exists but is stranded far away
• grain was harvested but not delivered before spoilage
• stone output is high but construction stalls due to hauling shortage

#35.11Construction Jobs

Construction should likely decompose into phases rather than one all-purpose "build house" action.

Example phases:

• designate site
• clear site
• deliver materials
• perform build labor
• finish and claim building

This allows:

• visible progress
• partial completion
• interruptions
• different workers contributing different kinds of labor

#35.12Household and Personal Labor

Not all meaningful work should belong to the public settlement queue.

Private or semi-private labor matters too:

• eating
• resting
• child care
• mourning
• caring for sick family
• maintaining household stores

These tasks should compete with settlement labor in believable ways.

This is crucial for making villagers feel like people with lives instead of infinitely obedient civic drones.

#35.13Duty Conflicts

Villagers should sometimes face real conflict between:

• settlement duty
• household duty
• self-preservation
• player assignment
• direct control aftermath

A good architecture should allow those conflicts to surface through rule weighting rather than bespoke scripting every time.

Examples:

• an exhausted parent delays quarry work to return home
• a hungry laborer stops hauling and eats first
• a frightened trader refuses the unsafe shortcut unless directly pushed

This is where personality and condition begin to matter economically, not just narratively.

#35.14Crisis Jobs

Certain jobs should exist in a special crisis class.

Examples:

• extinguish fire
• drag wounded villager to safety
• defend gate
• flee settlement center
• retrieve child from danger

Crisis jobs should:

• override many ordinary priorities
• spread quickly through local relevance
• support player intervention naturally
• generate strong memories and social consequences

#35.15Player Overrides

The player needs levers stronger than passive priority shaping, but weaker than micromanaging every chore.

Useful override tools:

• assign specific villager to job
• pin a job or project
• forbid certain jobs to certain people
• set regional work bans
• set risk tolerance
• create expedition party
• suspend nonessential labor in crisis

These should modify the labor architecture, not bypass it completely.

For example:

• the player assigns Joren to quarry work
• Joren still chooses exact pathing and may still react to danger
• the settlement now treats that assignment as strongly reserved

#35.16Job Persistence Across Simulation Tiers

Jobs must survive actor promotion and demotion.

That means:

• a claimed quarry job stays meaningful offscreen
• a hauling job can remain in progress while compressed
• a blocked job can return to the pool without losing cause
• a dangerous route can change job desirability over time

The job system should preserve:

• what needs doing
• who was doing it
• why it stalled or succeeded
• what changed in settlement state as a result

#35.17Failure Modes the Architecture Should Support

The labor model should naturally allow believable failure, not only success.

Examples:

• no one can do the job
• someone can do it but never reaches it safely
• someone starts it but collapses from exhaustion
• the resource disappears first
• the destination fills up
• a family emergency pulls the worker away

These are not bugs in concept. They are part of what makes the world feel alive.

#35.18UI and Explainability Requirements

The player must be able to understand labor flow without reading hidden simulation internals.

Useful explainability outputs:

• why a job exists
• who has claimed it
• why it is blocked
• what the villager is currently doing
• what resource or route is constraining progress

Examples:

• Bridge repair blocked: no planks available.
• Quarry hauling delayed: north road unsafe.
• Oven idle: no grain delivered.
• Joren returned home: exhaustion critical.

If the player cannot understand why labor is failing, the system will feel random.

#35.19Recommended First Implementation

The first version of the task/job architecture only needs to prove:

• one stockpile-driven gather and return loop
• one hauling chain
• one construction chain
• one household interruption case
• one danger interruption case
• one player-assigned override case

That is enough to validate whether the settlement actually feels alive and manageable.

#35.20Social Simulation Boundaries

Social life should be systemic, but it should not be simulated at maximum depth for every person every tick.

A sensible boundary is:

• relationships update when people meaningfully interact
• households update on daily or event milestones
• reputation updates on notable public actions
• memory updates when thresholds of experience are crossed

This avoids constant expensive reevaluation while still allowing believable long-form life changes.

#35.21Event Ledger

The simulation likely needs an internal event ledger or world history log, even if the player never sees most of it.

The ledger should capture:

• important transitions
• unresolved incidents
• cause-and-effect breadcrumbs
• who was involved
• when and where it happened

Examples:

• Coren failed to return from north road route
• Mira was injured by wolf attack
• Tomas and Elira formed a bond after mutual aid
• court reputation with Joss decreased after diplomatic insult

This ledger supports:

• narrative surfacing
• debugging
• save/load integrity
• biography generation
• player-facing "what happened here" inspection

#35.22Save/Load and Time Continuity

The architecture should be designed assuming long-running worlds and repeated saves.

That implies:

• actor plans must serialize cleanly
• unresolved tasks and incidents must survive reload
• regional pressures must survive reload
• the world should not reset invisible systems on load

If the game later supports accelerated time, pause, or background advancement during load boundaries, the same architecture should still hold.

#35.23Architectural Anti-Goals

Avoid these traps:

• simulating every offscreen footstep forever
• storing giant brittle event queues per actor
• making regional simulation so abstract that people lose identity
• making personal simulation so expensive that population size must stay trivial
• mixing narrative presentation logic directly into core simulation state
• making direct control a totally separate ruleset from autonomous behavior

#35.24Early Implementation Target

For a first pass, the architecture only needs to prove a small, coherent loop:

• one settlement
• a few nearby work sites
• one or two risk-bearing travel routes
• a modest population
• a small wildlife and monster ecology
• actor promotion and demotion across tiers
• event logging of meaningful outcomes

If this small architecture cannot produce believable labor, travel, danger, and return behavior, the larger world design should be reconsidered before scaling up.

The economy in this project should not behave like an abstract score engine. It should behave like lived material reality.

That means:

• resources exist somewhere specific
• someone has to get them
• someone has to move them
• someone has to use them
• interruptions and losses should matter

If this layer is weak, the rest of the game loses credibility fast. Quests, households, building, and danger all depend on whether the world's material logic feels real.

#36.1Architectural Goal

The resource economy should:

• support RTS-style gathering clarity
• support citybuilder-style logistics chains
• support offscreen persistence without magical resolution
• produce meaningful pressure on routes, labor, and infrastructure
• remain explainable to the player

The economy should create stories through friction, not through arbitrary scarcity alone.

Examples of interesting friction:

• food exists but is too far away
• stone is mined but hauling is unsafe
• a household is cold because firewood was diverted elsewhere
• a building is half-finished because planks never arrived
• a trade promise fails because escorts were unavailable

#36.2Core Economic Principle

The game should distinguish between:

• existence
• access
• transport
• conversion
• consumption

Those are not the same thing.

For example:

• deer exist in the world
• that does not mean meat exists in storage
• logs exist in a forest
• that does not mean the watchtower can be built
• grain exists in a field
• that does not mean bread exists in a house

This distinction is one of the best ways to make the world feel grounded.

#36.3Core Material Layers

The economy should probably be understood as several linked layers.

#36.3.11. Raw World Resources

These are naturally occurring or spatially embedded materials.

Examples:

• trees
• berry patches
• stone nodes
• clay deposits
• reeds
• wild game
• monster reagents later

These resources should have location, yield profile, depletion behavior, and often route implications.

#36.3.22. Carried Resources

These are resources currently in motion through the world.

Examples:

• a laborer hauling stone
• a cart later carrying grain
• hunters returning with meat and hides

Carried resources are crucial because they are where risk, interruption, theft, injury, and player rescue become meaningful.

#36.3.33. Stored Resources

These are resources resting in recognized containers or places.

Examples:

• central stockpiles
• household stores
• building input buffers
• expedition packs
• regional caches later

Stored resources should have location, ownership or access rules, and capacity constraints.

#36.3.44. Processed Goods

These are transformed outputs created by labor and tools.

Examples:

• logs into planks
• grain into food
• hides into leather later
• ore into metal much later if the game reaches that depth

Processing should be a chain with labor, delay, and input dependency, not an instant number conversion.

#36.3.55. Consumed or Committed Resources

These are materials that have already been spoken for.

Examples:

• planks reserved for a house
• food allocated to a feast or expedition
• medicine committed to the injured
• stone promised to a repair task

The economy must track commitment, not just stockpile totals, or the settlement will feel like it is lying.

#36.4Resource Categories

The first implementation does not need many resource types, but the categories should be meaningful.

Useful early categories:

• food
• wood
• stone
• basic fuel or firewood
• simple building supplies
• hides or hunting byproducts
• one or two special reagents for event flavor

These are enough to create:

• gathering loops
• hauling pressure
• housing and warmth pressure
• hunting expeditions
• simple trade
• local route importance

The early economy should favor expressive categories over quantity bloat.

#36.5Economic Chain Model

Most materials should move through a chain like:

1. locate source
2. harvest or acquire
3. carry to destination
4. store or reserve
5. transform if needed
6. deliver to final use
7. consume, equip, build with, or trade

This model creates natural interruption points and natural player intervention points.

Examples:

• tree -> logs -> hauled -> stored -> delivered to build site -> consumed by construction
• boar -> carcass or meat/hide -> hauled home -> stored -> eaten or processed
• stone node -> mined stone -> hauled -> stockpile -> construction or repair

The architecture should preserve where along this chain something currently is.

#36.6Stockpile Model

Stockpiles should not just be global magic inventory pools.

The economy should likely support several storage scopes:

• household storage
• building-local input storage
• shared settlement stockpiles
• carried inventories
• expedition storage

This matters because:

• proximity affects labor efficiency
• household stress becomes material rather than abstract
• hauling remains strategically meaningful
• settlement layout matters

The player can still be given summarized totals for convenience, but the simulation should remember where things actually are.

#36.7Reservation and Allocation

Resources should support reservation and allocation states.

Important distinctions:

• available
• claimed
• in transit
• buffered
• committed
• consumed

Example:

• 40 wood exists in stockpile
• 18 wood is already reserved for a house
• 10 wood is being carried to a kiln
• only 12 wood is truly available for a new project

Without this distinction, players will constantly feel that the simulation is cheating or inconsistent.

#36.8Throughput Over Totals

The economy should care about flow rates, not just pile size.

The player should be able to feel the difference between:

• a settlement with large stockpiles but awful delivery speed
• a settlement with modest stockpiles but smooth throughput

This makes:

• roads
• nearby storage
• job priority
• hauling capacity
• staging areas

actually matter.

A believable economy is often bottlenecked by movement, not abundance.

#36.9Distance and Friction

Distance should be one of the most important economic variables in the game.

Distance creates:

• time cost
• labor opportunity cost
• route danger exposure
• household absence
• spoilage or delay pressure later if used

The player should feel that settling near a resource, building a road, or placing a forward cache changes the economy in concrete ways.

That is a major part of what makes the world cohesive.

#36.10Food Economy

Food should probably be the first fully convincing economic loop because it naturally connects:

• gathering
• hunting
• storage
• households
• shortages
• expeditions
• winter pressure later if included

The food system should ideally distinguish between:

• food in the wild
• food on the body of a hunter or gatherer
• food in storage
• food in household use

That allows memorable situations such as:

• hunters succeed but one dies on the road home
• the settlement is "rich" in nearby berries but still hungry because labor is diverted
• food exists, but a grieving household fails to manage its stores well

#36.11Building and Construction Economy

Construction should be a visible material sink.

Buildings should not simply complete because a build timer ended. They should depend on:

• materials gathered
• materials hauled
• labor delivered
• sometimes tool or specialist access later

Construction should therefore expose:

• what is missing
• what is reserved
• what is already on site
• what labor remains

This creates satisfying strategy around:

• staging materials
• securing routes
• prioritizing structures
• expanding in manageable steps

#36.12Household Economy

Households should have lightweight but meaningful private economies.

They may need:

• food
• warmth or fuel
• rest and shelter access
• child or dependent care support

The game does not need to simulate every spoonful, but households should be able to experience:

• scarcity
• comfort
• imbalance
• grief-driven disruption
• resilience

This is important because a "cozy" settlement without household material life will feel emotionally fake.

#36.13Hunting, Reagents, and Special Materials

The game's expedition side becomes stronger if not all resources are passive gatherables.

Some resources should require:

• hunting
• dangerous travel
• timing
• direct player attention
• unusual actors or tools

Examples:

• boar meat and hides
• bird reagents
• monster parts
• rare herbs in risky terrain

These materials are useful because they bridge:

• economy
• exploration
• danger
• story

They turn the world into more than a labor spreadsheet.

#36.14Trade and External Exchange

Trade should eventually sit on top of the same material logic, not bypass it.

That means traded goods should:

• exist materially
• be moved along routes
• be exposed to delay and danger
• affect trust and reputation when promised or lost

Early trade can be very simple:

• send goods
• receive goods
• succeed or fail based on route and fulfillment

Even a simple version can already support:

• diplomatic tone
• merchant relationships
• escort missions
• seasonal pressure

#36.15Economic Pressure Sources

The economy should create pressure from multiple directions at once.

Useful pressure sources:

• seasonal preparation
• hunger
• construction demand
• household needs
• infrastructure maintenance
• expedition provisioning
• trade obligation
• danger-induced route inefficiency

This helps the settlement feel alive because priorities genuinely compete.

#36.16Bottleneck Architecture

Interesting economy games are often really bottleneck games.

Common bottleneck types:

• extraction bottleneck
• hauling bottleneck
• storage bottleneck
• route safety bottleneck
• labor bottleneck
• processing bottleneck
• commitment bottleneck

The player should be able to diagnose which one is occurring.

Examples:

• quarry output high, but no one can haul it
• food harvested, but no household receives it
• planks exist, but all are reserved elsewhere
• trade goods ready, but north road too dangerous

This supports both strategy and story clarity.

#36.17Economy and Offscreen Parity

The economy must remain believable offscreen without simulating every sack by hand.

Good compression targets:

• aggregate repeated hauling on stable routes
• compress harvest cycles into milestone updates
• update storage deltas at believable intervals
• represent remote trade or supply movement as route-state plus cargo-state

Bad compression targets:

• deleting carried resources because they are inconvenient
• skipping reservation logic offscreen
• instantly merging all storage into one number
• resolving dangerous supply trips with no chance of disruption

The rule should be:

• compress motion
• preserve ownership, commitment, and consequence

#36.18Explainability Requirements

The player should be able to inspect not just resource totals, but resource truth.

Useful outputs:

• where this resource is coming from
• what is consuming it
• what is reserved already
• why a building is waiting
• why a household is short
• which route is slowing delivery

Examples:

• Watchtower stalled: 12 planks reserved, 4 delivered, north road delaying remaining shipment.
• Household cold: no firewood delivered after labor shifted to quarry haul.
• Granary low: west berry work interrupted by predator activity.

If the player cannot understand economic failure, the whole simulation will feel arbitrary.

#36.19CPU Strategy for the Economy

The economy can become a hidden CPU monster if every actor constantly reevaluates every resource relationship.

To stay sane:

• use scoped job markets instead of global scans
• treat stable supply routes as compressible patterns
• update aggregate shortages on coarser cadence than embodied actions
• recompute throughput summaries periodically, not every frame
• let buildings and households emit need signals instead of polling everything constantly

The economy should feel rich because of causal structure, not because of brute-force simulation.

#36.20Anti-Goals

Avoid these traps:

• magical global inventory with no spatial truth
• too many resource types before the core loops are fun
• construction that ignores hauling and reservation
• trade that teleports goods and still claims danger matters
• household needs so deep they bury the strategy game
• economy tuned purely around scarcity instead of friction

#36.21Recommended First Implementation

The first resource/economy pass only needs to prove:

• one food gather and return loop
• one hunting return loop
• one stone or wood hauling chain
• one construction site with reserved inputs
• one household shortage consequence
• one route danger bottleneck
• one small trade or provisioning example if feasible

If those pieces feel coherent, the economy will already support most of the game's larger promises.

• chunk-based streaming for world breadth
• region-level simulation for low-fidelity persistence
• actor state machines or HTN-like planning for interpretable behavior
• event promotion and demotion across fidelity tiers
• stateful per-person identity data
• route, risk, and logistics modeling that spans multiple chunks

Important technical principle:

Do not design the architecture around "simulate every entity equally forever."

Design around:

• selective fidelity
• compressible actor state
• recoverable causality
• importance-driven simulation budgets

• what the game actually has to prove to be fun
• what order the systems should likely be built in
• where the design is strongest
• where it is currently fragile
• how to push for maximum perceived world parity without unsustainable CPU cost
• what rules preserve a cohesive player experience

The central discipline of the whole project should be:

• simulate what creates meaning
• compress what creates cost
• surface what creates attachment

If the project follows that rule consistently, it can feel much larger and richer than its actual runtime expense.

#38.1What the Game Must Actually Deliver

The full design document contains many exciting systems, but the project will stand or fall on a smaller set of promises.

The game must make these things feel true:

• villagers are people, not faceless workers
• the settlement works even when the player is not hand-holding it
• direct control is exciting because it changes real lives and real outcomes
• offscreen life stays causally believable
• infrastructure, travel, and risk matter
• events feel like part of the same world as hauling, hunger, and building

If those six promises land, the game can survive with modest content breadth for a long time.

If those promises fail, no amount of open-world scale or event quantity will save it.

#38.2Recommended Build Order

The project should not be built feature-first. It should be built around dependency truth.

Recommended order:

1. embodied movement, selection, and local action loop
2. basic labor and stockpile loop
3. villager identity state with traits, condition, and simple memory
4. job persistence across offscreen compression
5. route, danger, and interruption logic
6. event surfacing and aftermath write-back
7. direct-control expeditions and small party play
8. relationship, rumor, and reputation propagation
9. broader world streaming and longer-distance content

In practical terms, the first real question is not "can the game stream an infinite world?"

It is:

• can one villager take one believable job
• get interrupted
• remain understandable
• and come back changed in a way the player cares about

If that loop works, the rest can scale outward.

#38.3Suggested Prototype Ladder

A useful implementation ladder would be:

#38.3.1Prototype 1: Honest Worker Loop

Prove:

• villager claims job
• villager walks to site
• villager gathers
• villager returns
• stockpile changes
• interruption can occur
• player can inspect why

If this does not feel good, stop and fix it before adding narrative ambition.

#38.3.2Prototype 2: Offscreen Continuity

Prove:

• actor compresses cleanly offscreen
• task still progresses
• route danger can alter outcome
• actor rematerializes plausibly
• no obvious teleport or fake-resolution feeling appears

This is the foundation of the "living world" claim.

#38.3.3Prototype 3: Direct-Control Story Episode

Prove:

• player selects two or three villagers
• leads a hunt, escort, or rescue
• traits and condition matter during the episode
• aftermath changes memory, injuries, stockpiles, and relationships
• villagers return to autonomous life without feeling disconnected

This validates the core fantasy line between ambient story and playable story.

#38.3.4Prototype 4: Social and Institutional Consequence

Prove:

• event affects relationship or reputation
• information spreads imperfectly
• later event outcome reads prior history

This is where the world begins to feel authored by memory rather than isolated incidents.

#38.4Strongest Parts of the Concept

The current design is strongest where multiple layers reinforce each other instead of competing.

Current strengths:

• direct control is justified by consequence, not just action flavor
• autonomy has mechanical purpose instead of being decorative AI
• infrastructure matters because travel and risk matter
• events are grounded in simulation state instead of floating above it
• traits and memory are intended to change actual outcomes, not just dialogue
• offscreen continuity is treated as a first-class design problem

This gives the project a genuine identity. It is not just "RTS plus RPG." It is a world where governance, travel, personhood, and intervention feed each other.

#38.5Weak Spots and Failure Modes

The design also has several dangerous weak spots that need active containment.

#38.5.11. The Everything-Matters Trap

If every villager can participate in every life system at equal depth all the time, the project becomes unreadable and too expensive.

The solution is not to abandon personhood.

The solution is:

• universal systemic eligibility
• selective intensity
• strong surfacing filters

Everyone can matter. Not everyone can be equally hot at all times.

#38.5.22. The Spreadsheet Trap

If the player mostly watches jobs, shortages, route statuses, and alerts without enough embodied intervention, the game stops feeling like a world and starts feeling like a management dashboard.

The cure is to make sure that:

• direct control episodes happen often enough
• they are worth doing
• they permanently matter afterward

#38.5.33. The Puppet Trap

If direct control overrides too much, villagers stop feeling like people.

If it overrides too little, direct control feels ornamental.

The current doc points the right way already:

• strong control over immediate action
• identity persistence in performance and consequence

That principle should not be softened later for convenience.

#38.5.44. The Noise Trap

A living world can easily become a world that never shuts up.

If every romance seed, injury, rumor, route hazard, and shortage is surfaced similarly, the player will stop reading the world.

The game needs:

• ambient events
• surfaced events
• urgent events

with clear filtering logic and strong prioritization.

#38.5.55. The Infinite-World Trap

Infinite worlds are seductive and often poison early development.

The risk is not only technical. It is design dilution.

An endless world can hide the fact that:

• the local loop is weak
• personhood is shallow
• jobs are opaque
• events are repetitive

The world should expand only after the nearby world is compelling.

#38.6Cohesion Rules

To stay cohesive, the game should protect a few non-negotiable design rules.

#38.6.1One World, Not Layered Minigames

The builder loop, RTS loop, and RPG/event loop should all read and write the same core state.

That means:

• hunting affects food and memory
• diplomacy affects reputation and trade
• injury affects labor reliability
• road building affects event probability and logistics

If any major activity becomes detached from the settlement sim, the project will start to feel like stitched modes instead of one world.

#38.6.2People Before Content Volume

It is better to have:

• fewer villagers
• fewer event templates
• fewer map regions

if the people inside them feel legible and changed by life.

This project is not a content-count fantasy first. It is an attachment fantasy first.

#38.6.3Consequence Before Spectacle

Big events matter only if their aftermath matters.

A boar hunt is compelling because:

• someone may be injured
• food returns home
• confidence rises
• fear spreads
• relationships change

not because a boar has cool attack animation alone.

#38.6.4Explainability Over Black-Box Cleverness

Any system that cannot be explained in plain language to the player is a likely trust problem.

Prefer:

• visible causes
• inspectable statuses
• named blockers
• understandable priority rules

over hidden "smart" behavior.

#38.7Maximum Parity Without Frying the CPU

The project should chase perceived parity, not literal parity.

The player does not need every square meter of world and every villager to run at identical fidelity.

The player needs confidence that:

• things continue
• outcomes follow causes
• important people stay coherent
• returning to a place makes sense

That means maximum parity should be pursued through architectural illusion backed by real state.

#38.7.1Spend CPU on the Following

• currently visible embodied actors
• selected or recently selected actors
• active combat and hunts
• settlement core logistics
• route intersections near player interest
• actors involved in dangerous or story-hot chains

These are the places where fake behavior is easiest for the player to notice.

#38.7.2Save CPU on the Following

• idle remote wilderness
• repeated offscreen footstep simulation
• full social reevaluation every tick
• exact remote creature pathing
• universal job scoring against all jobs by all villagers
• perfect replayability of offscreen time

These are expensive and give poor return if simulated literally.

#38.7.3Techniques That Preserve Believability Cheaply

• route-segment travel instead of constant offscreen pathing
• milestone-based task progress instead of giant action tapes
• regional opportunity fields instead of fully embodied remote encounters
• actor heat scoring instead of simple distance-only fidelity rules
• event aftermath records instead of full historical replay
• household and social updates at milestones rather than continuous polling

The right question for every expensive system is:

• what player-facing lie becomes visible if this is compressed?

If the answer is "not much," compress it.

If the answer is "the player will feel cheated," keep it hot.

#38.8Observability Requirements

For this design to survive contact with players and developers, the simulation needs to be easy to inspect.

Developer-facing observability should eventually include:

• actor current heat tier
• why the actor or region is at that heat tier
• pending promotion or demotion reason
• current plan and next milestone
• claim and reservation state
• route risk summary
• last interruption cause
• event ledger entry chain
• memory and reputation deltas after major incidents

Player-facing observability should include:

• what a villager is doing
• why they are doing it
• why they stopped
• whether they are focused, hot, warm, or backgrounded when relevant
• what changed because of a recent event
• what risks a route or action implies

Without this, both debugging and player trust will collapse.

#38.9Content Strategy Notes

This game does not need a huge number of event templates at first.

It needs a small number of event families with strong systemic reuse.

Good early families:

• hunt
• escort
• injury or sickness
• missing person
• trade visit
• diplomatic summons
• discovery on route
• household stress event

Each family should be able to read:

• who is involved
• what they are like
• where they are
• what the settlement needs
• what the region is like

That will produce more variety than dozens of shallow custom scenes.

#38.10Warning Signs During Development

The project is drifting in a bad direction if:

• the settlement only works under heavy player micromanagement
• villagers feel interchangeable in outcome terms
• offscreen resolution feels like teleporting or hand-waving
• direct control becomes optimal for routine chores
• event volume increases but story recall does not
• the world grows larger while local life grows less legible
• the player cannot explain why labor or social outcomes occurred

These should be treated as design alarms, not polishing issues.

#38.11Practical Definition of Success

The design is succeeding if a player can naturally tell a story like:

"I sent three villagers to hunt because food was low. One of them was already nervous after a wolf scare, and he broke first when the boar charged. The other two brought the meat back, but one was injured. That injury slowed our quarry output, which delayed the watchtower, which made the north road feel unsafe for a week. Later, when I needed someone to escort a trade run, I chose the one who held his nerve."

That anecdote contains:

• resource pressure
• personality
• direct control
• injury
• logistics consequence
• infrastructure consequence
• future decision impact

That is the game's promise in one chain.

If the game reliably produces stories like that, the concept is working.

• unique identity
• settlement and household membership
• stats
• traits
• learned tendencies
• memories
• bonds
• role
• inventory
• current task or mission
• current location abstraction
• active conditions
• notable biography flags

Likely persistent data categories per region:

• chunk membership
• travel routes
• threat fields
• resource sites
• weather or biome state
• settlement influence
• traffic intensity
• recent incidents

Likely persistent data categories per settlement:

• population
• building state
• stockpiles
• infrastructure
• household graph
• diplomatic status
• current requests, missions, and shortages

The first implementation target should likely avoid:

• rival AI civilizations
• full dynasty simulation depth
• endless authored quest chains
• ultra-deep genetics
• world-scale perfect persistence of every micro action

The first implementation should prove:

• direct RTS-style control
• autonomous worker behavior
• a small settlement loop
• a living-person model with traits and memories
• meaningful offscreen continuity
• one or two player-led expedition or event types

• one settlement
• a bounded but streamed map
• resource gathering and stockpiling
• housing and a few building upgrades
• wildlife hunting and simple monster danger
• several named villagers with traits and memories
• direct control for hunting, escort, and scouting
• one diplomatic or narrative event template
• offscreen risk and return behavior

If this slice is not compelling, the larger infinite-world promise should not be attempted yet.

#42.1Scope Explosion

• RTS
• citybuilder
• colony sim
• open-world RPG
• emergent social sim
• narrative event system

This is the primary project risk.

#42.2Simulation Opacity

If villagers behave richly but opaquely, the player may stop trusting the game. Interpretable decision logic and good surfacing are mandatory.

#42.3Micromanagement Trap

If direct control is too strong, the player must control everything. If it is too weak, the RPG/intervention fantasy collapses.

#42.4Story Noise

If every background event is surfaced equally, no event feels important.

#42.5Open-World Complexity

Seamless infinite world requirements massively increase:

• persistence burden
• streaming burden
• debugging burden
• pathfinding complexity
• save and load complexity

This should be earned by a smaller successful sim, not assumed from the start.

• people should feel like people, not worker counters
• the world should remain alive offscreen
• offscreen life should preserve causality rather than fake instant resolution
• direct control should create memorable turning points
• autonomy should remain useful and trustworthy
• infrastructure and travel should matter
• systems should be interpretable by the player
• selective fidelity is necessary, not a compromise failure

• What exactly changes when a unit is directly controlled?
• Is direct control a total override or a strong suggestion?
• How large should settlements become before personhood becomes unreadable?
• What is the failure state before rival factions exist?
• How punishing should death, injury, and household collapse be in a game with cozy aspirations?
• How should quests blend authored story with systemic state?
• What information should the player always know about offscreen people they care about?
• When should a background actor be promoted into a story-hot actor?

• settlement growth feels strategic
• people feel individually shaped by life
• the world stays active when the player looks away
• direct control lets the player personally author decisive moments
• stories arise from systems, not only scripts

The clearest current identity for the project is:

A cozy frontier settlement sim with RTS control, RPG intervention, and emergent local drama.