Runtime
The Runtime is Typhon's game-server execution layer: a DAG-scheduled, multi-threaded tick loop that dispatches developer-defined systems against the ECS data layer and automates their UoW/Transaction lifecycle. Systems declare phase and read/write access so the scheduler derives safe parallel execution automatically, scope dispatch to spatial simulation tiers, and skip entirely when nothing relevant changed. An overload detector and always-on per-tick telemetry let the server degrade gracefully under a load spike — throttling systems, slowing the tick rate, or signalling game code to shed load — instead of falling over.
🔬 Recommended: read in-depth-overview/10-runtime.md (Chapter 10: Runtime) first to understand the overall design and concepts behind this category, before diving into the specific features below.
Public Features
| Feature | Summary | Status | Level |
|---|---|---|---|
| Tick-Based Execution Engine | TyphonRuntime — the top-level host that owns the tick loop, creates one UoW per tick and one Transaction per system automatically, and drives startup/crash-recovery/shutdown |
✅ Implemented | 🔵 Core |
|   ↳ Execution Modes | Today: a fixed-timestep tick loop plus a single-threaded debug variant; event-driven and hybrid request/response modes are designed but not yet built | 🚧 Partial | 🟣 Advanced |
|   ↳ Worker Pool & Threading Model | Core allocation between a dedicated tick-metronome thread and a worker pool that executes the system DAG in parallel | ✅ Implemented | 🟣 Advanced |
|   ↳ Parallel Tick Fence | Spreads the post-tick WriteTickFence step (cluster migrations, AABB refresh, WAL publish) across the worker pool instead of running it on one thread — tuned via RuntimeOptions |
✅ Implemented | 🟣 Advanced |
| Declarative System Scheduling (Track → DAG → Phase, Auto-DAG) | Systems declare per-component read/write access and a DAG-local phase; the scheduler auto-derives execution edges and rejects unsafe write/write or stale-read conflicts at Build() |
✅ Implemented | 🔵 Core |
| System Types | Five system base classes a developer picks per piece of game logic — proactive callbacks, reactive entity queries, chunk-parallel non-entity work, multi-stage pipelines, and sub-system grouping | ✅ Implemented | 🔵 Core |
|   ↳ CallbackSystem | Proactive system that runs every tick for non-entity work — timers, input draining, global state | ✅ Implemented | 🔵 Core |
|   ↳ QuerySystem | Reactive per-entity system that auto-skips when nothing relevant changed, with optional automatic multi-core chunking | ✅ Implemented | 🔵 Core |
|   ↳ ChunkedCallbackSystem | Fan a CallbackSystem's body out across N workers for SIMD sweeps, reductions, and other non-entity chunkable work | ✅ Implemented | 🟣 Advanced |
|   ↳ PipelineSystem | Reactive multi-stage gather/process/scatter system for bulk entity processing — full execution model pending Patate | ✅ Implemented (chunk-dispatch only) | 🟣 Advanced |
|   ↳ CompoundSystem | Group related sub-systems' registration under one Configure call — one node from the outside, parallel inside |
✅ Implemented | 🟣 Advanced |
| Parallel Entity Processing (QuerySystem.Parallel) | Automatic multi-core chunking with a reusable PointInTimeAccessor (no per-chunk Transaction for non-Versioned writes) across four dispatch paths selected by Versioned-write × change-filter |
✅ Implemented | 🟣 Advanced |
| Reactive Dispatch: Change Filters & Run Conditions | changeFilter limits a system's entity set to dirty ∪ Added by piggybacking on the View's ring buffer; shouldRun gives a zero-cost proactive skip predicate evaluated before any input work |
✅ Implemented | 🟣 Advanced |
| Typed Event Queues | Single-producer ring-buffer queues for inter-system signalling within a tick, enabling reactive cascade chains that early-out cheaply when dormant | ✅ Implemented | 🟣 Advanced |
| Side-Transactions for Immediate Durability | Per-tick CreateSideTransaction(Immediate) lets a system commit economy-critical writes durably mid-tick, independent of and invisible to the main tick UoW's snapshot |
✅ Implemented | 🟣 Advanced |
| Overload Management | Single-writer overload state machine that escalates/de-escalates through system throttling and tick-rate modulation (TiDi, up to 6x) and fires a critical-overload callback for game-decided player shedding | 🚧 Partial | 🟣 Advanced |
| Telemetry & Runtime Inspection | Always-on, zero-allocation ring buffer of per-tick/per-system telemetry inspectable from game code; a pluggable IRuntimeInspector hook for remote tooling is designed but not implemented |
🚧 Partial | 🟣 Advanced |
| Spatial Tiers & Adaptive Dispatch | Per-cluster simulation tiers let systems process near entities every tick and far entities at reduced/amortized/dormant rates, scoping dispatch automatically to the matching clusters | ✅ Implemented | 🟣 Advanced |
|   ↳ Tier-Filtered & Amortized Dispatch | Scope a system to clusters in matching tier cells, and optionally process just 1/N of them per tick | ✅ Implemented | 🟣 Advanced |
|   ↳ Cluster Dormancy (Sleep/Wake) | Clusters untouched for N ticks sleep and are skipped by every dispatch path, waking within one tick of being written to | ✅ Implemented | 🟣 Advanced |
|   ↳ Checkerboard (Red/Black) Dispatch | Two-phase Red/Black parallel dispatch so neighbor-touching systems never race across a cell boundary | ✅ Implemented | 🟣 Advanced |
| Data-Driven Timers / Scheduled Entities | Documented pattern for modeling respawns/expiries as entities with a time-of-expiry component and a CallbackSystem poll; no built-in timer/scheduling infrastructure exists yet |
📋 Planned | 🟣 Advanced |
Internal Features
No internal-only engine machinery documented separately in this category — every feature file above is directly reached from application code (TyphonRuntime, SystemBuilder, TickContext, RuntimeOptions, Transaction). The DAG deriver, overload detector, dormancy reporter, and access validator that back these features are implementation detail behind them, not separately catalogued.