DEV Community: Rowan Vale

Indexing 6,000+ Map Points for an Extraction Game: Spatial Queries That Don't Stutter

Rowan Vale — Mon, 03 Aug 2026 10:20:11 +0000

Extraction shooters and PvPvE ARPGs put a strange burden on their community tooling. A normal wiki page answers "what is this item?" An interactive map has to answer a much harder question, dozens of times per second, while the user pans around: which of the thousands of points of interest are inside this rectangle, at this zoom level, with these filters enabled?

When I started sketching a companion map for Mistfall Hunter — Bellring Games' third-person PvPvE extraction ARPG that launched July 29 on Xbox, Steam and Game Pass — the point count looked manageable until it wasn't: spawns, loot containers, objectives, locked doors and extraction zones add up to roughly 6,300 verified coordinates across the game's maps. A naive points.filter(p => inViewport(p)) works in a demo and dies on a mid-range phone. This post walks through the data model and the indexing structure that made the map feel instant, and what I'd do differently next time.

The data model: one table, typed points, no cleverness

The first temptation is to model each point kind as its own entity — a Spawn table, a LootContainer table, an ExtractionZone table. Resist it. On a map, everything is a point with a type and a payload:

type PointType =
  | 'spawn'
  | 'loot'
  | 'objective'
  | 'extraction'
  | 'door';

interface MapPoint {
  id: string;
  map: string;          // map id, if the game has several
  x: number;            // world coordinates, not screen pixels
  y: number;
  type: PointType;
  tier?: number;        // loot rarity tier, objective difficulty, ...
  label: string;
  payload: Record<string, unknown>; // free-form: loot table ref, rotation info, ...
}

A single flat collection matters for two reasons:

Filtering is a bitmask, not a join. The UI has a row of toggle chips ("show loot", "show extractions"). If types live in separate tables, every pan/zoom/filter change becomes N queries and a merge. With one table, a filter is (point.type & activeMask) !== 0.
The index can be built once. Whatever spatial structure you choose, it wants a homogeneous array of {x, y, id} records.

Store world coordinates, never image pixels. The map art will get re-exported at higher resolution the week after you ship, and pixel coordinates silently rot. Keep a single worldToImage transform per map instead.

The query pattern you're actually optimizing for

Profile before you pick a structure. The real workload of an interactive game map is:

Dominant query: axis-aligned bounding-box (AABB) read — "everything inside the current viewport rect."
Frequency: every pointermove / wheel event, so 30–120 Hz, but cheap to debounce to animation frames.
Writes: essentially zero at runtime; the dataset ships as a static JSON and changes on redeploy.
Size: thousands, not millions. ~6,300 points is 300–600 KB as compact JSON, less after gzip.

That profile — read-heavy, static, medium-N — points directly at a static structure built at load time, not a dynamic quadtree.

Why not a quadtree

Quadtrees are the textbook answer and the wrong one here. They shine when points move (players, mobs) or when N is huge. For a static 6k-point dataset:

Rebalancing logic is dead code — nothing ever mutates.
Pointer-chasing through a tree in JS means cache-hostile object graphs.
AABB queries still visit many internal nodes near the rectangle edge.

What worked: a flat grid hash + typed buckets

The structure I settled on is embarrassingly simple: a uniform grid over the map's bounding box, with each cell holding indexes into the flat point array.

class GridIndex {
  private cells: Map<number, number[]> = new Map();
  private cellSize: number;

  constructor(
    private points: MapPoint[],
    private bounds: { minX: number; minY: number; maxX: number; maxY: number },
    targetCellsPerSide = 64,
  ) {
    const w = bounds.maxX - bounds.minX;
    const h = bounds.maxY - bounds.minY;
    this.cellSize = Math.max(w, h) / targetCellsPerSide;
    points.forEach((p, i) => {
      const key = this.key(p.x, p.y);
      let cell = this.cells.get(key);
      if (!cell) this.cells.set(key, (cell = []));
      cell.push(i);
    });
  }

  private key(x: number, y: number): number {
    const cx = Math.floor((x - this.bounds.minX) / this.cellSize);
    const cy = Math.floor((y - this.bounds.minY) / this.cellSize);
    return cy * 4096 + cx; // cheap integer hash; 4096 > cells per side
  }

  query(rect: { minX: number; minY: number; maxX: number; maxY: number },
        typeMask: number): MapPoint[] {
    const out: MapPoint[] = [];
    const x0 = Math.floor((rect.minX - this.bounds.minX) / this.cellSize);
    const x1 = Math.floor((rect.maxX - this.bounds.minX) / this.cellSize);
    const y0 = Math.floor((rect.minY - this.bounds.minY) / this.cellSize);
    const y1 = Math.floor((rect.maxY - this.bounds.minY) / this.cellSize);
    for (let cy = y0; cy <= y1; cy++) {
      for (let cx = x0; cx <= x1; cx++) {
        const cell = this.cells.get(cy * 4096 + cx);
        if (!cell) continue;
        for (const i of cell) {
          const p = this.points[i];
          if (!(typeMask & (1 << typeIndex(p.type)))) continue;
          if (p.x >= rect.minX && p.x <= rect.maxX &&
              p.y >= rect.minY && p.y <= rect.maxY) out.push(p);
        }
      }
    }
    return out;
  }
}

Two details do the heavy lifting:

Cell size chosen from N, not vibes. With ~6,300 points, 64×64 cells give an average of ~1.5 points per occupied cell. A viewport query touches a few hundred cells, examines a few hundred points, and keeps maybe a few dozen. That's microseconds, not milliseconds.
The grid returns candidates; the final AABB test returns exact hits. Cells overlap rectangle borders, so the inner loop re-checks bounds. Skipping that check is the classic bug that makes markers "bleed" one cell past the viewport edge — harmless until you use the same query for hit-testing clicks.

Build cost at load is O(N) and takes ~2 ms for 6k points. The whole index is a Map<number, number[]> and a typed flat array — trivially serializable, trivially testable.

Clustering at low zoom is a separate problem

Zoomed all the way out, an AABB query correctly returns 4,000 points — which no renderer and no human wants. Don't solve this by degrading the index; solve it at the rendering layer:

When query() returns more than a threshold (I use ~300), switch the renderer to density rendering: accumulate the candidate points into a coarse screen-space grid and draw one cluster badge per occupied cell with a count.
Keep the same spatial index for both modes. Clustering libraries that rebuild their own tree per zoom level are wasted work on a static dataset.

const hits = index.query(viewport, typeMask);
if (hits.length > 300) renderClusters(hits);
else renderMarkers(hits);

Click hit-testing: reuse the index in reverse

The other query a game map needs is "which point did the user just click?" — a point query, not a rectangle query. The grid handles it for free: build a tiny AABB around the cursor (say ±8 px converted to world units at current zoom), run the same query(), then pick the nearest hit by Euclidean distance. No second index, no O(N) scan.

Testable invariants worth writing down

Map data is crowd-verified and drifts. Two cheap property tests caught more bad data than any manual review:

Every point lies inside its map's declared bounds. Off-by-one-tile coordinates from a data-entry error show up as markers in the void — or worse, silently dropped by the index key function.
Querying the full map bounds returns every point of the requested types. This round-trip test catches both index bugs and corrupted payloads in one assertion.

it('index round-trips all points', () => {
  const all = index.query(mapBounds, ALL_TYPES_MASK);
  expect(new Set(all.map(p => p.id)).size).toBe(points.length);
});

Seeing it in the wild

If you want to see what this feels like at full scale, the community database Mistfall Hunter Wiki & Build Tools runs exactly this kind of interactive map over its ~6,300 verified spawn/loot/objective/extraction points, layered with its item and recipe data. Toggling the loot/spawn/extraction layers while panning is a live demo of why the filter-as-bitmask + static-grid combination works: the query cost stays flat no matter which layers are on.

Takeaways

One flat, typed point collection beats per-type entities for map data.
Static dataset + AABB-dominant reads = uniform grid hash, not a quadtree.
Cell size from point density (~1–2 points per cell), exact bounds re-check inside the loop.
Clustering is a rendering decision, not an indexing decision.
Round-trip property tests turn map data drift from silent rot into CI failures.

6,000 points feels like "too many to hand-place, too few to engineer for." It's exactly the range where a hundred lines of deliberate indexing turn a janky demo into something players actually leave open on a second monitor.

Representing Roguelite Build Effects Without Hard-Coding Every Combination

Rowan Vale — Wed, 29 Jul 2026 10:58:19 +0000

Build planners for roguelites become fragile when every effect is encoded as a special case. Pass the Fear is a useful example: characters, weapons, relics, tarot cards, battle scars, skill nodes, and weapon parts can all change a run. The combinatorial space grows too quickly for a long chain of if statements.

Describe effects as data

Start with stable IDs and a small vocabulary of operations. A relic effect could be represented as:

{
  "sourceId": "relic-example",
  "trigger": "on_hit",
  "operation": "multiply",
  "stat": "damage",
  "value": 1.15,
  "conditions": ["target_burning"]
}

The public relic directory remains readable for players, while the structured record can be evaluated by tools. The same approach works for the weapon database, where base stats and upgrade effects should be stored separately.

Define an evaluation order

The hard part is not storing a 15% bonus. It is deciding when that bonus applies. A deterministic pipeline might be:

load character base stats;
apply permanent skill-tree modifiers;
apply weapon and part modifiers;
apply relic and tarot modifiers;
evaluate battle-scar tradeoffs;
calculate conditional effects for the selected scenario.

Writing the order down prevents two UI screens from producing different totals. It also makes balance patches easier to test.

Keep provenance with every fact

Every value should include a source version or verification note. When a patch changes a weapon, the system can flag builds that still depend on an older value instead of silently returning a plausible but incorrect result.

A character directory can expose role and starting-kit data, while the skill tree supplies node-level modifiers. The records stay independent but join through stable IDs.

Make the planner explain itself

A useful build planner should show more than a final score. It should list which sources changed damage, cooldown, survivability, or status effects and in what order. Explainable calculations help players notice mutually exclusive choices and assumptions.

Design for discovery

The main Pass the Fear Wiki ties the systems together, but each tool and directory should link back to the underlying entities. That creates a navigable knowledge graph for players and keeps the site maintainable.

The general lesson is to treat game effects as composable data, define evaluation order explicitly, and preserve provenance. Then adding a new relic or weapon becomes a content update instead of another hard-coded branch.

Modeling Crafting Dependencies for a Scrap Mechanic Planner

Rowan Vale — Wed, 29 Jul 2026 10:55:31 +0000

Crafting-heavy games look simple until a player asks a practical question: “What do I need to build this machine, including every intermediate part?” At that point a recipe list becomes a dependency-graph problem. Scrap Mechanic is a useful case study because its parts, Craftbot recipes, upgrade chains, crops, and survival raids all affect planning.

Model recipes as directed edges

Each craftable output should point to its ingredient requirements, while every ingredient should have a stable item ID. A compact representation might look like this:

{
  "outputId": "controller-level-3",
  "quantity": 1,
  "station": "craftbot",
  "ingredients": [
    {"itemId": "component-kit", "quantity": 4},
    {"itemId": "circuit-board", "quantity": 6}
  ]
}

A public parts database can render the readable item pages, but the same records should power a crafting reference and any planning tools.

Expand dependencies recursively

A crafting planner can walk the graph until it reaches raw resources. The important details are:

multiply ingredient quantities by the requested output count;
merge repeated materials after expansion;
detect cycles or invalid recipes;
preserve station requirements;
let players mark inventory they already own.

Memoizing each expanded recipe keeps large plans responsive. It also makes the calculation deterministic enough to test with fixtures whenever a game update changes recipe data.

Keep blueprint analysis separate

A blueprint analyzer has a different input grain. It starts with a serialized creation, counts parts by UUID, and joins those IDs back to the item database. Keeping this parser separate from the recipe graph makes both systems easier to validate.

The useful output is not only total block count. Mass, component categories, controller usage, bearings, pistons, and missing or modded UUIDs help a builder understand why a creation behaves the way it does.

Treat raids as another calculator

Survival planning also depends on farm value and timing. A raid calculator can translate planted crops into an expected raid level, then explain the thresholds instead of presenting a mystery number.

One source, several interfaces

The main Scrap Mechanic Wiki connects these views, but the architecture works because the tools do not maintain competing copies of the same facts. Normalize item IDs, version the source data, validate every relationship, and generate player-facing tools from that shared model.

That pattern applies well beyond one game: dependency graphs are the right abstraction whenever crafting, upgrades, and inventories overlap.

Designing a Data-First Companion Wiki for DragonSword: Awakening

Rowan Vale — Wed, 29 Jul 2026 10:46:36 +0000

A game wiki becomes much more useful when it is treated as a small data product instead of a stack of prose pages. DragonSword: Awakening is a good example because its 19 playable heroes, Tag-team interactions, upgrade materials, and exploration data all overlap.

Start with a normalized content model

I would keep heroes, roles, elements, skills, materials, recipes, and map locations as separate entities, then connect them through stable IDs. That avoids copying the same material or skill data into multiple pages and makes later balance updates less error-prone.

A hero record can stay small:

{
  "id": "hero-slug",
  "role": "breaker",
  "element": "fire",
  "tagTriggers": ["launch", "stun"],
  "materialIds": ["mat-a", "mat-b"]
}

The public hero directory is the human-readable view, while the same relationships can drive filters and comparison tools.

Build tools from the same source

Once the content is normalized, a team builder should not need a second hand-maintained dataset. It can derive role coverage, Tag-chain compatibility, and missing support functions from the hero records.

The same principle applies to a material planner: let users select upgrade goals, aggregate required items by ID, and show which requirements are shared across heroes. This is more useful than forcing people to maintain a spreadsheet beside the wiki.

Treat maps as structured data

An interactive map works best when each marker stores a type, region, coordinates, prerequisites, and source notes. That makes filtering and later validation much easier than embedding coordinates directly in presentation code.

Design for discovery

The main DragonSword: Awakening Wiki links the datasets and tools together, but every entity page should also provide contextual links back to related heroes, items, bosses, or locations. This helps both players and crawlers discover the graph naturally.

The broader lesson is simple: store facts once, derive tools from the same model, and make every useful record reachable from navigation and search. A companion site built this way can survive patches without turning each update into a manual rewrite.