Clock and simulation time

SimClock

Kind	Engine infrastructure (not toggleable)
Project	NextIteration.Engine/SimClock.cs
Exposes	world_time on the World node; TickContext.WorldTime/TicksPerDay/PerTick/Hours/Days
Consumes	the tick number, ticks_per_day
Consumed by	every system with a rate; DayNightSystem; the viewer (world time); the trace (timestamps)
Status	designed · Phase 1 (#29)
PLAN	§5.5, §11.4
Player	Time

One constant defines the clock: ticks_per_day, on the World node, default 200 (one tick ≈ 7.2 sim-minutes). Everything else derives from it.

Unit	Ticks at default
hour	8.3
day	200
week	1,400
season (90 days)	18,000
year	73,000

The engine owns world_time

SimClock computes world_time = tick × 1440 / ticks_per_day (sim-minutes, int) and writes it to the World node before the Environment phase. No system advances it — DayNightSystem used to, in an earlier draft, and that made time stop when the sun was toggled off. A player action that sets world_time or ticks_per_day is rejected (PLAN §13.3). ctx.WorldTime is the same value for systems; the viewer and the narrator derive morning of day 3 from it and never show a tick.

Rates: the unit is in the key

Templates, settings, rules and attributes store sim-time values with the unit in the key: hunger_rate_per_day: 100, regrow_per_day: 80, lifespan_years: 64, fact_refresh_hours: 1, equilibration_per_hour: 0.17. Data files may write strings — "100/day", "3 hours", "60 ± 15 years" — which the loader parses into the key's unit and rejects on mismatch (grammar on Data files). Nothing is converted to ticks at load; a per-tick number on the graph would read as nonsense in the Studio and bind a save to one clock.

Systems convert at the point of use:

yield return new DeltaAttributeIntent(npc, "hunger", ctx.PerTick(s.HungerRatePerDay));
if (ctx.WorldTime - hotSince >= ctx.Hours(3)) …
var k = s.EquilibrationPerHour / ctx.Hours(1);

scripts/check-rates.sh greps data and systems for per-tick literals.

Three tiers (for later phases)

Detailed (fixed tick, every system — Phase 1), Background (an area ticks every N ticks with rates scaled — Scale phase), History (one coarse tick = a year — Worldgen phase). Long-horizon processes read world_time, so they behave the same in any tier.

History

Phase	Change
1	Introduced: engine-owned world_time, unit-in-the-key rates converted at use, PerTick.

See also

DayNightSystem · Tick pipeline and systems · Data files and the rate grammar