I Built a Real-Time Zombie Outbreak Simulator Using Uber’s H3 Spatial Index and Web Workers

There are two kinds of developers in this world:

1.Those who build practical, enterprise-grade, high-value CRUD applications.
2.Those who spend their weekends writing heavily optimized mathematical simulations calculating exactly how fast an army of fast-moving zombies would turn the city of London into an absolute buffet.

I fall squarely into the second camp.

I wanted to build a web-based, interactive zombie apocalypse simulator capable of handling thousands of distinct geographical zones in real-time at 60 FPS. No abstractions, no random generic circles expanding on a flat canvas—I wanted real-world city structures, actual road networks, weather vectors (wind directions), population densities, and dynamic 3D building reveals. Here is an engineering breakdown of how I combined Uber’s H3 Hexagonal Hierarchical Spatial Index, a custom SIZD mathematical epidemiological model, Web Workers for concurrent crunching, and an A road-network search algorithm* to build a highly responsive apocalypse sandbox.

The Core System Architecture: Separation of Church and Slaughter

If you try to run complex mathematical simulations for thousands of map coordinates directly on the browser's main UI thread, your application will freeze up faster than a civilian cornered by a zombie horde.To keep the UI running at a buttery-smooth 60 FPS, the app splits responsibilities cleanly between two distinct architecture layers:

┌────────────────────────────────────────────────────────┐
│               MAIN UI THREAD (Angular)                 │
│  - MapLibre GL Layer rendering & 3D Extrusions         │
│  - RequestAnimationFrame loops for particle tracers    │
├────────────────────────────────────────────────────────┤
                            │  ▲
        Worker Messages:    │  │ Worker Responses:
        { type: 'TICK' }    │  │ { type: 'TICK_RESULT', payload: ... }
                            ▼  │
┌────────────────────────────────────────────────────────┐
│            BACKGROUND WEB WORKER (TS)                  │
│  - Seeded Mulberry32 Pseudo-Random Number Generator    │
│  - Cellular H3 Neighborhood Math (gridDisk, gridRing)   │
│  - SIZD Differential Equations for cell metrics        │
└────────────────────────────────────────────────────────┘

The background Web Worker manages the complete state of the simulation grid inside a lightweight Map layout (let grid: Map<string, SimCell>), processes data slices incrementally, and posts only lightweight updates back to the UI thread.

Deep-Dive Code Breakdown

Let's tear open the chest cavity of the code and analyze the exact algorithms and mathematics driving this apocalypse.
1. The Math Under the Hood: The SIZD Model

Traditional pandemic tracking models use the classic SIR Model (Susceptible, Infected, Recovered). But since zombies don't exactly "recover," we had to upgrade this to a custom SIZD Model inside calculations-worker.ts:

-Susceptible (Healthy civilians)

-Infected (Bitten, incubating, panicking)

-Zombie (Reanimated, hungry)

-Dead (Fully neutralized or consumed)

Every single cell on the map runs differential equation steps on every clock tick. Here is how the worker evaluates state transitions per cell:

const VARIANT_PARAMS: Record<ZombieVariant, VariantParams> = {
  standard: {
    gamma: 0.16, delta: 0.025, mu: 0.05, betaMult: 1.0,
    seedZombiePct: 0.06, seedInfectedPct: 0.12,
    pzZombiePct:   0.20, pzInfectedPct:   0.10,
  },
  fast: {
    gamma: 0.26, delta: 0.010, mu: 0.08, betaMult: 1.3,
    seedZombiePct: 0.08, seedInfectedPct: 0.15,
    pzZombiePct:   0.25, pzInfectedPct:   0.12,
  },
  horde: {
    gamma: 0.32, delta: 0.006, mu: 0.10, betaMult: 1.7,
    seedZombiePct: 0.14, seedInfectedPct: 0.22,
    pzZombiePct:   0.30, pzInfectedPct:   0.15,
  },
};

gamma dictates the speed at which an Infected person turns into an active Zombie. Notice that in the horde configuration, conversion rates double (0.32), giving civilians almost zero time to get their affairs in order.
delta simulates humans fighting back. It is a zombie kill-rate coefficient. In horde mode, the sheer mass of numbers drops human defense efficacy down to a despair-inducing 0.006.

2. The Spatial Index: Uber's H3 Hex Grid

Using rectangular latitude/longitude blocks for mapping introduces severe distortion near the poles, and calculating distances using spherical trigonometry over thousands of points is incredibly slow. Instead, the simulation wraps cities into an elegant hexagonal grid using Uber's H3 spatial index.
Why hexagons?
Because unlike squares, every neighbor of a hexagonal cell shares an identical distance from its center point. This makes cellular automata wave propagation beautiful and simple.
Inside the worker loop, we handle the spread to neighboring areas using h3.gridDisk:

const ringSize = VARIANT_RING[variant];
const neighborIds = h3.gridDisk(cellId, ringSize).filter((id) => id !== cellId);

for (const neighborId of neighborIds) {
  const neighbor = grid.get(neighborId);
  if (!neighbor || neighbor.status !== 'clean') continue;
  if (neighbor.population <= 0) continue;

  const p = spreadProbability(cell, neighbor) * maturityFactor;

  if (rng() < p) {
    infectCell(neighbor, 0.005);
    dirtyCellIds.add(neighborId);
    spreadEvents.push({ fromCenter: cell.center, toCenter: neighbor.center });
  }
}

The Maturity Gate & The Wind Matrix

To prevent the virus from looking like an unnatural, perfectly growing circle, I implemented two neat modifiers:

1. Maturity Gate: Freshly infected cells have incubated the virus for fewer ticks, meaning they spread sluggishly. As a cell matures (maturity = Math.min(1, ticksInfected / 4)), its viral transmission probability maximizes (1.0), creating realistic pulsing waves of infection instead of a robotic uniform march.

2. Deterministic Wind: When initializing the simulation, a pseudorandom direction vector (windAngle and windStrength) is calculated. The spread probability math incorporates this vector, pushing the outbreak along specific prevailing paths (e.g., chasing weather dynamics or structural layouts).

3. Simulating Chaos: Panic Flight Long Jumps

Real people do not sit quietly waiting for their hex cell to be overrun. They climb into cars, hit highways, and flee. This human behavior is modeled using Panic-Flight Long Jumps:

if (cell.status === 'overrun' && maturity >= 1 && hasTransit(cell)) {
  if (rng() < LONG_JUMP_BASE_P) {
    const jumpRing = 3 + Math.floor(rng() * 3); // Ring 3 to 5
    const candidates = h3.gridRing(cellId, jumpRing);
    if (candidates.length > 0) {
      const target = candidates[Math.floor(rng() * candidates.length)];
      const tgt = grid.get(target);
      if (tgt && tgt.status === 'clean' && tgt.population > 0 && hasTransit(tgt)) {
        infectCell(tgt, 0.003);
        dirtyCellIds.add(target);
        spreadEvents.push({ fromCenter: cell.center, toCenter: tgt.center });
      }
    }
  }
}

If an infected hex reaches maximum maturity and sits adjacent to major transportation lines (hasTransit(cell)), it triggers a jump. The engine leaps over intermediate rings entirely using h3.gridRing(cellId, jumpRing), instantly creating isolated, non-contiguous cluster breakouts miles away from the primary containment zone.

4. Determinism: Mulberry32 Seeded PRNG

If a user shares a link to a simulation run, the recipient should witness the exact same chaotic sequence of events. Native Math.random() cannot handle this because it's completely non-deterministic. To solve this, the simulation implements a custom Mulberry32 pseudorandom generator inside the background thread:

createRng(seed: number): () => number {
  let s = seed;
  return () => {
    s |= 0;
    s = (s + 0x6d2b79f5) | 0;
    let t = Math.imul(s ^ (s >>> 15), 1 | s);
    t = (t + Math.imul(t ^ (t >>> 7), 61 | t)) ^ t;
    return ((t ^ (t >>> 14)) >>> 0) / 4294967296;
  };
}

By passing down an explicit simulation seed integer, this fast, bitwise generator returns identical floating-point sequences every single time, giving us total reproducible control over the chaos.

5. Client Thread Optimization: Micro-routing with A* & Heaps

When an infection spreads from one cell to another, the UI draws a particle stream representing the civilian flight line. Drawing straight lines over real geometry looks terrible. Instead, map.ts intercepts these spread events and routes them along the city’s actual OpenStreetMap road network.To ensure the mapping stays completely performant, it uses an optimized A Routing Strategy* paired with a custom low-overhead Binary Min-Heap:

class MinHeap {
  private d: { id: number; f: number }[] = [];
  get size() { return this.d.length; }
  push(x: { id: number; f: number }) { /* O(log n) tree balancing bubble up */ }
  pop(): { id: number; f: number } | undefined { /* O(log n) bubble down */ }
}

Instead of looping blindly through thousands of vertices across the whole city to locate the nearest intersection node, the application maps the node array indices into uniform coarse spatial coordinate boxes (nodeGrid) via a hashing utility:

function gk(lng: number, lat: number, s: number): string {
  return `${Math.floor(lng / s)},${Math.floor(lat / s)}`;
}

This allows the lookup engine to query a constrained localized $5\times5$ tile region grid during its search (for (let dx = -2; dx <= 2; dx++)), shrinking node localization from a sluggish O(N) operation down to an instantaneous O(1) lookup.
Once localized, the A* paths are handed to MapLibre GL for rendering. If the distance exceeds an absolute boundary, the engine gracefully fallbacks to linear tracking, preventing long-distance jumps from eating valuable clock cycles.

6. Visual Trickery: 3D Building Extrusion Reveals

Uploading thousands of complete complex geometry features to GPU buffers on every frame causes noticeable stuttering. To avoid this, map.ts utilizes feature state binding.
When a city is loaded, every building is indexed into its respective H3 grid index cell using h3.latLngToCell at resolution level 9 (BUILDING_RES = 9).

dirtyCells.forEach((cell) => {
  const indices = this.buildingCellIndex.get(cell.cellId);
  if (!indices) return;
  const next = cell.status === 'overrun' ? 'overrun' : cell.status === 'infected' ? 'infected' : 'clean';
  indices.forEach((idx) => {
    this.map.setFeatureState({ source: 'city-buildings', id: idx }, { revealStatus: next });
  });
});

By leveraging generateId: true on the GeoJSON layout, MapLibre assigns constant numerical IDs tracking index entries. When a hex vector updates, the system fires targeted setFeatureState updates only for the structural elements linked to that specific altered grid boundary.
MapLibre GL translates these state changes via data-driven styling expressions directly inside the GPU paint pipeline:

'fill-extrusion-height': [
  'match',
  ['coalesce', ['feature-state', 'revealStatus'], 'clean'],
  'overrun', 90,
  'infected', 45,
  3
]

As a result, buildings dynamically "grow" from a baseline footprint height of 3 meters up to an ominous 90-meter crimson spire when completely overrun—handled entirely via high-speed GPU interpolation transitions, with zero data-reupload overhead!

What I Learned About High-Performance JavaScript

Avoid JSON serialization in loops: Do not pass thousands of deep objects over postMessage every 16ms. The background thread filters down to dirty cells only and caps visual spread tracers to small batches per tick.

GPU expressions are magic: Keeping your JS logic small and letting MapLibre's underlying shaders handle transitions (fill-extrusion-color-transition) keeps performance exceptionally light.

Hexagons rule the world: Square bounding coordinates make math tedious. Hex grids turn adjacent neighborhood discovery into a fast, fixed array query.

Try out the project here: Zombie-Outbreak

Please leave a star on the github repo if you liked what you saw.
Thanks.