docs: define emergent world architecture
This commit is contained in:
@@ -77,6 +77,47 @@ Preserve the simulation/presentation boundary.
|
||||
When adding a system, first prove the contract with one real gameplay use case.
|
||||
Do not extract generic frameworks before multiple real consumers justify them.
|
||||
|
||||
## Emergent-world doctrine
|
||||
|
||||
The game world is the source of narrative truth. Dialogue, tasks, quests, and
|
||||
visible happenings must arise from ordinary simulation state and events rather
|
||||
than maintaining parallel scripted copies.
|
||||
|
||||
- Keep immutable definitions, authored instance placement, mutable state,
|
||||
systems, and presentation as separate layers.
|
||||
- Persist stable IDs and primitive data only. Saved state must never contain
|
||||
scripts, nodes, `NodePath`s, callables, or resource paths.
|
||||
- Mutate authoritative state before recording the fact that describes the
|
||||
mutation. Facts may reference exact causes; they may not stand in for a
|
||||
missing world change.
|
||||
- Treat dialogue prose as presentation. Semantic intents, selected response
|
||||
IDs, action commands, commitments, and their causal world events are the
|
||||
authoritative contract.
|
||||
- Treat quests as player-facing projections of real unresolved situations.
|
||||
Never create quest-only enemies, items, damage, relationships, resources, or
|
||||
completion facts.
|
||||
- Route player and NPC interactions through the same authoritative action and
|
||||
capability contracts. Presentation can suggest or submit a command, but the
|
||||
simulation must revalidate it.
|
||||
- Loaded visuals must not decide whether travel, work, growth, or distant
|
||||
conflict completes. Presentation interpolates authoritative state and may
|
||||
report local feasibility or obstruction.
|
||||
- Every generated action, situation, helper, dialogue intent, or consequence
|
||||
must expose a concise reason trace with the definition and causal fact IDs
|
||||
that justified it.
|
||||
- “Data-only content” means new combinations of existing typed predicates,
|
||||
capabilities, effects, behavior profiles, and presentation cues. A genuinely
|
||||
new mechanic adds one bounded reusable handler and tests; it does not add one
|
||||
script per item, creature, quest, or conversation.
|
||||
- Prefer typed Godot resources, composition, deterministic registries, and
|
||||
explicit strategy handlers. Do not introduce a universal reflection DSL or
|
||||
rewrite the project as a full ECS.
|
||||
|
||||
The intended extension path is therefore definition plus content pack, optional
|
||||
presentation cue, and authored placement or simulation spawn. A berry, bear,
|
||||
caravan, shortage, or conversation topic should reuse the same state, action,
|
||||
event, and presentation contracts that existing content uses.
|
||||
|
||||
## Resource and target rules
|
||||
|
||||
Do not reintroduce abstract food/wood task-zone fallbacks.
|
||||
|
||||
Reference in New Issue
Block a user