dead-air/daisy
Watch
3
0
Fork
You've already forked daisy
 1
Code Issues 10 Pull requests Projects Releases Packages Wiki Activity Actions

Simulation scenarios for churning on the algos #8

New issue
Open
opened 2026-11-15 01:10:04 +00:00 by muse-lantern · 0 comments
muse-lantern commented 2026-11-15 01:10:04 +00:00
Member
Copy link

The plan

This repo is a prototype for simulating the process and churning on the algos. Scenarios are the workbench: each one is a headless test that sets up a world, scripts a situation, and asserts what the layers do. The scenarios are also the tactic data the future model-integration work will measure against — a model Commander is only as good as its score on these.

Current state

One scenario exists: tests/daisy_smoke_check.gd (26 checks). It stands up a Director + 2 Commanders + 3 NPCs each, scripts a silent stealth-kill (asserts the roster drops with no alert and no knowledge entry anywhere), has a second NPC find the body (asserts the Commander goes on alert and the alert flows down to the other Commander), and covers the coordination guard both ways (all on one objective warns, split objectives stay quiet).

What changes

Add scenarios one at a time, each as a headless test in tests/, each with a printed check count. The list, in the order that makes sense — each scenario lands as the issue it depends on settles:

  1. Stealth-kill silent drop — BUILT (the smoke test). The reference scenario.
  2. Fox + handlers + gunner. The worked example from the design: the Commander uses the fox for roaming, scouting, and baiting, the two light infantry stay near the fox as handlers, the heavy gunner holds a Commander-chosen smaller area. Depends on the Commander issue (role-based tasking).
  3. Multi-commander reinforcement. The Director issues "Reinforce XYZ" to one Commander — the guard stays quiet. To all Commanders — the guard fires. Then the Director redirects one Commander elsewhere and the guard clears. Depends on the Director issue.
  4. Interrupted report. An NPC finds a body and starts reporting, and is killed before the report lands. The Commander never learns, stays calm, and the ledger holds nothing. Depends on the knowledge-ledger issue (interruptible reports).
  5. Player discovered. One Commander discovers the player. The Director is aware (it knows everything its Commanders know) and puts all Commanders on alert. Depends on the Commander and Director issues.
  6. Stale knowledge. A last-seen position ages past the decay rule and stops driving behaviour. Depends on the knowledge-ledger issue (decay rules).
  7. No-Commander fallback. An unassigned NPC does the fallback behaviour; a stale order reverts. Depends on the fallback issue.
  8. Spawning. The Director (or the spawning system) reinforces a depleted team and the new unit joins the roster cleanly. Depends on the spawning issue.

What done looks like

Each scenario is a test with a check count, the smoke test stays fast, and the scenario list in this issue is kept current — a scenario is checked off here when it lands, with its test file named. Scenarios are the acceptance bar for the issues they depend on: an issue is not done until its scenario passes.

Open questions

  • Do scenarios need a 3D scene with a navmesh, or stay logic-only until the small-brain issue lands movement?
  • How is a scenario parameterized — same world with different scripts, or a fresh world per scenario?
  • Should scenarios share a helper for building worlds (Director + Commanders + teams), or does each build its own?
  • At what point does a scenario become a benchmark with a score, rather than a pass/fail test?
## The plan This repo is a prototype for simulating the process and churning on the algos. Scenarios are the workbench: each one is a headless test that sets up a world, scripts a situation, and asserts what the layers do. The scenarios are also the tactic data the future model-integration work will measure against — a model Commander is only as good as its score on these. ## Current state One scenario exists: `tests/daisy_smoke_check.gd` (26 checks). It stands up a Director + 2 Commanders + 3 NPCs each, scripts a silent stealth-kill (asserts the roster drops with no alert and no knowledge entry anywhere), has a second NPC find the body (asserts the Commander goes on alert and the alert flows down to the other Commander), and covers the coordination guard both ways (all on one objective warns, split objectives stay quiet). ## What changes Add scenarios one at a time, each as a headless test in `tests/`, each with a printed check count. The list, in the order that makes sense — each scenario lands as the issue it depends on settles: 1. **Stealth-kill silent drop** — BUILT (the smoke test). The reference scenario. 2. **Fox + handlers + gunner.** The worked example from the design: the Commander uses the fox for roaming, scouting, and baiting, the two light infantry stay near the fox as handlers, the heavy gunner holds a Commander-chosen smaller area. Depends on the Commander issue (role-based tasking). 3. **Multi-commander reinforcement.** The Director issues "Reinforce XYZ" to one Commander — the guard stays quiet. To all Commanders — the guard fires. Then the Director redirects one Commander elsewhere and the guard clears. Depends on the Director issue. 4. **Interrupted report.** An NPC finds a body and starts reporting, and is killed before the report lands. The Commander never learns, stays calm, and the ledger holds nothing. Depends on the knowledge-ledger issue (interruptible reports). 5. **Player discovered.** One Commander discovers the player. The Director is aware (it knows everything its Commanders know) and puts all Commanders on alert. Depends on the Commander and Director issues. 6. **Stale knowledge.** A last-seen position ages past the decay rule and stops driving behaviour. Depends on the knowledge-ledger issue (decay rules). 7. **No-Commander fallback.** An unassigned NPC does the fallback behaviour; a stale order reverts. Depends on the fallback issue. 8. **Spawning.** The Director (or the spawning system) reinforces a depleted team and the new unit joins the roster cleanly. Depends on the spawning issue. ## What done looks like Each scenario is a test with a check count, the smoke test stays fast, and the scenario list in this issue is kept current — a scenario is checked off here when it lands, with its test file named. Scenarios are the acceptance bar for the issues they depend on: an issue is not done until its scenario passes. ## Open questions - Do scenarios need a 3D scene with a navmesh, or stay logic-only until the small-brain issue lands movement? - How is a scenario parameterized — same world with different scripts, or a fresh world per scenario? - Should scenarios share a helper for building worlds (Director + Commanders + teams), or does each build its own? - At what point does a scenario become a benchmark with a score, rather than a pass/fail test?
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
No results found.
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
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#8
No description provided.