Open-World RTS/RPG Settlement Sim

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

This document is the design authority for what Worldforge is meant to become. It is not the implementation sequence. The Development track owns implementation order, phase gates, proof, and the extension contracts that connect the first vertical slice to the complete design.

• 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

Villagers build and grow settlements through autonomous labor, resource use, household decisions, and civic projects. The player observes those lives, shapes priorities and policy, and may assign specific work when they want stronger direction. At any moment, the player can explicitly take control of individuals or small groups and 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:

• inspects settlement needs, throughput, projects, and failure pressure
• shapes labor priorities and may assign specific work
• permits, sponsors, reserves land for, or places buildings when their authority allows it
• 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:

• selects people to observe without changing their behavior
• explicitly takes or releases direct control
• 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 explicitly taking control of 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

#9.1Selection Contract

The first playable control set should support:

• click to replace the current selection with one selectable actor
• drag to replace the current selection with actors inside a marquee
• Shift-click to add one actor or remove it when already selected
• Shift-drag to add every actor inside a marquee once without discarding the rest of the selection
• click on empty ground to clear selection unless an order-targeting mode is active
• Escape to cancel an order-targeting mode before it clears the selection
• a visible selected state in the world and a compact list of selected actors in the player UI
• double-click and control groups only after the basic selection and order path is stable

Selection is presentation and UI focus state. It does not own actor behavior, persist a second copy of actor identity, or mutate simulation components directly.

Selection must remain causally inert to the Actor. Clicking, inspecting, following with the camera, or leaving a statistics panel open cannot supersede a plan, alter need or danger pressure, change IAUS or HTN decisions, or make the Actor react to being observed. Selection may keep detached presentation data or a visible proxy available, but simulation heat and decision truth remain under their existing owners.

Direct control requires a separate explicit Take Control button, hotkey, or command-mode action. Release Control is also explicit. A normal selection may receive assignments while remaining autonomous, and the player may inspect one Actor while directly controlling another Actor or Party.

#9.2Order Input Contract

The baseline interaction uses contextual orders:

• in the Phase 4 vertical slice, right-click on an authored Site or ground within its bounded target radius issues a Site move order; other ground is rejected and does not imply exact local pathfinding
• after Phase 7 adds local embodied navigation, right-click on exact traversable ground may issue a local world-position move order through the same durable movement-order path
• right-click on a hostile target issues an attack order
• by the Phase 6 vertical-slice exit, right-click on the authored finite food source or its available Job requests assignment of one selected Actor to that existing food chain
• by the Phase 6 vertical-slice exit, right-click on the authored construction site or its available Job requests assignment of one selected Actor to that existing construction chain; an eligible controlled Party may request the existing bounded construction-assist operation
• an explicit command button may enter a targeting mode when context alone would be ambiguous
• invalid targets do not create partial orders and must produce visible rejection feedback

The first slice does not need a second gather, haul, or build mutation path. The target adapter resolves stable Actor, Job, initial WorkTask, Site, Construction, and retained revision facts, then calls the existing player-assignment or Party-assist operation. Hauling and building remain task steps inside the assigned Work lifecycle. Exact assignment cancellation uses the retained AssignmentOrder ID and its current revision.

A normal order replaces incompatible immediate player intent. Holding Shift appends an order to the actor's player-order queue. Emergency orders such as retreat may interrupt the current action, but the command definition must say that explicitly. Order application uses a stable recipient order and stable target IDs so replay does not depend on selection order, pointer values, or container iteration.

Move, gather, build, attack, and priority orders use assignment authority unless the player has explicitly taken direct control. Assignment may strongly redirect immediate intent, but it does not silently change the Actor's control-state band.

#9.3Order Ownership and Data Flow

The required ownership path is:

1. Controls translate physical input into backend-neutral selection or order requests.
2. App composition resolves screen-space targeting and submits one gameplay command.
3. Game command handling validates authority, recipients, target type, reachability prerequisites,

and queue policy against simulation truth.

1. The owning gameplay system converts an accepted command into actor intent, a route request, a

job claim, a combat target, or another domain-specific state change.

1. Simulation systems execute that state through their normal fixed-tick passes.
2. Events and presentation report acceptance, rejection, progress, interruption, and completion

after the authoritative mutation occurs.

The durable order record should contain an order kind, stable order ID, stable actor IDs, a typed target, queue or interruption policy, issuing simulation tick, and any domain parameters required to validate replay. It must not contain raw ownership pointers or renderer objects. Rendering reads selection and order results; it does not repair routes, job claims, combat state, or actor intent.

#9.4Autonomy and Player Authority

Player orders temporarily override the actor's immediate autonomous intent; they do not erase needs, traits, injuries, jobs, relationships, or memory. When an order completes, is cancelled, or becomes invalid, the actor returns to normal planning with the resulting position and condition. The UI must distinguish at least these states:

• accepted and pending
• executing
• blocked or waiting
• interrupted
• completed
• rejected or invalidated

The player must be able to tell which order is active, where it is targeted, whether additional orders are queued, and why an actor cannot comply. Feedback may be visually compact, but it cannot rely only on logs or developer tools.

#9.5Implementation Ownership

Implementation ownership is divided as follows:

• Phase 1 owns stable route and destination requests, target positions, reachability results, and movement continuity across world heat transitions. It does not open the full player order UI.
• Phase 2 owns the player-order source marker, actor-intent override rules, cancellation, queue policy, and the transition back to autonomous planning. It proves the data contract with a narrow command-driven scenario before general RTS interaction opens.
• Phase 3 owns gather, haul, build, and assignment orders because those commands mutate jobs, reservations, stockpiles, and construction state.
• Phase 4 owns the bounded player interaction path for selection, contextual Site movement and Actor attack, retreat, bounded Party orders, incident response, assist behavior, and command feedback. It also provides the durable selected-Actor assignment issue and cancellation operations. These are the reusable foundations for later escort and work-targeting play; they do not constitute a multi-step escort, rescue, or broad construction lifecycle.
• Phase 6 promotes the existing diagnostics Party formation, control, release, and response actions into a discoverable player-facing surface. It also owns the minimum graphical adapters for assigning one selected Actor to the existing food or construction Job, cancelling the exact assignment, requesting existing Party construction assist, and displaying accepted, queued, deferred, executing, blocked, interrupted, completed, cancelled, or rejected results with their owner-supplied reason.
• Phase 7 first adds World-owned local embodied navigation: exact world-position targets, nav-cell traversability, deterministic local paths, dynamic-obstruction invalidation, and explicit arrival tolerance. Inter-Site travel remains on the Phase 1 route graph, and movement orders remain under the Phase 4 command contract.
• Phase 14 exposes selection, assignment, take-control, release, order feedback, and owner-built

snapshots through the scriptable standard interface without changing their gameplay owners.

• Phase 15 corrects the bounded proof interaction so observation selection, assignment authority,

and direct control are distinct in the normal player experience. It adds explicit take-control and release actions before connected movement broadens the playable space.

• Phases 7-12 add broader target kinds only when their domain state exists: Phase 7 adds building placement, upgrade, repair, and infrastructure commands; Phase 8 adds ecology and discovery targets; Phase 9 adds processing, crafting, provisioning, trade, and broader transfer commands; Phase 11 adds quest, escort, rescue, and institutional responses; Phase 12 adds tactical, formation, defense, and warfare commands.
• Phase 11 owns multi-step escort and rescue requests, including acceptance, deadlines, travel interruption, completion, abandonment, autonomous continuation, and quest or institutional consequences. It composes the existing Party, movement, incident, and consequence owners rather than creating escort-only versions of their state.

Large-scale army control, advanced formation warfare, broad remapping UI, and networked command replication are not part of the first vertical slice. They remain tracked in the development indices until a later scope explicitly promotes them.

The completed Phase 4 proof may enter control as part of selected-Actor command handling. That was acceptable for proving the shared control owner, but it is not the final player contract. Phase 15 must remove that coupling before later settlement play builds on it.

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

AI-controlled rival factions are intentionally out of scope for the first vertical slice. Phase 12 owns the first bounded rival faction after diplomacy, institutions, combat, and world-scale pressure have stable owners.

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.

#11.1Architectural Goal

The world partition system should:

• let the player move through a broad continuous 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.

#11.2Core Spatial Layers

The world is represented through several nested layers.

#11.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.

Phase 7 activates this layer for gameplay before expanded construction requires local access. World owns traversability, local path results, obstruction invalidation, position, and arrival tolerance. Game movement orders request a typed Site or world-position target; App, Controls, Render, and Tools do not author or repair navigation state. Phase 8 ecology, Phase 11 rescue, and Phase 12 tactical movement consume this path only after the Phase 7 proof is complete.

#11.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.

#11.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.

#11.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

#11.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.

#11.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

#11.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.

#11.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

#11.7Focus and Simulation Heat Model

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

The world uses 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.

#11.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.

#11.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.

#11.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.

#11.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.

#11.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.

#11.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

#11.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

#11.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.

#11.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

#11.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.

#11.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.

#11.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.

#11.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.

#11.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.

#11.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.

#11.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 greater world breadth means equal simulation everywhere
• making route logic depend on full offscreen pathfinding every second

#11.24Game Development Expansion

The engine already owns the bounded chunk, region, route, Site, residency, heat, promotion, demotion, persistence, and selective-fidelity model. Phase 15 makes that model visibly connected through hierarchical inter-chunk traversal and resident-chunk terrain. Phase 18 expands regional knowledge, climate, ecology, and discovery. Phases 19-22 add settlements, institutions, narrative opportunities, factions, logistics, and conflict without changing chunk or region ownership. Phase 23 closes production-world budgets and content breadth.

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.

#14.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.

#14.2Entry and Exit Contract

Direct control has an explicit boundary:

• clicking selects for observation
• ordinary orders use assignment authority
• Take Control requests direct authority through the normal command owner
• the request may be rejected because of authority, state, distance, incapacity, or scenario rules
• Release Control reconciles retained plans, jobs, needs, position, condition, and consequences

Camera focus, UI inspection, and selection markers are not gameplay pressure. They cannot alter motivation, emotion, work, or risk merely because the player is watching.

#14.3What 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

#14.4What 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.

#14.5Recommended Control Model

The control model is:

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

#14.6Command Authority Levels

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

#14.6.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.

#14.6.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 the project's default "micro adventure" mode.

#14.6.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

#14.7Control 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.

#14.8Direct 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

#14.9Party 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.

#14.10Dialogue, 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.

#14.11Combat 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

#14.12Resistance, Obedience, and Tone

The game avoids 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

#14.13Memory 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.

#14.14Direct Control and Story Priority

Recent direct control should produce two separate derived inputs rather than one durable story score: narrative presentation may treat the episode as recently relevant, and World may accept a time-bounded recent-control reason when deciding heat. The Actor does not own player interest or assign its own simulation tier.

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

#14.15Offscreen 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.

#14.16Failure 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

Valid ordinary orders should therefore remain reliable. Actor identity affects execution speed, capability, morale, risk, consequences, and later interpretation. It must not create arbitrary ordinary-order refusal. Domain invalidity, incapacitation, or an explicitly declared critical safety rule may block or interrupt an order, but the owning system must return a visible reason.

Phase 6 must prove this with two Actors who have different owned capability, condition, or temperament facts. They execute the same valid command through the same command owner and produce different, explained performance or outcomes without either Actor receiving hidden command rules.

#14.17First Proof and Expansion Targets

Phase 4 proves direct control with:

• leading one villager or a small Party to an authored Site
• simple direct combat against wildlife
• one noncombat traveler dispute where capability or trait facts affect an eligible outcome
• one scouting or investigation order through observer knowledge

Phase 11 expands this command, Party, incident, and consequence foundation into multi-step escort, rescue, social, diplomatic, and institutional requests. Escort is not part of the first direct-control proof.

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

#15.1Ambient Story

Things the world does on its own:

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

#15.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.

#17.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

#17.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.

#17.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

#20.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

#20.2Pressure Curves, Root Choice, and Method Choice

Needs and emotional pressures must not use one global reaction threshold. Worldforge uses one shared pressure-response evaluator with actor- or source-owned curve data. The evaluator accepts a bounded pressure, a reviewed response curve, an action score, a critical pressure, and a clear pressure. It returns the raw pressure, curved score, and action, critical, and clear crossings in a detached trace. Hunger, rest, safety, warmth, and companionship use this contract. Later fear, grief, anger, duty, and relationship pressures should use the same evaluator without moving their authoritative facts into a global AI owner.

The layers have separate jobs:

• needs, affect, memories, relationships, rumors, and events own the facts that create pressure
• the shared curve evaluator turns those facts into comparable, inspectable response values
• IAUS ranks eligible root concerns, such as work, hunger, safety, or companionship
• shallow HTN decomposition selects an interpretable method for the chosen root
• the actor retains the selected commitment and current safe interruption point
• Work, Resource, World, and other domain owners execute and validate the method's steps

This separation allows two people to react differently to the same raw fact. A fearful actor may cross the action score quickly after a credible wolf rumor. A brave actor may retain work until the threat becomes critical. A recent breakup may add a strong companionship or grief pressure for one actor while another actor's traits, relationships, and coping tendencies produce a slower curve. The event or relationship system owns the causal shock and its decay. The curve system does not store a second copy of the breakup, rumor, or relationship.

#20.3Inherited Baselines and Individual Temperament

Pressure responses should be authored as reusable population templates, not hand-tuned for every person. A template defines the baseline curves and the maximum permitted variation for each drive. When a person is created, the actor system deterministically generates compact hunger, rest, safety, warmth, and companionship sensitivity coefficients from the population seed, stable actor ID, template ID, and reviewed generator version. Two people may therefore inherit the same baseline_adult template while crossing action or critical pressure at different times.

The generated coefficients are bounded. They adjust the pressure supplied to the shared curve evaluator but do not create separate behavior branches or allow unlimited modifier stacking. The inspector must show the raw pressure, sensitivity coefficient, adjusted pressure, template ID, generator version, and generation key so the difference remains explainable.

Templates are immutable authoring data after roster creation. The actor owns the materialized baseline, generated temperament, and provenance in runtime and save state. Saving an existing person stores those values rather than only a random seed; later template balancing or generator changes therefore cannot silently rewrite that person's behavior. Newcomers can use the current template version. Phase 10 lineage proved bounded parental variation through the same actor-owned coefficient record rather than introducing another response system; Phase 17 may tune the population-facing balance without changing that owner.

This variation changes tendencies, not destiny. Skills, relationships, memories, location, opportunities, possessions, health, and incidents provide the experiences that make lives diverge. Temperament changes how a person responds to those experiences.

#20.4Commitments and Safe Interruption Points

Crossing an action score does not automatically abandon the current task. Every executable method declares its interruption policy:

• immediate safety override for critical danger, incapacitation, or other hard failures
• finish the current atomic Work step, then reconsider
• continue until a named checkpoint, such as delivery, tool return, or shift boundary
• use an on-person solution, such as eating an unreserved carried meal

For example, ordinary hunger during work may select finish current Work step -> eat carried meal -> resume retained job. The actor keeps the Job and Work-task checkpoint identity while the method is pending. Resource validates that the meal is real, belongs to the actor, and is not cargo in transit for active Work. Consumption and hunger relief commit as one coordinated transaction. Only critical hunger uses the interruption safety override. An idle actor with the same meal may select eat carried meal immediately without manufacturing a Work checkpoint. This prevents actors from dropping tools at the first threshold while preserving urgent failure behavior.

#20.5Dijkstra / 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.

#21.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

#21.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

#21.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.

#21.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

#21.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.

#21.6Need Categories

Needs are grouped by behavioral role.

#21.6.1Survival Needs

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

These needs deserve the strongest behavioral authority.

#21.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.

#21.6.3Psychological Needs

• curiosity
• comfort
• autonomy
• emotional regulation

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

#21.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.

#21.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

#21.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.

#21.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.

#21.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.

#21.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.

#22.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

#22.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.

#22.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.

#22.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.

#22.55. Affect

Short- to medium-term emotional condition:

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

Affect should alter judgment, not replace personality.

#22.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.

#22.77. Bonds

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

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

#22.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.

#22.99. Reputation

How broader groups perceive someone:

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

#22.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.

#23.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

#23.2Schema Categories

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

#23.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

#23.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

#23.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

#23.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

#23.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

#23.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

#23.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

#23.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

#23.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

#23.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

#23.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

#23.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

#23.2.1313. Control and Narrative References

The Actor record stores only stable references needed to preserve its current control and causal state. It does not own a combined story-importance or player-interest score.

Relevant facts may include:

• current control authority and order source
• retained incident, memory, relationship, obligation, and consequence references
• the tick and reason for the most recent accepted control transition

Player favorite and pin state belongs to player-profile presentation data. Narrative salience is derived from owned incidents, memories, relationships, obligations, and recent control. UI may rank detached facts for presentation. World validates explicit promotion reasons and remains the only owner of heat and residency state.

#23.3Minimal Required Record

The leanest villager record includes 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.

#23.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"]
    }
  ]
}

#23.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

Inherited variation includes:

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

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.

#27.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

#27.2Three Narrative Sources

The game supports three main sources of quest and event content.

#27.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.

#27.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

#27.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.

#27.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

#27.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

#27.5Event Lifecycle

A useful event lifecycle is:

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

#27.5.1Dormant

The template exists as a possibility but is inactive.

#27.5.2Triggered

World conditions satisfy the activation rules.

#27.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.

#27.5.4Engaged

The event becomes actively processed by:

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

#27.5.5Resolved

The event reaches an outcome state.

#27.5.6Persisted as Aftermath

Its consequences remain in:

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

#27.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

#27.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

#27.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.

#27.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

#27.10Ambient Versus Foreground Events

The event architecture should strongly distinguish between:

• ambient events
• surfaced events
• foreground quests

#27.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

#27.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

#27.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.

#27.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.

#27.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.

#27.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

#27.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.

#27.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.

#27.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.

#27.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

#27.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

#27.19Game Development Expansion

The engine already owns bounded Incidents, Quests, participants, consequences, memory, reputation, knowledge, Parties, travel interruption, rescue, diplomacy, and persistence. Game Development expands that foundation in dependency order:

• Phase 18 composes travel, discovery, danger, uncertainty, and return into expedition incidents.
• Phase 20 proves civic requests, evidence, obligations, diplomacy, and institutional consequence.
• Phase 21 owns the complete narrative loop: systemic events, structured templates, dialogue,

interruptible quests, autonomous and neglected outcomes, personal adventures, handcrafted arcs, repetition control, and durable aftermath.

• Phase 22 applies the same narrative and consequence contracts to conflict, occupation, loss, and

recovery.

• Phase 23 broadens validated narrative content and builds only the authoring tools justified by

repeated production work.

#28.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.

#28.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

#30.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

#30.2Core UI Philosophy

The UI should be built around three simultaneous lenses:

#30.2.11. Settlement Lens

Use for:

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

This is the macro governance layer.

#30.2.22. Person Lens

Use for:

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

This is the attachment layer.

#30.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.

#30.3Required Player Questions

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

#30.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

#30.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

#30.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.

#30.4Primary Information Layers

The game surfaces information in layered bands rather than one universal feed.

#30.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.

#30.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

#30.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.

#30.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

#30.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.

#30.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.

#30.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.

#30.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.

#30.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.

#30.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.

#30.7Event Surfacing Model

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

Instead, events should pass through surfacing tiers:

#30.7.1Ambient

Logged quietly into digest or biography surfaces.

Use for:

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

#30.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

#30.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.

#30.8Biography and History Presentation

The project needs a strong biography surface for important villagers.

A villager profile contains:

• 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.

#30.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.

#30.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.

#30.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

#30.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.

#30.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.

#30.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.

#30.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

#30.16Game Development Expansion

The engine already provides the bounded settlement, person, and episode lenses plus developer inspection. Phase 14 exposes owner-built facts, actions, widgets, surfaces, slots, themes, input, reload, and recovery through the documented Lua standard interface and external API Reference. Every later phase must extend that interface with its own minimum facts, causes, choices, progress, failure, uncertainty, accessibility, and normal-play live proof. Phase 23 broadens presentation and end-user customization only after those phase-local interfaces are proven.

The ordinary graphical launch loads only first-party standard packages. Development packages are an explicit --development-addons opt-in. The standard village view remains useful with no current selection: it reads one bounded Settlement page, the active Construction page, and its Work-owned priority, then shows residents, households, buildings, project progress, and assigned labor. Its priority control submits the registered revision-checked Work command. Selecting a resident adds their authored profession and the existing routine, need, Household, destination, and work facts. The same normal view now shows a newest-first village chronicle of completed conversations, support, and disagreements. Selecting a resident pages their retained named relationships and current stage. Incident, Relationship, Memory, and Actor remain authoritative; the interface keeps no parallel social history.

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

#31.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

#31.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

#31.3Intersection Inputs

Intersection evaluation reads:

• 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

#31.4Incident Family Definition Ownership

Phase 4 uses two compiled incident-family definitions, wildlife.predator and traveler.dispute, plus two compiled display labels. This is bounded proof data for the reusable selector, lifecycle, scheduling, presentation, and outcome boundaries. It is not the production content-authoring path.

Phase 11 must convert these defaults before adding a third broad content family. A validated, versioned incident-family catalog should provide:

• one stable family ID and content version
• selector gates, capability requirements, consideration weights, and tuning version
• display name and summary keys plus any category, urgency, or response metadata needed by detached presentation
• one registered outcome-resolver ID when the family has distinct resolution behavior

The selector consumes immutable catalog definitions and remains mutation-free. Tools receives display metadata through detached incident inspection instead of comparing family strings. App submits one family-agnostic resolution request. A narrow Game registry maps the retained resolver ID to a focused outcome module; that module validates the family-specific result and coordinates requests to existing Actor, World, Work, Resource, relationship, memory, or consequence owners.

The catalog does not become a universal event bus or a second owner of incident outcomes. A family that reuses an existing outcome contract may be added as validated data. A family with genuinely different rules adds one focused Game outcome module and one registry entry, but it must not require new family branches in selection, generic App composition, or Tools presentation. Scripting remains closed until repeated Phase 11 content proves a specific need that validated data and focused C++ owners cannot meet.

#31.5Intersection Categories

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

#31.5.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

#31.5.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

#31.5.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

#31.5.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

#31.5.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

#31.5.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

#31.6Intersection 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

#31.6.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

#31.6.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

#31.6.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

#31.6.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

#31.6.55. Resolution Mode Selection

The incident becomes:

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

#31.6.66. Aftermath Write-Back

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

#31.7Ambient, Surfaced, and Embodied Intersections

Not every intersection should produce an encounter scene.

There should be at least three outcome bands:

#31.7.1Ambient

The incident resolves quietly and only alters simulation state.

Example:

• two villagers become friendlier after repeated work overlap

#31.7.2Surfaced

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

Example:

• north route increasingly unsafe due to predator activity

#31.7.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.

#31.8Repetition 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

#31.9Opportunity 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.

#31.10Path 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.

#31.11Site 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.

#31.12Timed 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.

#31.13Multi-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.

#31.14Intersections 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.

#31.15Intersections 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.

#31.16Anti-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

#31.17First Proof and Expansion Targets

Phase 4 proves the reusable core with:

• one hostile route encounter
• one noncombat traveler dispute through the same lifecycle
• one scouting or investigation result through the observer-knowledge owner

Phase 8 expands discovery and environmental intersections. Phase 11 expands social and institutional intersections and proves that a third data-only family does not require generic App, selection, or Tools branches. These families share the incident lifecycle, but they do not need to exist in the first implementation.

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.

#32.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.

#32.2Three Main Consequence Layers

A useful framing is three linked layers:

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

#32.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

#32.2.22. Social Propagation

What travels from one actor to others.

Examples:

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

#32.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

#32.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.

#32.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

#32.5Memory Structure

Memory records stay lightweight but meaningful.

A memory entry includes:

• a stable typed memory ID and holder Actor ID
• a registered, versioned memory-kind ID
• witnessed or reported provenance with a source incident; reports also name the reporting Actor and source memory
• source, creation, and expiry ticks
• a typed Site ID and optional route-segment ID
• sorted stable participant Actor IDs
• initial intensity in fixed-point basis points
• valence
• tags
• behavior effects
• a registered disclosure-policy ID
• a registered decay profile

The memory owner retains initial intensity and derives current intensity from age and the registered decay curve. It does not rewrite every memory every tick. The initial implementation keeps at most 64 active memories per holder. Capacity cleanup removes expired records first, then uses effective intensity, creation tick, and stable memory ID as deterministic eviction keys.

Useful categories:

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

Valence can help express whether the memory is:

• positive
• negative
• mixed
• unresolved

#32.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.

#32.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.

#32.8Disclosure Rules

Memories should use explicit disclosure policies rather than a Boolean shareable flag. Propagation is a later command/result path between memory owners; it does not directly mutate an Actor.

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.

#32.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

#32.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

#32.11Rumor Versus Report

The architecture should distinguish between:

• rumor
• witness account
• accepted report
• official record

#32.11.1Rumor

Low-certainty socially spread information.

Can:

• be incomplete
• be distorted
• spread widely

#32.11.2Witness Account

High-certainty from someone directly involved or present.

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

#32.11.3Accepted Report

Information a community more or less believes.

This is often what matters for practical social consequences.

#32.11.4Official Record

Information recognized by a formal institution.

This may matter for:

• diplomacy
• law
• taxation
• honors
• punishment

#32.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.

#32.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.

#32.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.

#32.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.

#32.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.

#32.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

#32.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.

#32.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.

#32.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.

#32.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

#32.22First Proof and Expansion Targets

Phase 5 proves one bounded consequence family from the retained dangerous trip:

• dangerous trip -> witness memory -> route fear or learned avoidance
• direct witness -> bounded household and settlement propagation
• retained consequence -> one reputation, relationship, or household reaction -> later decision

Phase 10 expands missing-person, grief, caregiving, and life-progression consequences. Phase 11 expands diplomatic mistakes into official distrust and later institutional response. Those later chains reuse the Phase 5 owners and propagation contracts rather than expanding the first proof.

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.

#35.1Why This State Machine Exists

The current runtime has one direct path: load project data, construct a session, run it, and shut down. That direct path is adequate for completed Phase 0 behavior, but Phase 1 will introduce world and session-loading responsibilities that need an explicit coordination owner. The lifecycle foundation therefore belongs in a Phase 0 Addendum before Phase 1. The addendum formalizes the existing direct path without implementing a title screen, empty front end, session replacement, or asynchronous loading.

An explicit application flow should provide:

• one owner for legal lifecycle transitions
• one observable current lifecycle state and transition reason
• identical lifecycle rules for graphical and headless composition where their flows overlap
• transactional session creation, so a failed load cannot partially replace the active session
• explicit input reset, worker cancellation, resource release, and shutdown boundaries
• failure states that retain useful diagnostics without leaving half-owned services alive

#35.2State Model

The target application states are:

#35.2.1`bootstrapping`

The app validates configuration and required project data and constructs process-level services. No mutable gameplay session exists. Partial startup failure must unwind already-created services in reverse ownership order.

#35.2.2`front_end`

The process is ready but no gameplay session exists. This state may later host a title screen, scenario selection, load-game selection, settings, and recoverable error messages. It is a Phase 6 player-interface responsibility and should not be implemented as an empty placeholder during Phase 1.

#35.2.3`loading_session`

The app validates the requested scenario or save and constructs a complete candidate session. The current session, if any, is not mutated in place. A successful candidate becomes authoritative in one commit; a failed candidate is discarded with an explicit diagnostic.

#35.2.4`active_session`

A valid RuntimeSession and its required services exist. Simulation may be running, paused, or performing an authorized single step, but those are Simulation-owned run-policy states rather than application-flow states.

#35.2.5`leaving_session`

The app stops accepting new gameplay requests, resolves the chosen save or discard policy, cancels session-scoped work, clears held input, and destroys session-scoped resources in defined reverse order. The next state is front_end or shutting_down.

#35.2.6`faulted`

A process-level or session-transition failure is retained with its operation, source, and reason. If the front end and its required services remain healthy, the player may return there. Otherwise the only legal destination is shutting_down. A fault does not authorize partial session state.

#35.2.7`shutting_down`

The terminal application state. No new session, simulation, asset, or UI work may begin. Remaining process-level services are released in reverse ownership order before exit.

#35.3Legal Transition Table

The controller should accept only these transition families:

• bootstrapping -> front_end after process services and front-end prerequisites validate
• bootstrapping -> loading_session for direct scenario launch and headless runs
• bootstrapping -> faulted or shutting_down after unrecoverable startup failure
• front_end -> loading_session after a validated new-session or load-session request
• front_end -> shutting_down after a quit request
• loading_session -> active_session after complete candidate-session construction succeeds
• loading_session -> front_end after a recoverable load failure or cancellation
• loading_session -> faulted after a failure that leaves the front end unusable
• active_session -> leaving_session after return-to-front-end, replace-session, or quit intent
• leaving_session -> front_end after session cleanup completes
• leaving_session -> loading_session only for an explicitly validated replace-session request
• leaving_session -> shutting_down after quit intent and complete session cleanup
• faulted -> front_end only when process-level services required by the front end still validate
• faulted -> shutting_down for every unrecoverable failure

There is no legal direct transition from front_end to active_session, from active_session to front_end, or from active_session directly to shutting_down. Loading and cleanup must remain observable owners rather than hidden work performed by an enum assignment.

#35.4Separate Simulation Run Policy

Application flow and simulation run policy are orthogonal:

• App owns whether a valid session exists and whether it is loading, active, or leaving.
• Simulation owns running, paused, and authorized single-step behavior for an active session.
• Controls may request pause or lifecycle behavior but cannot write either state directly.
• Player UI and developer tools read both states and explain them; they do not own transitions.
• A pause menu is a UI overlay plus a Simulation-owned pause request. It is not a replacement for the active_session application state.

This separation prevents state multiplication such as active_paused_inventory, active_paused_settings, or active_running_debug. UI panels and overlays should use their own small presentation state where needed.

#35.5Ownership and Data Contract

The intended implementation is a narrow App-owned controller, not a general state-machine framework. A concrete design should contain:

• ApplicationFlowState, containing only the lifecycle enum
• ApplicationFlowRequest, containing a requested transition, stable request sequence, session descriptor where required, and reason
• ApplicationFlowResult, reporting accepted, rejected, completed, cancelled, or failed outcomes
• ApplicationFlowController, validating legal transitions and owning the current lifecycle state
• explicit composition operations that construct or destroy services and sessions after validation
• an inspector snapshot containing current state, pending request, last transition, and last failure

Commands request transitions. App validates and performs them. Results report facts after mutation. The transition controller must not load files, mutate ECS state, call renderer backends, or hide resource ownership inside callbacks. The composition root performs those operations through the existing owners and commits the state transition only at the documented boundary.

Application flow is transient process state. It is not serialized as world truth. Saves contain the durable session data owned by Game and Simulation. Replay may record lifecycle requests needed to reproduce a test, but it must not make a captured loading_session or leaving_session value a second restore path.

#35.6Implementation Plan

#35.6.1Stage 1: Pure Transition Contract

Add the enum, request/result types, a table-driven legality function, transition reasons, and unit tests. Do not move startup or shutdown code yet. Prove every legal edge and representative illegal edges without SDL, assets, ECS, or threads.

#35.6.2Stage 2: Current Direct-Launch Path

Route the existing graphical and headless direct-scenario flow through bootstrapping -> loading_session -> active_session -> leaving_session -> shutting_down. Keep all current services and mutation owners. This stage changes coordination only and must preserve output, replay hashes, reset behavior, and destruction order.

#35.6.3Stage 3: Transactional Session Loading

Construct a candidate session and its session-scoped resources outside the authoritative active session. Commit only after configuration, scenario, scene, world state, presentation assets, and cross-owner validation succeed. Add cancellation and failure injection before considering workers.

#35.6.4Stage 4: Front End and Recoverable Flow

Phase 6 may add front_end, return-to-front-end, load selection, save/discard confirmation, and recoverable error UI. This stage must reuse the same controller in graphical and headless tests, while headless execution may continue using the direct-launch subset.

#35.6.5Stage 5: Asynchronous Loading Only After Measurement

If Phase 1 measurements justify background loading, keep worker completion outside lifecycle authority. Workers produce bounded results tagged with request sequence and cancellation generation; App accepts them in a defined order and ignores stale results. Asynchrony does not add new lifecycle states merely to describe implementation details.

#35.7High-Risk Changes

The following changes require isolated slices and failure-injection proof:

#35.7.1Resource Lifetime and Destruction Order

Moving startup and shutdown coordination can cause double destruction, use-after-release, leaked SDL resources, workers that outlive their owners, or a renderer referencing session assets after the session is gone. Every session-scoped and process-scoped resource needs an explicit owner and release order before Stage 2 begins.

#35.7.2Pause and Single-Step Semantics

Treating pause as an application state would compete with the fixed-step scheduler, change replay behavior, and create invalid combinations during loading or shutdown. Pause must remain a Simulation run policy that is valid only while the application state is active_session.

#35.7.3Save, Restore, Reset, and Replay Authority

Serializing transient lifecycle state can turn loading or leaving into a second mutation path. Save and replay must continue restoring through RuntimeSession and domain owners. Scenario reset must not recreate the process lifecycle controller or bypass session cleanup.

#35.7.4Transactional Loading and Failure Recovery

A load may fail after some assets, ECS data, presentation resources, or workers exist. Candidate state must remain detached until all required owners validate. Failure cleanup must preserve the old active session or return to a known session-free state.

#35.7.5Input Routing Across Transitions

Pressed or held input can leak from a menu, loading screen, or old session into a new session. Every transition that removes or replaces an active session must inject one backend-neutral input reset and discard stale session-targeted commands.

#35.7.6Graphical and Headless Divergence

The graphical path has SDL, presentation, and UI resources that headless execution omits. A controller implemented only inside the graphical loop would produce two lifecycle contracts. The transition logic must remain backend-neutral even though composition operations differ.

#35.7.7Asynchronous Completion Order

Worker completion depends on timing and must not decide authoritative transition order. Stale load results, cancellation races, quit-during-load, and request replacement are mandatory tests before background work can participate.

#35.7.8State Explosion and Hidden Global Ownership

Adding states for menus, overlays, actor behavior, network status, streaming heat, or every error subtype would create a monolith. The application FSM must reject facts owned by Simulation, Game, Controls, Render, Assets, or UI rather than absorbing them for convenience.

#35.8Benefits

• Startup, loading, session replacement, return-to-front-end, and shutdown become explicit and testable.
• Invalid lifecycle requests fail at one boundary with a useful reason.
• Partial load failures can recover without corrupting the current session.
• Graphical and headless execution share a lifecycle contract.
• Tools can explain the current state, pending request, and last failure.
• Future title, loading, save-selection, and results screens gain a stable behavior owner.
• Input reset, worker cancellation, replay, and resource release receive named transition points.

#35.9Potential Drawbacks

• The controller adds coordination types and tests before it adds visible gameplay.
• Migrating the current direct loop creates regression risk in already-proven startup and shutdown.
• More legal states increase the failure matrix and require systematic transition tests.
• Transactional loading may temporarily hold both old and candidate session resources.
• A poorly scoped controller can become a service locator or central event bus.
• Developers may incorrectly add new global states instead of fixing ownership in a domain system.
• Front-end recovery and async cancellation can substantially increase code paths if introduced before a real product requirement exists.

#35.10Verification Gates

Implementation is not complete until it proves:

• exhaustive legal-transition tests and representative illegal-transition rejection
• identical transition results for repeated request sequences
• unchanged graphical and headless direct-launch outcomes after Stage 2
• clean shutdown from every nonterminal state, including failure and cancellation points
• sanitizer-clean construction, replacement, cancellation, and destruction paths
• input reset and stale-command rejection when leaving or replacing a session
• transactional failure at each loading boundary without partial authoritative mutation
• pause, single-step, reset, save/restore, and replay behavior remain under their existing owners
• an inspector can show current state, last transition reason, pending request, and failure details
• no application lifecycle value is treated as durable world or save authority

#35.11Phase Ownership

• D.6 owns the permanent architecture boundary and the rule against a monolithic global FSM.
• Phase 0 Addendum owns Stages 1-2: the pure transition contract, the existing graphical and headless direct-launch route, failure reporting, input cleanup, inspection, and shutdown proof.
• Phase 1 owns Stage 3 for transactional candidate world/session loading. Synchronous streaming remains the first proof path. Phase 1 may add Stage 5 only after measurement justifies bounded background work.
• Phases 2-5 extend their own actor, job, control, encounter, and consequence state machines without adding application lifecycle states.
• Phase 6 owns Stage 4, player-facing front-end flow, save/discard confirmation, recoverable errors, lifecycle explainability, and the final interaction audit.

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

#36.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.

#36.2Core Runtime Layers

The runtime is divided into cooperating layers rather than one monolithic update loop.

#36.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.

#36.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."

#36.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

#36.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.

#36.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.

#36.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

#36.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

#36.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.

#36.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

#36.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.

#36.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

#36.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.

#36.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.

#36.6Travel Model

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

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

Travel is 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.

#36.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.

#36.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.

#36.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

#37.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

#37.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

#37.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

#37.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.

#37.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

#37.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.

#37.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

#37.4Job Lifecycle

A settlement job moves 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

#37.4.1Created

The world state generates the job from a need.

#37.4.2Visible to Eligible Actors

The job enters the local or settlement labor market.

#37.4.3Claimed or Assigned

Either:

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

#37.4.4In Progress

The actor is executing the plan generated from the job.

#37.4.5Blocked or Interrupted

Causes might include:

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

#37.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

#37.4.7Completed

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

#37.5Push Versus Pull

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

#37.5.1Pull

Villagers look for jobs they can do.

Good for:

• organic autonomy
• believable daily routines
• reducing player micromanagement

#37.5.2Push

The player or settlement explicitly assigns work.

Good for:

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

The model is:

• pull by default
• push when the player cares

This fits both the cozy-builder and RTS layers.

#37.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.

#37.7Priority Architecture

Job priority is a composite score rather than one arbitrary 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.

#37.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.

#37.9Reservation and Claiming

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

Reservations apply to:

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

A claim includes:

• 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

#37.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

#37.11Construction Jobs

Construction decomposes 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

#37.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.

#37.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.

#37.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

#37.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

#37.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

#37.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.

#37.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.

#37.19Game Development Expansion

The engine already owns demand, Job, WorkTask, reservation, assignment, interruption, cancellation, construction, hauling, household duty, crisis work, persistence, and deterministic contention. Phase 16 composes those owners into normal visible settlement life. Phase 17 adds care and household commitments. Phase 19 expands production, autonomous projects, businesses, trade, and specialization. Phases 20-22 add institutional, narrative, and conflict work without adding a second labor market.

#37.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.

#37.21Event Ledger

The simulation uses 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

#37.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.

#37.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

#37.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.

#38.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

#38.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.

#38.3Core Material Layers

The economy consists of several linked layers.

#38.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.

#38.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.

#38.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.

#38.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.

#38.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.

#38.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.

#38.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.

#38.6Stockpile Model

Stockpiles should not just be global magic inventory pools.

The economy supports 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.

#38.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.

#38.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.

#38.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.

#38.10Food Economy

Food is 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

#38.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

#38.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.

#38.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.

#38.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

#38.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.

#38.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.

#38.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

#38.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.

#38.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.

#38.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

#38.21Game Development Expansion

The engine already owns registered resources, finite and renewable sources, physical custody, carrying, storage, reservations, conversion, consumption, trade obligations, conserved money, and throughput diagnostics. Phase 16 proves a readable starter economy. Phase 18 adds environmental limits and discovered sources. Phase 19 expands production, markets, wages, trade, specialization, decline, and recovery. Phase 20 adds public and trusted finance. Phase 22 applies destruction, displacement, supply, and recovery pressure. Phase 23 expands validated content breadth without adding another economy owner.

The player is primarily a watcher and arbiter. They can inspect, prioritize, permit, prohibit, fund, assign, or explicitly take direct control, but ordinary settlement life must not wait for them.

#39.1Product Contract

The settlement game must support all of these outcomes:

• a small group establishes shelter, water access, food, and storage
• additional households join, form, divide, inherit, migrate, or disappear
• public and private projects compete for land, labor, materials, and money
• different settlements make different civic, cultural, economic, and defensive choices
• production and infrastructure create real advantages and maintenance obligations
• shortages, injury, disease, death, debt, conflict, bad leadership, or unsafe geography can stop growth or cause decline
• successful settlements may specialize, establish outposts, influence neighbors, and become part of a regional polity
• failure remains a valid simulation outcome; settlement labels and capabilities may regress

Growth is not a guaranteed ladder. The same starting conditions should not always produce the same town.

#39.2Observation, Orders, and Direct Control

Clicking a villager selects them for observation. It must not change their control state, current plan, pressure curves, job claim, risk tolerance, or decision scoring.

Selection may:

• show identity, household, traits, needs, condition, wealth, equipment, current intent, job, destination, relationships, memories, and recent decision reasons
• make the villager easier to follow with the camera
• mark the villager as a possible recipient for an assignment or command
• keep presentation data available while the inspection surface is open

Selection must not:

• enter direct control
• cancel or supersede autonomous work
• make the villager aware that the player is watching
• change IAUS inputs or HTN planning
• create simulation pressure merely because the camera or cursor is nearby

Direct control requires a separate explicit action such as Take Control, a dedicated hotkey, or an unambiguous command-mode action. The action uses normal command validation and may be rejected. Release Control is equally explicit. Selection and control may therefore refer to different sets: the player can inspect one villager while controlling another person or Party.

An ordinary move, gather, build, or priority order uses assignment authority unless the player has explicitly taken direct control. Direct control is reserved for moment-to-moment steering, dangerous expeditions, tactical encounters, and other deliberate interventions.

#39.3Settlement Identity Is a Capability Profile

village, town, city, and kingdom should be readable descriptions derived from actual state, not authoritative upgrade levels or one linear technology tree.

A settlement profile is derived from independently owned facts such as:

• resident and dependent population
• safe housing and household capacity
• water, food, fuel, health, and sanitation reliability
• storage, transport, and route access
• production breadth, tool quality, and specialist labor
• public safety, maintenance, and defensive capability
• market reach, trade obligations, and financial institutions
• civic, cultural, religious, educational, and governing institutions
• influence over outposts, settlements, territory, and external obligations

The profile can describe both scale and character. Examples include:

• small agricultural village
• fishing and river-trade town
• fortified mining town
• pilgrimage center
• market city
• declining former capital

No building should directly set is_city = true. A city that loses population, water reliability, trade, or institutional continuity may remain physically large while becoming functionally weak. A kingdom is not a very large city; it is a governed network of settlements, institutions, territory, obligations, and external relationships.

#39.4Capability Domains and Hierarchical Needs

Settlement needs are hierarchical in pressure, but not a rigid unlock tree. Critical deficits produce urgent work. Stable foundations allow households and institutions to pursue higher-order goals. Several domains may develop at once, and culture or geography may change their relative weight.

#39.4.1Survival

• potable water access and delivery
• calories, nutrition variety, preservation, and seasonal reserves
• shelter, warmth, sleep, and household capacity
• sanitation, waste handling, burial, and disease control
• basic treatment, care, and recovery

#39.4.2Stability

• safe storage and stock rotation
• reliable routes and hauling capacity
• fire prevention and emergency response
• tool availability and routine maintenance
• protection from animals, crime, raids, and environmental exposure

#39.4.3Production

• extraction and renewable resource stewardship
• processing, workshops, tools, fuel, and skilled labor
• construction capacity and material staging
• transport equipment, roads, bridges, docks, and depots
• surplus creation without exhausting households or local ecology

#39.4.4Social and Civic Life

• gathering, hospitality, leisure, ritual, worship, and mourning
• education, apprenticeship, records, and knowledge transmission
• dispute resolution, leadership, public work, and trusted institutions
• care for children, elders, injured people, and dependents
• settlement identity, customs, celebrations, and public memory

#39.4.5Regional and Sovereign Capacity

• markets, trade routes, tariffs, contracts, and reserve policy
• migration, diplomacy, aid, and inter-settlement obligations
• outposts, roads, messengers, defense, and emergency mobilization
• durable offices, law, treasury, succession, and institutional continuity
• shared authority across multiple settlements without erasing local identity

Higher-order projects do not become impossible whenever one household is hungry. Their scores, funding, labor access, and political support should respond to the severity and duration of lower deficits.

#39.5Settlement Scale Descriptors

These descriptors communicate typical capability, not mandatory population thresholds or fixed building checklists.

#39.5.1Household, Stead, or Camp

• one or a few households
• direct access to shelter, fire, food, and water
• personal storage and mostly manual production
• little redundancy when a worker, route, or source fails

#39.5.2Hamlet

• several households sharing nearby sources and labor
• communal storage or a barn, shed, or cache
• one or two repeated work roles
• informal shared decisions and limited emergency capacity

#39.5.3Village

• dependable water, food, housing, and seasonal storage
• several material sources and basic processing
• public meeting space and some shared infrastructure
• enough labor diversity for construction, maintenance, care, and defense

#39.5.4Town

• specialist workshops and multi-step production
• market, inn or tavern, religious or civic institutions, and formal storage
• maintained regional routes and trade obligations
• durable leadership, records, public services, and meaningful specialization

#39.5.5City

• multiple districts, markets, services, and infrastructure networks
• deep production, finance, education, health, administration, and culture
• large import requirements and consequences when regional logistics fail
• several overlapping institutions rather than one universal civic owner

#39.5.6Regional Polity or Kingdom

• multiple settlements and outposts under negotiated or imposed authority
• treasury, law, succession, diplomacy, defense, and regional infrastructure
• local settlements retain distinct economies, cultures, leaders, and failure risks
• collapse may fragment the polity without deleting its people, buildings, debts, or history

#39.6Autonomous Project Lifecycle

Villagers and institutions should be able to create and complete projects without a player placing every building.

The lifecycle is:

1. owner facts emit a need, opportunity, ambition, or obligation
2. households, occupations, leaders, or institutions generate bounded project proposals
3. hard gates reject impossible land, knowledge, authority, safety, or material conditions
4. eligible proposals are scored from pressure, benefit, cost, risk, culture, relationships, sponsor wealth, public policy, and downstream needs
5. a sponsor chooses land, funding, material reservations, and labor policy
6. the normal Construction and Work owners execute site preparation, delivery, building, and commissioning
7. the completed building registers capabilities, work demand, operating inputs, capacity, maintenance, and side effects through existing owners
8. continued value is evaluated; a building may be upgraded, repurposed, sold, abandoned, damaged, demolished, or inherited

This is not a universal settlement AI manager. Need owners emit facts, proposal definitions remain data, IAUS ranks eligible alternatives, and existing domain systems execute the accepted project.

This boundary still requires a coordination plane. Avoiding a universal mutation owner must not leave food, farming, construction, infrastructure, trade, demography, and routine schedulers with no shared strategy. Settlement owns a retained development plan made of needs, forecasts, goals, commitments, dependencies, reconsideration conditions, and causal history. A pure Game reasoner proposes changes to that plan from immutable owner snapshots. App submits the accepted plan's revision-checked requests to the existing domain owners.

The development planner may decide that a settlement should restore a seasonal food reserve, add housing, repair an access road, or establish a workshop. It may not create food, claim a worker, change land, place a completed building, move money, or advance a route. Resource, Work, Actor, World, Construction, Household, Production, Trade, and Route retain those mutations.

Player direction changes priorities, permissions, sponsorship, land reservations, or explicit assignments through the same planning and owner command paths. Releasing control returns authority to the retained settlement plan rather than restarting a separate autonomous scenario.

The player may change priorities, reserve land, contribute funds, forbid a category, approve a public project when their authority requires it, or explicitly sponsor an alternative. Those actions influence the same proposal and construction path used by autonomous sponsors.

#39.7Distinct Settlement Choices

Alternative projects should satisfy overlapping needs in different ways.

For example:

• a tavern improves hospitality, leisure, information exchange, food service, and trade traffic, but consumes food, drink, fuel, labor, and public order capacity
• a church, shrine, or temple supports ritual, care, burial, legitimacy, community cohesion, and charitable reserves, but consumes construction wealth, staff time, and institutional support
• a market improves exchange and specialization but increases traffic, theft exposure, price pressure, and dependence on routes
• a fortified granary improves reserve security but costs stone, guards, maintenance, and convenient household access

Choices need not be permanently exclusive. Their opportunity cost, sponsor support, land, labor, maintenance, and cultural effects create different development paths. Content definitions supply capabilities and costs; code must not contain a tavern_or_church branch.

#39.8Building Families

Buildings are registered definitions with stable identities. Each definition states:

• capabilities and service capacity
• valid footprints, terrain, access, and adjacency
• construction stages, material alternatives, tools, labor, and skill requirements
• operating inputs, outputs, jobs, storage, and occupancy
• maintenance, fuel, cleanliness, safety, and decay
• ownership, access, rent, tax, or public-service policy
• noise, fire, pollution, disease, traffic, morale, or reputation effects
• upgrade, repurpose, damage, abandonment, and demolition rules

The content catalog should grow through families rather than unrelated special cases.

#39.8.1Shelter and Household

• temporary camp, hut, cottage, longhouse
• farmhouse, urban home, tenement, estate
• guesthouse, dormitory, barracks

#39.8.2Water, Sanitation, and Health

• water access point, well, cistern, pump
• bath, latrine, drain, sewer, waste site
• healer's room, clinic, infirmary, hospital
• cemetery, burial ground, crematory where culturally appropriate

#39.8.3Storage and Logistics

• ground stockpile, shed, barn, granary
• warehouse, cold store, cellar, armory
• cart yard, depot, dock, caravan stop

#39.8.4Food and Agriculture

• gathering camp, fishing station, hunting lodge
• field, orchard, pasture, animal shelter
• mill, bakery, kitchen, smokehouse, butcher, brewery

#39.8.5Material and Craft Production

• woodcutter camp, sawpit, lumbermill
• quarry, mason yard, clay pit, kiln
• mine, charcoal burner, smelter, foundry, forge
• tannery, loom, tailor, carpenter, general workshop

#39.8.6Civic, Cultural, and Commercial

• village green, meeting hall, town hall, courthouse
• tavern, inn, market, shop, guild hall
• shrine, church, temple, monastery
• school, archive, library, theater, festival ground
• counting house, bank, trust, treasury, mint

#39.8.7Safety, Defense, and Regional Infrastructure

• watch post, fire station, wall, gate, tower
• guard house, barracks, refuge
• road, bridge, ferry, dock, lighthouse
• waystation, outpost, customs house

Specific cultures, biomes, eras, and technologies may supply different buildings for the same capability.

#39.9Resource Definition Contract

Resource breadth must be data-driven. A new tree species, ore, crop, recipe, coin, or gemstone should normally require content definitions and validated relationships, not a new C++ branch.

Each material definition should include only relevant fields from this contract:

• stable resource ID and display metadata
• material family, physical form, and property tags
• mass, volume, stack, unit, and transport characteristics
• quality, condition, freshness, contamination, and decay policy
• fuel, nutrition, warmth, hardness, value, or other domain properties
• storage, temperature, handling, hazard, and spoilage requirements
• substitution group and conversion compatibility
• source, renewal, depletion, and stewardship policy
• recipe, construction, equipment, consumption, and trade references
• owner, location, provenance, reservation, and legal-access rules

Species and grades should matter only where they create decisions. Oak and pine may differ in growth, mass, strength, fuel value, appearance, or preferred uses. If they do not yet create a decision, both may use a broader construction timber substitution group while retaining source provenance for later content expansion.

#39.10Material Families and Growth Bands

The list below is a content framework, not a requirement to simulate every item immediately.

#39.10.1Foundation Food and Water

• forage: berries, mushrooms, roots, nuts, wild greens
• aquatic: freshwater fish, shellfish where the biome supports them
• game: small game, venison, boar, meat, fat, bone, hide
• crops: wheat or another regional grain, vegetables, legumes, fruit
• water: raw freshwater, potable water, contaminated water
• prepared food: meal, flour, bread, stew
• preserved food: dried berries, smoked fish, smoked meat, grain reserve

Wells, rivers, springs, cisterns, and aqueducts are sources or infrastructure. They are not interchangeable resource items. Their output may share the potable water material contract after quality and contamination checks.

#39.10.2Foundation Structural and Household Materials

• timber by useful species or property group
• logs, fuelwood, charcoal, planks, beams
• fieldstone, cut stone, gravel, sand
• clay, brick, ceramic
• reeds, plant fiber, rope
• hides, leather, wool, cloth
• salt, herbs, simple medicine

#39.10.3Metal and Mineral Families

• copper, tin, iron, silver, gold, and other approved ore families
• ore, concentrate, ingot, alloy, component, tool, and finished-good forms
• coal or other fuel where required by the production model
• common stone, building stone, decorative stone, and useful mineral deposits
• gemstones in rough, cut, set, and heirloom forms

Stone types are minerals or rock families. Tree species remain timber sources.

#39.10.4Mid-Development Goods

• preserved foods, drink, feed, seed, and breeding stock
• flour, bread, dairy, oil, leather, textiles, ceramics, glass
• bronze, iron, steel, tools, fittings, weapons, armor
• carts, barrels, furniture, construction components
• medicine, paper, records, books, instruments, and specialist supplies

#39.10.5Late and Generational Goods

• precision tools and complex production equipment
• architectural components and regional infrastructure supplies
• luxury food, cloth, jewelry, art, ceremonial goods, and diplomatic gifts
• archives, charters, deeds, account records, and authenticated claims
• heirlooms and named crafted objects with provenance, ownership, memory, and inheritance
• seed strains, breeding lines, recipes, and craft knowledge preserved through their proper biological, knowledge, or institution owners rather than treated as generic inventory

Knowledge, legitimacy, reputation, influence, and faith are not material resources. They retain their own owners and may affect access, decisions, and value without becoming stackable inventory.

#39.11Money, Wealth, and Financial Custody

Villagers can own money. Wealth always has an owner, custody location, and transfer history.

Supported custody scopes should include:

• coins carried in an Actor wallet or inventory
• household money stored at home
• business or workshop operating funds
• institutional reserves
• settlement treasury
• deposits held in trust by a bank-like institution

Gold, silver, and copper may exist both as commodities and as minted denominations. Ore, ingots, jewelry, and coins are different forms with different uses. Currency definitions state issuer, metal or backing, denomination, mass, validity, and acceptance. Prices use an exact value unit and cannot rely on floating-point comparison.

A deposit is not a teleported pile of coins. It is a claim recorded by a financial institution and a corresponding liability backed by reserves, loans, property, or other approved assets. Deposits, withdrawals, transfers, credit, interest, default, theft, bank failure, inheritance, taxation, and currency distrust must preserve ownership and conservation through explicit transactions.

Early settlements may use sharing, barter, favors, commodity exchange, or coin side by side. Household provisioning must not require wages unless the settlement's actual policy and ownership model make that true.

At scale, stable balances and periodic account summaries may replace embodied movement of every coin inside a trusted institution. Cash withdrawal, caravan payment, robbery, institutional failure, and audit still reconcile against real reserves and transaction records.

#39.12Prosperity, Failure, Decline, and Recovery

The simulation must not optimize every settlement toward success.

Valid failure pressures include:

• exhausted or seasonally unavailable resources
• crop failure, contaminated water, fire, weather, disease, or injury
• insufficient hauling, tools, skills, housing, care, or maintenance
• dangerous or severed routes
• badly chosen projects and unsustainable operating costs
• unequal ownership, debt, theft, corruption, or loss of institutional trust
• death or departure of key workers, leaders, caregivers, or knowledge holders
• conflict between households, institutions, cultures, or settlements
• war, migration, succession crisis, trade collapse, or ecological damage

Failure should remain causal and inspectable. It may produce stalled construction, abandoned buildings, rationing, household collapse, emigration, population decline, institutional failure, fragmentation, or settlement abandonment.

Recovery may come from adaptation, migration, changed policy, aid, trade, new leadership, repurposed buildings, ecological recovery, or player intervention. Recovery uses the same systems; it is not a free reset.

#39.13Scale and Content Expansion Contract

Settlement breadth must scale by content and bounded schedules, not global reevaluation.

• buildings emit scoped service, input, maintenance, and labor needs
• households emit bounded private needs and proposals
• settlements maintain periodic capability, shortage, throughput, and project summaries
• proposal generation is event- or cadence-driven and evaluates a bounded eligible set
• regional polities aggregate obligations and capabilities without polling every resident
• cold settlements retain causal summaries, active obligations, project milestones, balances, and significant events
• promotion restores embodied detail from authoritative owner state rather than regenerating a generic town

Adding a resource, building, recipe, culture, institution, or settlement profile should extend validated catalogs and narrow resolver registries. It must not add a parallel economy, settlement manager, save path, or simulation tier.

#39.14Player-Facing Proof of Life

The normal interface should let the player observe:

• people choosing, claiming, performing, interrupting, and completing work
• visible extraction, hauling, storage, processing, construction, and consumption
• household and public shortages
• why a project was proposed, selected, funded, stalled, changed, or abandoned
• who owns money, where it is held, and why it moved
• how a building changes services, work, costs, risks, and settlement capability
• which pressures support or threaten the current settlement profile

The first proof should favor a small number of complete visible loops. Later content breadth must reuse those loops and preserve their explanations at larger scale.

#39.15Phase Routing

• Phase 14 exposes versioned detached settlement, resource, building, wealth, and proposal facts plus typed development commands through the same authoritative owners, then composes the standard replaceable interface through documented surfaces and slots.
• Phase 15 separates observation selection from explicit direct control while proving connected movement.
• Phase 16 proves an autonomous starter settlement with visible food, water, materials, storage, construction, several building families, personal and household money, one autonomous project choice, and one recoverable or terminal failure.
• Phase 17 adds household wealth transitions, care, death, inheritance, migration, and generational continuity.
• Phase 18 adds ecological production limits, seasonal sources, field risk, environmental disruption, and regional resource discovery.
• Phase 19 expands autonomous projects, specialization, production, markets, wages, trade, settlement capability profiles, outposts, decline, and recovery.
• Phase 20 adds public finance, taxation, banks or trusts, institutional projects, civic choice, leadership, and regional-polity formation.
• Phase 21 composes systemic incidents, dialogue, quests, personal adventures, and authored arcs from real people, settlements, institutions, travel, and durable aftermath.
• Phase 22 applies defense, war, loss, occupation, and supply pressure to the same settlements and material economy.
• Phase 23 expands validated resource, building, culture, interface, audio, art, and scenario content after the systemic families are proven.

• an App-owned application and session flow state machine that remains separate from simulation run policy and gameplay state
• 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
• how the systems are ordered
• 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.

#41.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.

#41.2Canonical Build Order

The project is built around dependency truth rather than isolated features. Phase 0A-13 completed the runtime, world, Actor, work, control, consequence, persistence, scale, content, and release owners. The remaining canonical order is the gated Game Development track:

1. expose the existing engine through the scriptable standard interface, typed commands, safe

reload, recovery, and the external API Reference

1. connect embodied chunks while preserving observation, control, route, navigation, residency,

heat, save, replay, and order continuity

1. compose one inhabited settlement with autonomous food, water, materials, construction, money,

project choice, failure, and visible explanation

1. deepen daily life, health, care, households, time, death, migration, and generations
2. compose expeditions, ecology, climate, discovery, uncertainty, return, and aftermath
3. expand autonomous settlement growth, production, trade, wealth, specialization, progression,

decline, and recovery

1. add governance, institutions, public and trusted finance, diplomacy, and regional polities
2. compose systemic incidents, dialogue, quests, personal adventures, authored arcs, and durable

narrative aftermath

1. expand rival factions, supplied warfare, defense, remote conflict, loss, and recovery
2. close measured content production, modding policy, atmosphere, accessibility, long-session

balance, supported platforms, compatibility, and release expansion

This sequence does not authorize an unbounded or content-heavy world before the nearby simulation is compelling. Every phase begins with a narrow vertical proof, extends the existing authoritative owners, closes continuity and player readability, and proves scale before the next phase opens.

In practical terms, the first real question is not "can the game stream a vast 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.

#41.3Gameplay Proof Ladder

These are cross-phase product proofs, not a second implementation order. Their engine foundations exist; Game Development must now prove them as readable normal play at increasing breadth.

#41.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.

#41.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.

#41.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.

#41.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.

#41.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.

#41.5Weak Spots and Failure Modes

The design also has several dangerous weak spots that need active containment.

#41.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.

#41.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

#41.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.

#41.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.

#41.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.

#41.6Cohesion Rules

To stay cohesive, the game should protect a few non-negotiable design rules.

#41.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.

#41.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.

#41.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.

#41.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.

#41.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.

#41.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.

#41.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.

#41.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.

#41.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.

#41.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.

#41.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.

#41.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

It excluded:

• rival AI civilizations
• full dynasty simulation depth
• endless authored quest chains
• ultra-deep genetics
• world-scale perfect persistence of every micro action

It proved reusable foundations for:

• 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
• one authored construction or upgrade project with visible material and labor flow
• wildlife hunting and simple monster danger
• several named villagers with traits and memories
• direct control for one dangerous Party trip, incident response, and scouting; multi-step escort and rescue requests expand this foundation in Phase 11
• one noncombat narrative event; diplomacy expands this path in Phase 11
• offscreen risk and return behavior

The Phase 3 and Phase 6 construction proof begins from an existing authored construction site and lets the player assign Actors through the normal Work lifecycle. It does not include building placement. Phase 7 owns the first player placement, upgrade, repair, and settlement-expansion path.

If this slice is not compelling, larger world breadth should not be attempted yet.

• one bounded streamed world and one meaningful route
• several persistent people with different capabilities, traits, needs, and memories
• one food loop and one construction or upgrade loop using the same job and reservation owners
• one dangerous player-led trip and one noncombat discovery, social, or institutional event
• one household consequence that changes a later decision
• player-facing explanations for what happened, why it happened, and what can be done next

Small content count does not authorize narrow architecture. The first food source, route, building, incident, memory, and household must use stable IDs, explicit owners, versioned state, deterministic ordering, bounded work, and data contracts that allow a second instance without replacing the first implementation. This does not require a universal framework or speculative behavior. It requires that domain code describe food as registered resource data rather than a special FoodLoop, that an incident use the same lifecycle intended for later incident families, and that save/load follow the same owner that mutates runtime state.

The implementation roadmap has three bands:

1. Phases 1-6 build and prove the bounded vertical slice.
2. Phases 7-13 expand the proven contracts into a production-capable engine, systemic gameplay foundation, content pipeline, and reproducible release checkpoint.
3. Game Development Phases 14-23 compose those systems into the connected, inhabited, long-form game. Their sequence is approved, but each phase remains planned until the previous phase proof passes and the next gate is explicitly activated.

The expansion sequence is:

• Phase 7: settlement growth, buildings, housing, and infrastructure
• Phase 8: exploration, knowledge, ecology, and environment
• Phase 9: production, crafting, trade, and the regional economy
• Phase 10: personhood, social life, progression, households, and lineage
• Phase 11: structured events, quests, diplomacy, and institutions
• Phase 12: combat, warfare, factions, and world-scale pressure
• Phase 13: content production, world breadth, accessibility, and release

These later phases are planned owners, not permission to implement their systems early. Each opens only after the vertical slice passes and its direct prerequisites remain proven. Every Phase 1-6 section states which later phase extends it, which authority must remain stable, and which shortcut would force replacement. The generated Vision Coverage section maps the major Current systems to both their first proof and their expansion owner.

Completing Phase 13 proved that the architecture, systemic owners, representative scale, content validation, accessibility baseline, packaging, and release recovery work together. It does not mean the complete game design has reached final breadth or balance. The Game Development guide owns that post-engine sequence: live UI iteration, connected world traversal, an inhabited settlement, daily life, expeditions, regional economy, governance, personal narrative, factions, content production, and release expansion. The Phase 0A-13 engine sequence is sealed at its checkpoint. Engine Development remains the current implemented-engine reference and changes only after a proved engine-facing change.

Deferred does not mean forgotten. A deferred item must name its future phase and activation condition. If a Current-design promise has no owner, it is a roadmap defect that must be resolved before dependent implementation begins.

#46.1Scope Explosion

• RTS
• citybuilder
• colony sim
• open-world RPG
• emergent social sim
• narrative event system

This is the primary project risk.

#46.2Simulation Opacity

If villagers behave richly but opaquely, the player may stop trusting the game. Interpretable decision logic and good surfacing are mandatory.

#46.3Micromanagement Trap

If direct control is too strong, the player must control everything. If it is too weak, the RPG/intervention fantasy collapses.

#46.4Story Noise

If every background event is surfaced equally, no event feels important.

#46.5Open-World Complexity

Broad streamed-world requirements 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

• Phase 14: which query, event, command, widget, package, and reload budgets keep the scripted standard interface responsive without waking or copying cold simulation state?
• Phase 15: which connected-region size, border density, residency budget, and travel feedback make the world feel continuous without hiding weak local play?
• Phase 16: how much building placement, housing pressure, maintenance, and settlement breadth creates strategy without burying personhood under construction management?
• Phase 17: how punishing should sickness, death, household collapse, aging, migration, and lineage be within the intended cozy frontier tone?
• Phase 18: how quickly should knowledge become stale, how harsh should weather and ecology be, and how much regional breadth remains readable and performant?
• Phase 19: how deep can production, trade, wealth, and autonomous growth become before material causality and individual lives become opaque?
• Phase 20: how much civic authority, finance, law, and polity complexity creates meaningful governance without replacing people with abstract institutions?
• Phase 21: what systemic-to-authored balance produces memorable dialogue and quests without allowing narrative content to bypass the living simulation?
• Phase 22: what faction and warfare pressure creates meaningful stakes without turning Worldforge into a conventional army-first RTS?
• Phase 23: which supported platforms, content breadth, addon permissions, authoring tools, audio scope, accessibility commitments, and release services are justified by measured production and player evidence?

• 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.