---
id: server-architecture/001
title: Field-simulation scaling memo
epic: server-architecture
state: done
priority: 1
blocked_by: []
estimate: M
created: 2026-08-05
updated: 2026-08-02
claimed_by: null
claimed_at: null
delivers: []
review_artifact: null
---

## Resolution (2026-08-02)

**Superseded, not written as originally scoped.** A direct architecture conversation answered the question this memo was meant to survey, without the memo itself ever getting written: **fields are now unlikely to survive into the final design** in their original per-cell-diffusion form. The actual scaling constraint this project faces turned out to be pathfinding (hundreds of creatures converging on a handful of targets), not field diffusion — solved with flow fields/Dijkstra maps, not a field-scaling technique from this task's original survey list (chunking / update-on-change / coarser resolution). Sensing (a creature noticing a hoard, a scent radius) is preserved without diffusion via spatial-hash emitter queries instead.

Full decision recorded in `server-architecture/overview.md`'s "Pathfinding and sensing" and "Netcode" sections — read that, not this note, for the actual architecture. This task is closed because the question is answered, not because the original memo was produced.

## What to do

Write a short architecture memo surveying how the four field layers (Charge, Heat, Tempo, Boundary — `land-of-lor/docs/README.md` §5) can be simulated without naive per-cell diffusion, which the docs already flag as "the first real engineering constraint" (§13). Survey at least: chunking (only simulate loaded regions), update-on-change (propagate only from cells whose value actually changed this tick), and coarser field resolution than the item grid (fields as a lower-resolution overlay). Weigh them against this project's actual needs — collaborative terraforming and shared field state during battle arenas (`battle-arena-poc`) — not a hypothetical MMO scale.

## Definition of done

A memo (add it under `land-of-lor/docs/` or as this task's own follow-up content — author's choice, note where it landed) that: describes each approach in a paragraph, gives an honest trade-off table, and ends with a recommendation. This is research/writing, not implementation — no code, no engine chosen yet.

## Where the work lands

`land-of-lor` repo (the memo becomes a doc there, per that repo's own docs/ conventions).

## Docs to read first

`land-of-lor/docs/README.md` §5 (fields), §13 (this exact open engineering flag); `land-of-lor/docs/thought-specs/battle-areans-and-element-types.md` (the ley-lines vision that implies real-time shared field state during a live match — the concrete case this scaling approach has to handle).