Turn scheduler #6

New issue

Open

opened 2026-08-06 21:51:49 +00:00 by icub3d · 0 comments

icub3d commented

2026-08-06 21:51:49 +00:00

Owner

The turn scheduler — design pillar 2, "turn order is a resource". Each character has an
independent cadence driven by TurnSpeed; a fast unit acts more often, not merely
earlier.

This is the most important pure-logic component in M1. It must have no Bevy rendering
dependency and must be exhaustively tested.

Scope

A scheduler that advances a virtual clock and yields the next unit to act.
TurnSpeed drives frequency. Ties broken deterministically by an explicit rule, never
by iteration order.
Query the upcoming order without advancing it — the HUD timeline needs a lookahead.
Units entering and leaving mid-mission (spawn, death) are handled without corrupting
the schedule.

Acceptance criteria

Given a fixed set of speeds, the emitted order is asserted against a hand-computed
sequence in a unit test.
A unit with double another's speed acts approximately twice as often over a long
run — asserted, not assumed.
Ties are stable and documented.
Removing a unit mid-schedule does not change the relative order of the rest.
Lookahead matches what actually happens when the schedule is advanced.

Notes

This is a candidate for an ADR: the scheduler's shape constrains the whole combat model
and is expensive to change later. See docs/adr/0001-record-architecture-decisions.md.

The turn scheduler — design pillar 2, "turn order is a resource". Each character has an independent cadence driven by `TurnSpeed`; a fast unit acts more often, not merely earlier. This is the most important pure-logic component in M1. It must have no Bevy rendering dependency and must be exhaustively tested. ## Scope - A scheduler that advances a virtual clock and yields the next unit to act. - `TurnSpeed` drives frequency. Ties broken deterministically by an explicit rule, never by iteration order. - Query the upcoming order without advancing it — the HUD timeline needs a lookahead. - Units entering and leaving mid-mission (spawn, death) are handled without corrupting the schedule. ## Acceptance criteria - [ ] Given a fixed set of speeds, the emitted order is asserted against a hand-computed sequence in a unit test. - [ ] A unit with double another's speed acts approximately twice as often over a long run — asserted, not assumed. - [ ] Ties are stable and documented. - [ ] Removing a unit mid-schedule does not change the relative order of the rest. - [ ] Lookahead matches what actually happens when the schedule is advanced. ## Notes This is a candidate for an ADR: the scheduler's shape constrains the whole combat model and is expensive to change later. See `docs/adr/0001-record-architecture-decisions.md`.

icub3d added the

labels

2026-08-06 21:52:04 +00:00

icub3d added this to the M1 — Playable Vertical Slice milestone

2026-08-06 22:21:45 +00:00