UNI-X.
Who owns this part of the map?
UNI-X turns running paths into territory claims. It stores ownership, handles captures and enclosed ground, and prepares shapes for the map.
Led territory engineering within Runiverse, working with co-founders and AI tools.
Less storage.
Same ground.
A simplified cell specimen: combine a fully owned group, then capture only part of it.
Seven children, one owner
Every child in this simplified group belongs to the same owner. There is an opportunity to store the complete group as its parent.
illustrative ownership records
Toggle the seam to see why a processing boundary should not become an ownership border. Hexagons show the idea, not exact H3 geometry.
Keeping the edges
that matter.
Historical synthetic geometry timings. Separate from app response time.
Node 22 · 512 MB heap cap · unrecorded development hardware. Approximate cell counts. A historical experiment, not a current benchmark.
One cell can stand for many.
UNI-X uses H3 cells at different sizes. Combining a fully owned group into a larger parent reduces stored rows. After that, a reader cannot look only for the smallest cells: apparently empty ground might belong to a larger parent.
When another runner crosses part of that ground, the engine expands the affected parent, transfers the captured children, and preserves the previous owner's untouched area.
One location, two owners.
An integrity scan found coarse and fine cells claiming the same ground for different owners. Part of the problem came from a resolution field that disagreed with the cell ID. A deletion could target a different key from the row that actually existed.
The repair uses the cell ID to determine its real size and the stored resolution to remove the old row. A successful request alone would not have revealed the ownership conflict.
The border had the same owner on both sides.
The rendering approach moved from individual cells to dissolved owner shapes, then to baking geometry in zones. Zones made one problem easier and introduced another: when one player's area crossed a zone boundary, separate dissolves drew a line through the same owner's territory.
We moved the usual export path to global, per-owner geometry published through Mapbox. The custom dissolve stayed. Publishing is manual, so the visible map can lag behind ownership updates. A budget-driven split fallback can still introduce internal outlines in large cases.
The first suspect was wrong.
A Redis investigation initially pointed at retained zone geometry. The maintenance report pointed to completed jobs holding large arrays the worker only needed to count. We changed new payloads to counts and kept older jobs readable.
The original cleanup approach then failed on the memory-limited instance it was meant to clean. The cleanup sequence changed too. The documented result is a corrected diagnosis and implementation; a measured post-fix saving has not been established.
Keeping the edges that matter
Our custom dissolve drops shared interior edges and joins the remaining boundaries into rings. In a historical synthetic test at roughly 20,000 cells, it took 137 ms for a solid shape and 268 ms for a scattered one. At roughly 150,000 cells, the same cases took 1.0 s and 2.5 s.
Measured under Node 22 with a 512 MB heap cap on unrecorded development hardware. These numbers describe geometry generation, not app response time.
Things the work
taught me.
A green response is not a correct answer.
One ownership conflict took an integrity scan to find. The request alone looked successful.
The border matters to the person looking at it.
A technical shortcut drew a line where one owner should have seen continuous territory.