Table of Contents

Spatial tiers & adaptive dispatch

In one line: run systems at full rate near, reduced rate far — per spatial cell, at cluster granularity, so the cost of tiering scales with active clusters, never entity count.

A large world can't simulate every entity at full frequency, and a per-entity distance check every tick is itself O(N). Instead, game code assigns one of four SimTier flags (Tier0..Tier3) to each spatial grid cell once per tick (via TickContext.SpatialGrid), and the engine builds — at tick start, skipped when nothing changed — a per-archetype index of active clusters grouped by tier. Three composable mechanisms read it: a system's Tier(...) filter restricts it to matching clusters (with CellAmortize(N) to process only 1/N of them per tick); Checkerboard() splits a tier-filtered set into two conflict-free Red/Black phases for systems that touch neighboring cells; and cluster dormancy puts clusters untouched for N ticks to sleep, dropping them from every dispatch path at zero cost until a write wakes them.

All three compose, engine-managed — a system can be tier-filtered, amortized, and checkerboard-dispatched at once, with dormancy filtering underneath. The trade is one tick of staleness: a tier change, a migration, or a wake takes effect at the next tick's dispatch.

How it relates

  • Cluster storage — tiers operate on cluster lists, not entities; this is why cost is O(active clusters).
  • Spatial index — the grid whose cells carry the SimTier assignment.
  • TickContext — where you assign tiers (SpatialGrid) and read TierBudgetMetrics.
  • System — the Tier / CellAmortize / Checkerboard filters are declared on it.

In the API

Learn & use

Edit this page