Spawning / reinforcement ownership #9

New issue

Open

opened 2026-11-15 01:10:07 +00:00 by muse-lantern · 0 comments

muse-lantern commented

2026-11-15 01:10:07 +00:00

Member

The plan

Somebody has to decide when new NPCs appear and which team they join. The design doc leaves open whether that is the Director's job or a separate system the Director only calls on. This issue settles the ownership, defines the interface, and builds the minimal version. It depends on the Director issue — spawning plugs into whatever shape the Director settles into.

Current state

Nothing. No spawning code exists anywhere in the repo; rosters are built by hand in the test (_build_world in tests/daisy_smoke_check.gd creates NPCs and adds them to Commanders directly). There is no concept of a reinforcement pool, a population budget, or a respawn timer.

What changes

Settle ownership and build the minimal version, in order:

Decide ownership. Two shapes: the Director owns spawning (it runs the base and its forces, so it manages the pools directly), or a separate system owns it and the Director only calls on it (request N units of type T at location L; the system fulfills or refuses). The considerations: spawning is about resources — how many units exist, where they come from, respawn timers — which is a different concern from tactics. The Director already knows the base and the union, which argues for Director-owned; the resource concern argues for separate. Decide and record the reasoning here.
Define the interface. Whichever shape wins, write the call: what the request carries (unit type, count, destination Commander, spawn position), what the answer carries (the spawned units, or a refusal with a reason), and what happens on refusal (the Director re-plans? waits? does without?).
Implement the minimal version. Spawn a unit into a Commander's roster at a position. The spawned unit starts with the settled fallback behaviour (see the fallback issue) until the Commander orders it — it must never spawn already knowing something it has not perceived.
Respect the bounded-knowledge rule. A spawned unit is roster knowledge, not player knowledge: the Commander knows it has a new unit, but the unit itself knows nothing until it perceives something. Write this as a test — a freshly spawned NPC's ledger contribution is empty.
Tests. Spawn into a roster, spawn refusal when the pool is empty (if pools exist), spawned unit starts clean and takes orders normally.

What done looks like

Ownership decided with reasoning recorded, the interface defined, the minimal spawn working and tested, and the design doc updated. Population budgets and respawn timers are follow-ups only if the ownership decision needs them — they are not smuggled into this issue.

Open questions

Ownership: Director, or a separate system the Director calls on?
Population budgets: does a base have a finite pool, or can it spawn indefinitely?
Respawn timers: does a lost unit come back on a clock, or only when the Director requests it?
Spawn positions: fixed spawn points, or anywhere the Director chooses?
Does the player ever see spawning happen, or does it always happen off-stage?

## The plan Somebody has to decide when new NPCs appear and which team they join. The design doc leaves open whether that is the Director's job or a separate system the Director only calls on. This issue settles the ownership, defines the interface, and builds the minimal version. It depends on the Director issue — spawning plugs into whatever shape the Director settles into. ## Current state Nothing. No spawning code exists anywhere in the repo; rosters are built by hand in the test (`_build_world` in `tests/daisy_smoke_check.gd` creates NPCs and adds them to Commanders directly). There is no concept of a reinforcement pool, a population budget, or a respawn timer. ## What changes Settle ownership and build the minimal version, in order: 1. **Decide ownership.** Two shapes: the Director owns spawning (it runs the base and its forces, so it manages the pools directly), or a separate system owns it and the Director only calls on it (request N units of type T at location L; the system fulfills or refuses). The considerations: spawning is about resources — how many units exist, where they come from, respawn timers — which is a different concern from tactics. The Director already knows the base and the union, which argues for Director-owned; the resource concern argues for separate. Decide and record the reasoning here. 2. **Define the interface.** Whichever shape wins, write the call: what the request carries (unit type, count, destination Commander, spawn position), what the answer carries (the spawned units, or a refusal with a reason), and what happens on refusal (the Director re-plans? waits? does without?). 3. **Implement the minimal version.** Spawn a unit into a Commander's roster at a position. The spawned unit starts with the settled fallback behaviour (see the fallback issue) until the Commander orders it — it must never spawn already knowing something it has not perceived. 4. **Respect the bounded-knowledge rule.** A spawned unit is roster knowledge, not player knowledge: the Commander knows it has a new unit, but the unit itself knows nothing until it perceives something. Write this as a test — a freshly spawned NPC's ledger contribution is empty. 5. **Tests.** Spawn into a roster, spawn refusal when the pool is empty (if pools exist), spawned unit starts clean and takes orders normally. ## What done looks like Ownership decided with reasoning recorded, the interface defined, the minimal spawn working and tested, and the design doc updated. Population budgets and respawn timers are follow-ups only if the ownership decision needs them — they are not smuggled into this issue. ## Open questions - Ownership: Director, or a separate system the Director calls on? - Population budgets: does a base have a finite pool, or can it spawn indefinitely? - Respawn timers: does a lost unit come back on a clock, or only when the Director requests it? - Spawn positions: fixed spawn points, or anywhere the Director chooses? - Does the player ever see spawning happen, or does it always happen off-stage?

muse-lantern referenced this issue

2026-11-15 01:10:25 +00:00

Build sequence: code first, then model integration #11

No labels

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference

dead-air/daisy#9

No description provided.

Rows
Columns