Commander: team tactics + environment knowledge + alerts #5

New issue

Open

opened 2026-11-15 01:09:58 +00:00 by muse-lantern · 0 comments

muse-lantern commented

2026-11-15 01:09:58 +00:00

Member

The plan

The Commander is the small picture, this moment: one team, its tactics, its knowledge. It runs a team of NPCEntities, works from what its NPCs know plus its local environment knowledge, executes the Director's objectives by deciding HOW, and owns the alert state of its team. This issue turns the spine's Commander into a tactician. It depends on the order-vocabulary issue (what it can order) and the knowledge-ledger issue (what its ledger means).

Current state

addons/daisy/src/commander.gd has the spine: roster, knowledge_ledger, environment_knowledge (a Dictionary that nothing writes to yet), alert_level with two rungs (ALERT_CALM, ALERT_ALERTED), issue_order (vocabulary-gated), receive_objective (translates reinforce into move_to orders for every living unit), on_npc_lost (the silent drop — no entry, no alert), on_body_found (writes unit_lost, raises the alert, tells the Director), and set_alert (pushes the level to the team). The worked example from the design — fox scouting and baiting, two light infantry as handlers, heavy gunner holding a smaller area — is not implemented anywhere.

What changes

Build the Commander, in order:

Role-based tasking. The worked example is the spec: the Commander assigns roles and positions to the team, not just a single target. Decide how roles are assigned — by NPC type (a fox scouts, a gunner holds), or by explicit role assignment the Commander makes per situation? Implement the fox + two handlers + gunner team as the first role assignment: fox roams/scouts/baits, infantry stay near the fox, gunner holds a Commander-chosen position.
Environment knowledge. Settle what goes in environment_knowledge and how it is authored: turf, local layout, positions that matter — chokepoints, cover, hold positions, patrol routes. Authoring is per-Commander configuration, not per-NPC. And the hard rule stands: environment knowledge is about the environment, never about live NPC status — it must never tell the Commander a patrol went missing. Write the rule as a test: no entry in environment_knowledge may reference a roster member's live state.
Alert ladder. Two rungs are not a ladder. Settle the rungs — the design's stealth games suggest calm, suspicious, searching, alerted — and what triggers each rung and what each rung changes: patrol patterns, reporting eagerness, whether the team investigates or holds. A found body jumps the ladder; a heard noise climbs it one rung; a long quiet period descends it.
Body-discovery chain. The spine has the endpoints (finder reports, Commander alerts, Director notified). Fill in the middle: the finder must report (see the knowledge issue's interruptible report — if the finder dies before reporting, the Commander stays calm), and the alert must reach the Director only via that report, never by any other path.
Cadence. The Commander re-plans on a fast cadence — real time, small state. Decide the tick: event-driven, periodic, or both? A decision model would drive this layer at roughly one to two seconds per team; the heuristic tick should be shaped so a model can replace it without changing the cadence.
Tests. The fox/handlers/gunner example runs as a scenario; the alert ladder climbs and descends per its triggers; environment knowledge contains no live NPC status; a finder killed before reporting leaves the Commander calm.

What done looks like

A Commander assigns roles per the worked example, climbs and descends the settled alert ladder, works from authored environment knowledge that contains no live NPC status, and re-plans on the settled cadence — each proven by a test. The design doc's Commander section matches.

Open questions

Role assignment — by NPC type, or explicit per-situation assignment by the Commander?
How is environment knowledge authored — per-Commander config files, per-base data, or in code?
Alert ladder: which rungs, what triggers each, what does each rung change?
Commander tick cadence — event-driven, periodic, or both, and at what interval?
What does the Commander report upward besides alerts — anything, or is the ledger the only channel?

## The plan The Commander is the small picture, this moment: one team, its tactics, its knowledge. It runs a team of NPCEntities, works from what its NPCs know plus its local environment knowledge, executes the Director's objectives by deciding HOW, and owns the alert state of its team. This issue turns the spine's Commander into a tactician. It depends on the order-vocabulary issue (what it can order) and the knowledge-ledger issue (what its ledger means). ## Current state `addons/daisy/src/commander.gd` has the spine: `roster`, `knowledge_ledger`, `environment_knowledge` (a Dictionary that nothing writes to yet), `alert_level` with two rungs (`ALERT_CALM`, `ALERT_ALERTED`), `issue_order` (vocabulary-gated), `receive_objective` (translates `reinforce` into `move_to` orders for every living unit), `on_npc_lost` (the silent drop — no entry, no alert), `on_body_found` (writes `unit_lost`, raises the alert, tells the Director), and `set_alert` (pushes the level to the team). The worked example from the design — fox scouting and baiting, two light infantry as handlers, heavy gunner holding a smaller area — is not implemented anywhere. ## What changes Build the Commander, in order: 1. **Role-based tasking.** The worked example is the spec: the Commander assigns roles and positions to the team, not just a single target. Decide how roles are assigned — by NPC type (a fox scouts, a gunner holds), or by explicit role assignment the Commander makes per situation? Implement the fox + two handlers + gunner team as the first role assignment: fox roams/scouts/baits, infantry stay near the fox, gunner holds a Commander-chosen position. 2. **Environment knowledge.** Settle what goes in `environment_knowledge` and how it is authored: turf, local layout, positions that matter — chokepoints, cover, hold positions, patrol routes. Authoring is per-Commander configuration, not per-NPC. And the hard rule stands: environment knowledge is about the environment, never about live NPC status — it must never tell the Commander a patrol went missing. Write the rule as a test: no entry in `environment_knowledge` may reference a roster member's live state. 3. **Alert ladder.** Two rungs are not a ladder. Settle the rungs — the design's stealth games suggest calm, suspicious, searching, alerted — and what triggers each rung and what each rung changes: patrol patterns, reporting eagerness, whether the team investigates or holds. A found body jumps the ladder; a heard noise climbs it one rung; a long quiet period descends it. 4. **Body-discovery chain.** The spine has the endpoints (finder reports, Commander alerts, Director notified). Fill in the middle: the finder must report (see the knowledge issue's interruptible report — if the finder dies before reporting, the Commander stays calm), and the alert must reach the Director only via that report, never by any other path. 5. **Cadence.** The Commander re-plans on a fast cadence — real time, small state. Decide the tick: event-driven, periodic, or both? A decision model would drive this layer at roughly one to two seconds per team; the heuristic tick should be shaped so a model can replace it without changing the cadence. 6. **Tests.** The fox/handlers/gunner example runs as a scenario; the alert ladder climbs and descends per its triggers; environment knowledge contains no live NPC status; a finder killed before reporting leaves the Commander calm. ## What done looks like A Commander assigns roles per the worked example, climbs and descends the settled alert ladder, works from authored environment knowledge that contains no live NPC status, and re-plans on the settled cadence — each proven by a test. The design doc's Commander section matches. ## Open questions - Role assignment — by NPC type, or explicit per-situation assignment by the Commander? - How is environment knowledge authored — per-Commander config files, per-base data, or in code? - Alert ladder: which rungs, what triggers each, what does each rung change? - Commander tick cadence — event-driven, periodic, or both, and at what interval? - What does the Commander report upward besides alerts — anything, or is the ledger the only channel?

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#5

No description provided.

Rows
Columns