Tick-rate / real-time-vs-lazy-evaluation memo

done priority 3 estimate S

server-architecture/003 · created 2026-08-05 · updated 2026-08-02

Resolution (2026-08-02)

Decided, not written as originally scoped. A direct architecture conversation settled concrete tick rates without the survey memo ever getting written: simulation at 20 Hz, network snapshots to clients at 10 Hz (with ~100 ms client-side interpolation), field diffusion at 2–5 Hz if fields survive at all (they mostly don’t — see task 001’s resolution). The lazy-evaluation half of this task’s original question is answered more fundamentally than “which systems can skip ticks while unwatched”: an empty world is a frozen world — no simulation runs at all while a world has zero players in it, so there’s no “far-off unvisited region ticking slowly” case to design for; there’s simply no ticking until someone’s there.

Full decision recorded in server-architecture/overview.md’s “Netcode” and “Persistence” sections — read that, not this note, for the actual architecture.

What to do

Survey how much of the simulation genuinely needs a fixed real-time tick versus can be lazily evaluated (e.g. only recompute a region’s fields when a player is actually nearby — per overview.md’s open question). This bears directly on both hosting cost (server-instance) and on how “alive” the world feels when nobody’s watching a given region.

Definition of done

A short memo: which systems need true real-time ticking (e.g. an active battle arena) versus which can be computed on-demand/lazily (e.g. a far-off, unvisited region’s slow terraforming). End with a recommended default tick strategy — a starting point for server-instance’s environment planning, not a locked-in architecture.

Where the work lands

land-of-lor repo.

Docs to read first

land-of-lor/docs/README.md §5 (fields), §7 (changing lines — the aging mechanism this tick strategy has to serve); this epic’s task 001 (scaling approach) for consistency.

View source in repository · also available as raw markdown.