feat: deliver emergent Jajce commitments
This commit is contained in:
Rijad Zuzo
@@ -41,10 +41,15 @@ SimulationClock
|
||||
-> ActionTargetResolver resolves a stable target ID
|
||||
-> VillageEconomy performs inventory/storage transactions
|
||||
-> AnimalCareSystem advances animal needs, routines, and feeding
|
||||
-> SimulationEventLog records completed facts
|
||||
-> SimulationEventLog records and indexes completed facts
|
||||
-> WorldEventStore exposes typed participants, locations, and causal queries
|
||||
-> EventKnowledgeSystem records, ranks, transfers, and retains bounded knowledge
|
||||
-> RelationshipSystem applies evidence-gated social consequences
|
||||
-> VillageOpportunitySystem projects one known unresolved need
|
||||
-> RelationshipSystem applies seven-dimensional evidence-backed consequences
|
||||
-> SituationSystem projects real unresolved conditions from facts and events
|
||||
-> QuestJournalSystem records only player discovery/tracking preference
|
||||
-> SocialCommitmentSystem resolves promises from ordinary outcome events
|
||||
-> ConversationService plans deterministic semantic turns from current context
|
||||
-> VillageOpportunitySystem preserves the legacy bounded compatibility slice
|
||||
-> ConflictSystem advances indexed combatants and authoritative combat outcomes
|
||||
-> WorldViewManager presents travel, NPC state, and world-state cues
|
||||
-> ActiveWorldAdapter supplies loaded-world positions/capacity
|
||||
@@ -81,14 +86,29 @@ would otherwise obscure that lifecycle:
|
||||
saves. It emits combat and war narrative facts
|
||||
and spawn/death signals that presentation binds to `HostileCombatant` visuals;
|
||||
- `simulation/events/SimulationEventLog.gd` owns ordered event identity,
|
||||
history queries, and rate calculations;
|
||||
- `simulation/knowledge/EventKnowledgeSystem.gd` owns per-NPC references to
|
||||
O(1) ID lookup, participant/type indexes, history queries, and rate
|
||||
calculations. `WorldEventStore` supplies the richer typed entity/location
|
||||
boundary without making presentation assets part of headless facts;
|
||||
- `simulation/knowledge/EventKnowledgeSystem.gd` owns player/NPC references to
|
||||
known objective events, immutable acquisition provenance, proximity witnesses
|
||||
at record time, one-hop direct fact transfer, and deterministic recent-fact
|
||||
retention/importance ranking. It can place the active opportunity trigger
|
||||
first without weakening its direct-source or one-hop checks;
|
||||
at record time, one-hop direct fact transfer, salience/confidence/pinning,
|
||||
and deterministic recent-fact retention/importance ranking;
|
||||
- `simulation/relationships/RelationshipSystem.gd` owns directed relationship
|
||||
queries, event-driven trust changes, and deterministic social tie-breaking;
|
||||
queries across familiarity, trust, affection, respect, fear, obligation, and
|
||||
hostility, exact event-backed changes, and deterministic social tie-breaking;
|
||||
- `simulation/situations/` owns typed predicates, bounded/deduplicated world
|
||||
situations, live progress projection, the player journal, and social
|
||||
commitments. None of these systems creates quest-only stock, enemies, or
|
||||
actions;
|
||||
- `simulation/dialogue/` owns semantic intent definitions, deterministic
|
||||
conversation planning, safe template substitution, and the narrow Dialogue
|
||||
Manager presentation adapter. Only semantic acts/topics enter persistence;
|
||||
- `simulation/commands/` owns copy-only commands/offers/results and reusable
|
||||
typed action effects. Concrete command services must revalidate authority at
|
||||
execution time for both player and NPC callers;
|
||||
- `simulation/regional/` owns deterministic scheduled jobs, keyed random
|
||||
decisions, and analytical elapsed-tick helpers. Presentation frame budgets
|
||||
may defer due work but cannot reorder it;
|
||||
- `simulation/population/SimulationPopulationView.gd` owns a transient derived
|
||||
all/living/starving stable-ID index. The manager rebuilds it once at the tick
|
||||
boundary and refreshes it after each interleaved NPC update; relationship and
|
||||
@@ -153,6 +173,7 @@ hard to read.
|
||||
| --- | --- |
|
||||
| `simulation/` | Headless-capable orchestration and core models |
|
||||
| `simulation/actions/` | Action decisions, execution, and target queries |
|
||||
| `simulation/commands/` | Shared player/NPC command, offer, result, and effect contracts |
|
||||
| `simulation/animals/` | Animal lifecycle, target claims, and feeding transactions |
|
||||
| `simulation/economy/` | Authoritative inventory and storage transactions |
|
||||
| `simulation/events/` | Immutable event history and derived event queries |
|
||||
@@ -160,11 +181,15 @@ hard to read.
|
||||
| `simulation/relationships/` | Directed social consequences and relationship queries |
|
||||
| `simulation/population/` | Transient per-tick population query indexes |
|
||||
| `simulation/opportunities/` | Knowledge-gated unresolved-condition projections |
|
||||
| `simulation/situations/` | World situation, journal, and commitment lifecycles |
|
||||
| `simulation/dialogue/` | Semantic conversation planning and presenter boundary |
|
||||
| `simulation/regional/` | Regional records, due-job scheduling, keyed randomness, analytical updates |
|
||||
| `simulation/state/` | Versioned, serializable mutable records |
|
||||
| `simulation/definitions/` | Stable IDs and immutable gameplay definitions |
|
||||
| `simulation/persistence/` | Validated local save-file storage |
|
||||
| `simulation/benchmark/` | Reproducible simulation and loaded-world query workloads |
|
||||
| `world/` | Loaded-world interaction geometry and presentation adapters |
|
||||
| `world/targets/` | Context-scoped target capabilities and transient presentation handles |
|
||||
| `world/animals/` | Animal presentation binding, routine sites, and navigation reporting |
|
||||
| `world/animals/goat/` | Self-contained goat scene, visual script, habitat, and lookdev scene |
|
||||
| `world/resource_nodes/` | Finite resource presentation and disposable loaded-anchor index |
|
||||
@@ -217,6 +242,15 @@ guidance without turning established-path cleanup into unrelated churn.
|
||||
- New mutable features define serialization and deterministic continuation at
|
||||
the same time as their first gameplay use. Cross-record causes use stable
|
||||
event IDs rather than object references or prose.
|
||||
- A situation or journal entry is a projection of ordinary facts. Accepting it
|
||||
creates a social commitment only; fulfillment, supersession, failure, and
|
||||
consequences always cite exact ordinary outcome events.
|
||||
- Dialogue authority is the selected semantic intent/action at an expected
|
||||
revision. Dialogue Manager renders one already-planned turn and never
|
||||
evaluates gameplay conditions or mutates simulation state.
|
||||
- Loaded navigation and visuals never decide whether distant work or travel
|
||||
completes. Regional completion belongs to serialized due jobs; presentation
|
||||
may interpolate and report local feasibility only.
|
||||
- Benchmark fixtures use ordinary simulation records and must round-trip
|
||||
through the current state schema. They may control workload setup, but must
|
||||
not add benchmark-only fields or branches to production saves and ticks.
|
||||
|
||||
+129
-120
@@ -2,154 +2,163 @@
|
||||
|
||||
## Purpose
|
||||
|
||||
Stable IDs and immutable definitions now form the vocabulary shared by
|
||||
simulation state, systems, world adapters, scenes, tests, and future save
|
||||
migrations.
|
||||
Stable IDs and immutable definitions form the vocabulary shared by simulation
|
||||
state, systems, world adapters, scenes, tests, and save migrations.
|
||||
|
||||
`SimulationIds` is the canonical source for code-facing `StringName` IDs.
|
||||
`ActionDefinition` and `ProfessionDefinition` are editor-readable custom
|
||||
resources. `SimulationDefinitions` loads, resolves, and validates the complete
|
||||
prototype set.
|
||||
`SimulationIds` remains the append-only source for code-facing compatibility
|
||||
IDs. `SimulationContentPack` is the no-code authoring manifest and
|
||||
`ContentCatalog` transactionally validates and publishes typed definitions in
|
||||
stable-ID order. The current core pack contains actions, professions,
|
||||
capability tags, items, resources, storage policies, and enemies. A failed pack
|
||||
publishes nothing: duplicate IDs, unknown references, unsupported handlers, or
|
||||
missing presentation cues are authoring errors rather than silent overrides.
|
||||
|
||||
## Current action contract
|
||||
Simulation code resolves definitions through the catalog. Presentation cue IDs
|
||||
remain headless strings and are mapped separately to scenes, materials, icons,
|
||||
or animation hooks. Runtime quantities and ownership stay in state records;
|
||||
saves do not contain `.tres` paths or copied definition balance.
|
||||
|
||||
Each executable action definition contains:
|
||||
## Content-pack contract
|
||||
|
||||
- stable `action_id`;
|
||||
- display name;
|
||||
- default duration;
|
||||
- optional preferred profession ID;
|
||||
- target type: resource, activity, animal, or free movement;
|
||||
- resource action ID when the action targets a ResourceNode;
|
||||
- optional completion-cost resource ID and amount.
|
||||
Each pack has a stable `pack_id`, display name, explicit pack dependencies,
|
||||
required handler IDs, and typed definition arrays. Pack and definition IDs are
|
||||
unique across the whole catalog. Packs cannot override each other in the first
|
||||
version, and enumeration is sorted independently of resource load order.
|
||||
|
||||
Adding data-only content is:
|
||||
|
||||
1. create a typed `.tres` definition;
|
||||
2. add it to an explicit pack;
|
||||
3. optionally register its stable presentation cue in the presentation layer;
|
||||
4. place or spawn an instance with its own canonical runtime ID.
|
||||
|
||||
Adding a fundamentally new mechanic still requires one bounded reusable
|
||||
handler. The pack declares that dependency so missing runtime support fails
|
||||
validation rather than becoming a partially functioning object.
|
||||
|
||||
## Action contract
|
||||
|
||||
Each executable `ActionDefinition` contains:
|
||||
|
||||
- stable action ID and display name;
|
||||
- duration and optional preferred profession;
|
||||
- target family and resource-action metadata;
|
||||
- optional completion cost;
|
||||
- actor and target capability tags;
|
||||
- selection, target, and completion handler IDs;
|
||||
- reusable typed effects;
|
||||
- event and presentation cue IDs.
|
||||
|
||||
Reusable `ActionEffect` definitions cover metric/need change, exact inventory
|
||||
transfer, damage/healing, relationship-dimension change, scheduling an ordinary
|
||||
action, and site-condition change. `ActionCommand` carries stable actor/action/
|
||||
target/item IDs, amount, and expected revision; `ActionOffer` and `ActionResult`
|
||||
are copy-only values. `ActionCommandService` is the authority boundary and must
|
||||
revalidate range, capabilities, reservation, permission, cost, and target state
|
||||
at execution time for either a player or NPC caller.
|
||||
|
||||
The current actions are gather food, gather wood, feed animal, deposit food,
|
||||
deposit wood, withdraw food, patrol, study, eat, rest, sleep, wander, and
|
||||
defend. Idle and dead are stable state sentinels, not executable action
|
||||
definitions.
|
||||
defend. Idle and dead are state sentinels, not executable definitions. The
|
||||
two-leg animal-feeding transaction remains a custom completion handler because
|
||||
it has a real compound pickup/delivery contract and no second shared consumer
|
||||
yet.
|
||||
|
||||
`defend` is the raid-response action: eligible strong villagers and guards
|
||||
prefer it during an active raid, travel to the guard post, and raise village
|
||||
safety while they work. Patrol activity sites accept it as a rally point.
|
||||
## Items, resources, and storage
|
||||
|
||||
SimNPC reads default duration and preferred-profession metadata from these
|
||||
definitions. WorldViewManager reads target type and resource-action metadata
|
||||
instead of maintaining a separate gather-action map. ActionSelectionSystem and
|
||||
SimulationManager share the same completion-cost metadata, so patrol and study
|
||||
both require one stored wood without duplicating that rule.
|
||||
`ItemDefinition` validates fields by category. Weapons require damage, reach,
|
||||
cooldown, and an equip slot; materials and consumables do not carry fake weapon
|
||||
fields. The core pack contains food, wood, herb, sword, and claw. Herb proves a
|
||||
new non-weapon item and route without a manager branch.
|
||||
|
||||
`feed_animal` is the first animal-targeted action. Its definition prefers the
|
||||
farmer profession and declares an exact one-food completion cost. Selection,
|
||||
animal target reservation, supply pickup, and completion remain separate. NPC
|
||||
care pays that definition cost from carried inventory after a real pantry
|
||||
pickup; player care pays it directly from the pantry while player inventory is
|
||||
deferred. Both paths use `AnimalCareSystem` and mutate only the exact target.
|
||||
`SimulationIds` names Dunja and Zora, their private shelter anchors, and the
|
||||
shared pasture anchor. These IDs are saved routine vocabulary; their loaded
|
||||
positions and private/shared ownership come from `AnimalRoutineSite` rather
|
||||
than entering an action definition or resource registry.
|
||||
`ResourceDefinition` owns yielded item, gather action, capability tags, base
|
||||
capacity/yield/regrowth, access policy, and presentation cue. Placement/state
|
||||
records retain unique contextual IDs and overrides such as safety risk,
|
||||
comfort, and discovery priority. Berry patches, trees, and herb patches share
|
||||
this contract.
|
||||
|
||||
## Current profession contract
|
||||
`StorageDefinition` declares accepted item IDs/tags, policy priority, capacity,
|
||||
settlement scope, deposit/withdraw actions, and presentation cue.
|
||||
`StorageRoutingPolicy` ranks compatible destinations deterministically by
|
||||
priority then stable target ID. Food-to-pantry and wood-to-woodpile remain
|
||||
covered; herb-to-apothecary proves data-only routing beyond those legacy cases.
|
||||
|
||||
Each profession definition contains a stable `profession_id`, display name,
|
||||
body color, and prop color. The current professions are farmer, woodcutter,
|
||||
guard, scholar, and wanderer.
|
||||
## Professions and capabilities
|
||||
|
||||
NPC generation chooses from the registry's stable IDs. NPC state stores and
|
||||
restores those IDs as `StringName`, and rejects records that reference an
|
||||
unknown profession or executable action.
|
||||
Each `ProfessionDefinition` contains a stable ID, display name, body color, and
|
||||
prop color. Farmer, woodcutter, guard, scholar, and wanderer are registered in
|
||||
the core pack. NPC state saves only the ID and rejects unknown definitions.
|
||||
|
||||
## Opportunity vocabulary
|
||||
`CapabilityTagDefinition` gives actions and targets a validated shared
|
||||
vocabulary. Tags express composable affordances; they do not mutate state or
|
||||
replace concrete authority checks.
|
||||
|
||||
`SimulationIds` defines the four proven opportunity types,
|
||||
`restock_empty_pantry`, `supply_missing_wood`, `feed_weak_villager`, and
|
||||
`repair_home_roof`, plus the stable `open`, `resolved`, and `invalidated`
|
||||
statuses. Invalidation reasons currently distinguish `interested_died` from
|
||||
`evidence_stale`. These are serialized vocabulary, not editor-authored quest
|
||||
definitions. Dynamic trigger, interested NPC, storage/resource goal, progress,
|
||||
exact resolution-event identity, and close reason belong to
|
||||
`OpportunityStateRecord` and `VillageOpportunitySystem`.
|
||||
## Enemies and combat
|
||||
|
||||
The shared record and lifecycle collaborator was extracted only after the
|
||||
food and wood consumers proved those fields. Their evidence, care, resolution,
|
||||
and invalidation rules remain explicit branches. `feed_weak_villager` opens on
|
||||
a `villager_weak` fact when a starving low-energy villager cannot eat and
|
||||
resolves only when that same villager actually consumes food; `repair_home_roof`
|
||||
opens on a `home_damaged` fact when a villager sleeps through low safety and
|
||||
resolves through the real wood-deposit path. Do not add a generic quest-
|
||||
definition registry until real acceptance, assignment, reward, or dialogue
|
||||
consumers establish a second shared contract.
|
||||
`EnemyDefinition` carries a behavior profile, combatant ID prefix, faction,
|
||||
hostility, weapon, health, movement, and visual parameters.
|
||||
`CombatantFactory` creates/restores every hostile and rebuilds collision-free
|
||||
per-prefix allocators. The core boar reuses the wolf-hunt behavior without a
|
||||
new manager or combat switch; raider and wolf compatibility spawn APIs delegate
|
||||
to the same factory.
|
||||
|
||||
## Player actor vocabulary
|
||||
Combatant and faction state use stable IDs. NPC combatants point to their
|
||||
person ID; hostile records persist `enemy_definition_id`. Weapons resolve
|
||||
through the same item catalog used by inventory rather than a parallel combat
|
||||
item table.
|
||||
|
||||
`SimulationIds.PLAYER_ACTOR_ID` (`-1`) is the stable event actor for
|
||||
player-performed actions, and `SimulationIds.PLAYER_INVENTORY_ID` names the
|
||||
carried-inventory holder in economic events. Player-performed pantry food
|
||||
supply is witnessed by nearby villagers and can raise their directed trust
|
||||
toward the player, with the player as a relationship subject.
|
||||
## Animals
|
||||
|
||||
## Item and weapon vocabulary
|
||||
`AnimalDefinition` + `AnimalCatalog` + `AnimalFactory` apply the same
|
||||
definition-instance-state-presentation contract to domestic animals. Goat and
|
||||
sheep reuse the `grazer_routine`, feeding capability, generic CozyGrazer scene,
|
||||
state migration, and care system; definition and visual parameters are the only
|
||||
type-specific pieces. The animal catalog remains isolated until the next
|
||||
shared content-pack migration adds that record family without destabilizing
|
||||
the already validated core pack.
|
||||
|
||||
`ItemDefinition` is the editor-readable resource contract for items, and
|
||||
`SimulationItems` is the current registry. Weapons carry `damage`, `reach`,
|
||||
and `attack_cooldown` and fill the `hand` equip slot, so the same contract can
|
||||
later host non-weapon items (food sacks, tools, armour) in a full inventory.
|
||||
The current weapons are `item_sword` (the player's equipped blade) and
|
||||
`item_claw` (wolf bites and unarmed defenders). NPC guards are equipped with
|
||||
swords; other villagers fight with claws, which feeds the village-defense
|
||||
derivation.
|
||||
## Situations and dialogue
|
||||
|
||||
## Conflict vocabulary
|
||||
Legacy `OpportunityStateRecord` vocabulary remains for save compatibility.
|
||||
New emergent content uses typed `SituationDefinition` resources: reusable
|
||||
predicates, evidence requirements, dedupe fields, priority/severity,
|
||||
alternative objectives, exact ordinary resolution patterns, expiry/cooldown,
|
||||
and dialogue topic IDs. Situation state saves the definition ID and causal
|
||||
facts; progress is re-derived from authoritative state and `WorldEventStore`.
|
||||
|
||||
`CombatantStateRecord` and `FactionStateRecord` use stable IDs. Combatant kinds
|
||||
are `npc`, `raider`, `wolf`, and `player`; NPC combatants reference their
|
||||
`SimNPC` by stable ID. Factions are `faction_village` and `faction_tribe`, with
|
||||
`neutral`/`hostile` stances and `none`/`planned`/`raiding`/`aborted` war plans.
|
||||
Combat, raid, and war narrative facts use the stable event types
|
||||
`combatant_hurt`, `combatant_killed`, `raid_started`, `war_resolved`,
|
||||
`war_aborted`, and `wolf_hunt`.
|
||||
`DialogueIntentDefinition` owns semantic preconditions, score, response intent
|
||||
IDs, template variants, and optional action metadata. Stable hashing selects a
|
||||
variant from conversation/turn/intent/topics without consuming shared RNG.
|
||||
Rendered prose and Dialogue Manager resources are presentation and never
|
||||
authoritative state.
|
||||
|
||||
## Enemy vocabulary
|
||||
## Validation and authoring report
|
||||
|
||||
`EnemyDefinition` is the data contract for hostile creatures and
|
||||
`SimulationEnemies` is the current registry. Each enemy carries a `kind`
|
||||
(raider/wolf), equipped weapon, health, move speed, body/accent colors, and a
|
||||
visual scale, so a new bear, bandit, or boar is mostly one definition plus a
|
||||
small `_build_*` visual hook on the shared `CreatureVisual` root. The current
|
||||
enemies are `enemy_raider` (sword) and `enemy_wolf` (claw).
|
||||
The catalog rejects:
|
||||
|
||||
## Validation
|
||||
|
||||
The registry rejects:
|
||||
|
||||
- missing or duplicate IDs;
|
||||
- empty display names;
|
||||
- non-positive action durations;
|
||||
- invalid target types;
|
||||
- resource actions without a resource-action ID;
|
||||
- incomplete, non-positive, or unknown completion-cost resources;
|
||||
- references to unknown professions or resource actions;
|
||||
- missing, empty, or duplicate pack/definition IDs;
|
||||
- silent cross-pack overrides;
|
||||
- unknown pack, handler, capability, item, profession, action, storage,
|
||||
behavior-profile, or presentation-cue references;
|
||||
- category-invalid item fields;
|
||||
- incomplete or non-positive costs/effects;
|
||||
- resources or storage routes with inconsistent item/action contracts;
|
||||
- definition resources that fail to load.
|
||||
|
||||
`tests/simulation_definitions_test.gd` verifies registry integrity,
|
||||
definition-backed behavior, unknown-ID rejection, and serialization
|
||||
round-tripping.
|
||||
`ContentCatalog.get_authoring_report()` exposes validity, sorted published IDs,
|
||||
and exact errors for CLI/editor tooling. Tests prove transactional failure,
|
||||
deterministic enumeration, core cross-references, boar behavior reuse, shared
|
||||
goat/sheep behavior, and herb routing.
|
||||
|
||||
## Deliberate boundary
|
||||
|
||||
Definitions currently own identity and the static metadata already proven by
|
||||
the prototype, including the patrol/study completion-cost contract. They do not
|
||||
yet own:
|
||||
Definitions own reusable static metadata, not mutable inventory, reservations,
|
||||
relationships, situation progress, entity ownership, or presentation nodes.
|
||||
Handler implementations remain bounded typed strategies. A universal
|
||||
reflection DSL, arbitrary scripts embedded in saves, and a full ECS are outside
|
||||
the contract.
|
||||
|
||||
- utility thresholds and consideration curves;
|
||||
- general preconditions beyond stored-resource completion costs;
|
||||
- completion effects;
|
||||
- interruption and failure policy;
|
||||
- reservation strategy;
|
||||
- detailed target-selection policy beyond current resource/activity/free
|
||||
metadata;
|
||||
- richer presentation hints beyond the current profession palette.
|
||||
|
||||
Selection, execution, target resolution, and visual travel are now separate
|
||||
responsibilities. The remaining concerns should move into definitions only
|
||||
when the action-system implementations prove a stable, reusable contract.
|
||||
Selection, execution, target resolution, simulation authority, and visual
|
||||
travel remain separate responsibilities. Extend definitions only after a real
|
||||
consumer proves a stable shared field; extend a handler when the mechanic itself
|
||||
is genuinely new.
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
## Current contract
|
||||
|
||||
`SimulationStateRecord` is the versioned JSON boundary for the current
|
||||
simulation. The current world schema is v14 and captures:
|
||||
simulation. The current world schema is v15 and captures:
|
||||
|
||||
- simulation seed, tick interval, tick count, clock remainder, and elapsed
|
||||
clock ticks;
|
||||
@@ -18,19 +18,25 @@ simulation. The current world schema is v14 and captures:
|
||||
and next routine tick;
|
||||
- pantry contents, carried NPC inventory, the ordered economic event stream,
|
||||
and its next stable event ID;
|
||||
- directed relationship records with familiarity, trust, and the stable event
|
||||
ID that last changed trust;
|
||||
- per-NPC known-event records that reference objective event history without
|
||||
copying it, including first-acquisition method, acquisition tick, and
|
||||
historical communicator provenance;
|
||||
- sparse directed relationship records for familiarity, trust, affection,
|
||||
respect, fear, obligation, and hostility, with the exact causal event for
|
||||
every non-neutral change;
|
||||
- player and NPC known-event records that reference objective event history
|
||||
without copying it, including acquisition source, hop count, confidence,
|
||||
salience, pin state, acquisition tick, and historical communicator
|
||||
provenance;
|
||||
- opportunity records with stable type/status, interested NPC, trigger event,
|
||||
target storage/resource/amount, exact later resolution event identity, or a
|
||||
deterministic invalidation reason and close tick;
|
||||
- world-backed situations, player journal discovery/tracking state, social
|
||||
commitments, and bounded semantic conversation acts. These records retain
|
||||
definition IDs and exact causal event references, never rendered dialogue
|
||||
prose or copied quest progress;
|
||||
- a player record holding the player-citizen's hunger, energy, health,
|
||||
downed state, and carried inventory. The player's world position remains
|
||||
presentation-owned and is intentionally not serialized;
|
||||
- combatant records (health, weapon, faction, position, hostility) for NPC
|
||||
defenders and standalone raiders/wolves;
|
||||
- combatant records (health, weapon, faction, position, hostility, and enemy
|
||||
definition ID) for NPC defenders and standalone hostile archetypes;
|
||||
- faction records (food, warriors, aggression, morale, stance, war plan) for
|
||||
the village and the hill tribe.
|
||||
|
||||
@@ -39,7 +45,7 @@ The top-level identity is:
|
||||
```json
|
||||
{
|
||||
"schema": "the_steward.simulation",
|
||||
"schema_version": 14
|
||||
"schema_version": 15
|
||||
}
|
||||
```
|
||||
|
||||
@@ -74,7 +80,9 @@ round-tripping, divergent known-event state, communicated provenance, and
|
||||
deterministic retention boundaries, and rejection of unsupported schemas.
|
||||
Active, resolved, and invalidated opportunity round-tripping, contradictory
|
||||
target state, invalid resource sources, and cross-record event references are
|
||||
covered too.
|
||||
covered too. The emergent slice additionally verifies that situation evidence,
|
||||
journal links, commitment participants/outcomes, and semantic conversation
|
||||
history survive a save between accepting and completing real work.
|
||||
|
||||
NPCStateRecord v2 adds the resolved travel destination and whether it is
|
||||
active. Nested v1 NPC records migrate explicitly with no invented active
|
||||
@@ -182,13 +190,11 @@ Communicated and ambiguous legacy facts receive a fresh retention lease at the
|
||||
saved simulation tick because their exact acquisition time was not previously
|
||||
stored. The v6 source record supplies the persisted direct-method snapshot.
|
||||
|
||||
Importance is intentionally derived rather than duplicated: a fact is
|
||||
`lasting` while it is the current trust cause for one of that knower's directed
|
||||
relationships; every other fact is `recent`. Current causal facts are protected
|
||||
so relationship state remains explainable. Each NPC keeps at most three recent
|
||||
facts, and recent facts at least one simulated day old are removed at the next
|
||||
deterministic daily-sized review. The objective event stream is never pruned by
|
||||
this rule.
|
||||
Importance combines persisted salience/pinning with current causal use. A fact
|
||||
is protected while it explains any relationship dimension, an open situation,
|
||||
journal discovery, or commitment. Unpinned ordinary memories remain bounded and
|
||||
age through deterministic reviews. The objective event stream is never pruned
|
||||
by this rule.
|
||||
|
||||
SimulationStateRecord v8 adds the top-level `opportunities` array and
|
||||
`simulation.next_opportunity_id`. The first nested `OpportunityStateRecord`
|
||||
@@ -255,6 +261,50 @@ records migrate to full health and standing. The player combatant used by the
|
||||
conflict system is derived state and is never serialized; hostile attacks
|
||||
reduce the authoritative player health through the ordered event stream.
|
||||
|
||||
SimulationStateRecord v15 adds top-level `situations`, `quest_journal`,
|
||||
`commitments`, and `conversation_history` arrays plus monotonic next-ID counters
|
||||
for each family. World schemas v1-v14 migrate to empty emergent collections and
|
||||
zero counters. On manager restore, a compatible legacy pantry opportunity can
|
||||
be imported once into the new situation system when no situation history is
|
||||
present; the two records are not independently generated substitutes for world
|
||||
state.
|
||||
|
||||
`SituationStateRecord` stores the definition and dedupe IDs, trigger event,
|
||||
stable primitive context, selected objective alternative, lifecycle, and exact
|
||||
resolution event. Live progress remains derived from the definition, ordinary
|
||||
event store, and current authoritative facts. `QuestJournalEntryStateRecord`
|
||||
stores discovery, tracking preference, selected alternative, and archive/close
|
||||
state only; it neither copies objectives nor owns progress. The player therefore
|
||||
cannot discover a journal entry until knowledge reaches them through an actual
|
||||
conversation or other ordinary knowledge path.
|
||||
|
||||
`CommitmentStateRecord` links one situation to typed debtor and creditor entity
|
||||
references, semantic terms, a deadline, lifecycle, and exact outcome event.
|
||||
Acceptance does not reserve stock or prevent other actors from resolving the
|
||||
situation. A matching outcome performed by the debtor fulfills it; another
|
||||
actor's outcome supersedes it; a still-achievable missed deadline breaks it at
|
||||
the due tick. Release remains an explicit social action. Consequence application
|
||||
is keyed by commitment/outcome identity so replay or restore cannot award it
|
||||
twice.
|
||||
|
||||
`ConversationActStateRecord` stores only a bounded semantic history: stable act
|
||||
ID, tick, typed speaker/listener references, supported intent ID, and at most
|
||||
eight topic IDs. Conversation IDs, current turns, option revisions, rendered
|
||||
templates, balloon state, and prose are transient. Reopening dialogue plans from
|
||||
current facts plus the retained semantic acts, so wording can evolve without
|
||||
changing authoritative history.
|
||||
|
||||
Nested `KnownEventStateRecord` v4 adds the player as a valid knower/source and
|
||||
records hop count, confidence, salience, and explicit pinning. Communicated
|
||||
facts remain exactly one hop from a performed or witnessed source. Nested
|
||||
`RelationshipStateRecord` v2 adds affection, respect, fear, obligation, and
|
||||
hostility, makes either player or NPC a valid endpoint, and stores a causal
|
||||
event ID for all seven dimensions. Nested `AnimalStateRecord` v3 persists an
|
||||
`animal_definition_id`; older records migrate to the goat definition. Nested
|
||||
`CombatantStateRecord` v2 persists `enemy_definition_id`; legacy hostile kinds
|
||||
map to their current raider or wolf definitions, while NPC defenders retain an
|
||||
empty enemy definition.
|
||||
|
||||
Current-schema parsing requires unique animal IDs that do not collide with
|
||||
resource or storage IDs. An animal reservation must belong to an existing NPC
|
||||
whose active feed task targets that exact animal. Every `animal_fed` event
|
||||
@@ -389,13 +439,17 @@ This phase does not yet provide:
|
||||
|
||||
- a save-slot menu, metadata, thumbnails, autosaves, or multiple profiles;
|
||||
- migrations from any historical world schema other than the explicitly
|
||||
supported v1–v10 layouts;
|
||||
- player inventory or player relationship records;
|
||||
- broader relationship dimensions, line-of-sight/hearing evidence,
|
||||
continuous or personalized memory decay, reinforcement, false beliefs, or
|
||||
multi-hop rumours;
|
||||
- generalized opportunity/quest definitions, acceptance, rewards, assignment,
|
||||
dialogue, or player-facing quest-log state;
|
||||
supported v1-v14 layouts;
|
||||
- line-of-sight/hearing evidence, personalized confidence decay,
|
||||
reinforcement, false beliefs, or multi-hop rumours;
|
||||
- the full regional situation predicate library, regional quest bounds,
|
||||
contracts beyond the first social commitment consumer, or generated
|
||||
free-form prose;
|
||||
- persistence of a currently open dialogue UI/turn. Semantic conversation
|
||||
history and commitment authority persist, while a balloon is regenerated
|
||||
after restore;
|
||||
- chunked regional saves, lazy location loading, or aggregate population
|
||||
persistence;
|
||||
- persistence for the player transform or presentation-only scene state.
|
||||
|
||||
Those features should build on this boundary rather than inventing parallel
|
||||
|
||||
Reference in New Issue
Block a user