# Production implementation blueprint

This document turns the research conclusion into a build plan for a web game, Unity, Godot, or Unreal.

## 1. Product boundary

The product is not “text to final art-complete map.” The first useful product is:

> text/reference → valid tactical greybox → engine scene → automated tests → editable semantic revision

Art dressing comes after geometry and gameplay validation.

## 2. Core services/modules

### 2.1 LevelSpec editor

Responsibilities:

- schema-aware JSON/visual editing;
- stable IDs;
- storey tabs;
- room/route graph view;
- 2D plan overlay;
- marker and portal editing;
- semantic wall painting; and
- human lock/pin controls so regeneration preserves approved areas.

### 2.2 Topology planner

Input: design brief and game mode.  
Output: abstract graph before coordinates.

Graph node types:

- spawn zone;
- objective/site;
- staging zone;
- lane segment;
- junction;
- rotation zone;
- vertical transition;
- exterior entry;
- anchor/cover zone; and
- optional/destructible shortcut.

Graph edge attributes:

- traversable state;
- width class;
- elevation change;
- visibility relationship;
- team pressure;
- destructible/locked state; and
- target travel time.

### 2.3 Metric layout solver

Start with integer-grid rectangles. Add CP-SAT or a custom backtracking solver for:

- room dimensions;
- adjacency;
- non-overlap;
- bounding envelope;
- route distance ranges;
- storey alignment;
- stair/hatch footprints;
- exterior access; and
- symmetry/asymmetry constraints.

Use a weighted objective for compactness, preferred adjacency lengths, and route-time targets.

A practical two-pass solver:

1. place route “spines” and objectives;
2. grow rooms/corridors around the spines while preserving constraints.

### 2.4 Geometry compiler

Compiler passes:

1. normalize units and coordinate convention;
2. rasterize/arrange spaces;
3. assign one owner to every boundary edge;
4. group edges into maximal wall runs;
5. resolve portals onto actual shared runs;
6. split walls around openings;
7. generate floors/ceilings and holes;
8. generate stairs/ramps/hatches;
9. emit cover and gameplay volumes;
10. split static versus dynamic semantics;
11. Boolean-bake the static shell; and
12. export engine/collision/nav sources.

Never allow the AI to bypass these passes with hand-authored triangles.

### 2.5 Geometry backend interface

```ts
interface GeometryBackend {
  beginLevel(meta: LevelMeta): void;
  addSolid(id: string, primitive: ConstructivePrimitive, semantic: SemanticTags): void;
  subtractSolid(id: string, primitive: ConstructivePrimitive): void;
  addDynamicPanel(panel: DynamicPanelSpec): void;
  finalizeStaticShell(): GeometryArtifact;
  exportCollision(): CollisionArtifact;
  exportDebug(): DebugArtifact;
}
```

Backends:

- brush `.map`;
- Manifold/mesh Boolean;
- CadQuery/OpenCascade B-rep;
- OpenSCAD batch CSG;
- voxel/SDF fallback; and
- engine-native primitive scene.

### 2.6 Validator service

Return machine-readable diagnostics with stable IDs and measured values:

```json
{
  "severity": "error",
  "code": "PORTAL_NOT_ADJACENT",
  "objects": ["lobby_bar_door", "lobby", "bar"],
  "message": "Requested door has no shared boundary.",
  "suggestions": [
    "Move bar west by at least 1 cell",
    "Insert a corridor between lobby and bar",
    "Change the intended adjacency"
  ]
}
```

Validator categories:

- schema;
- topology;
- dimensions/clearance;
- solid geometry;
- collision;
- navigation;
- visibility;
- game-mode rules;
- performance budget; and
- engine import.

### 2.7 Preview renderer

Every iteration should produce:

- labeled floorplan per storey;
- stacked isometric;
- route graph;
- collision-only view;
- semantic wall-role view;
- navmesh view;
- longest-sightline overlays;
- route heatmaps; and
- a first-person flythrough or fixed camera set.

The AI receives structured metrics plus selected images. A VLM can critique readability and gross visual errors, but numerical validators remain authoritative.

## 3. R6-like runtime data model

```ts
type WallRole =
  | "static_hard"
  | "soft_panel"
  | "reinforcement_slot"
  | "window_barricade"
  | "rappel_entry"
  | "hatch"
  | "destructible_floor";

interface DynamicSurface {
  id: string;
  role: WallRole;
  frame: Transform;
  size: Vec2;
  adjacentSpaces: [SpaceId, SpaceId | "outside"];
  damageGrid?: { columns: number; rows: number };
  penetrationClass: string;
  navLinksByState: Record<string, NavLinkId[]>;
  occlusionByState: Record<string, boolean>;
  replicationKey: string;
}
```

Compile the immutable frame and shell separately from panels. On destruction/reinforcement:

- swap or fracture visual geometry;
- update collision cells;
- toggle nav links;
- update visibility/occlusion;
- replicate state; and
- emit audio/VFX/debris.

Use pre-segmented tiles for a first implementation. Fully dynamic mesh fracture is not required to prove the map pipeline.

## 4. CS/Valorant-like tactical metrics

For each candidate map calculate:

- spawn → site route time by route family;
- defender spawn → hold position time;
- first-contact timing interval;
- edge-disjoint route count;
- rotation time A ↔ B;
- number and width of site entrances;
- longest sightline and percentile distribution;
- exposed distance along each route;
- cover interval distribution;
- number of safe/contested plant cells;
- retake path count;
- elevation-change count; and
- utility occlusion/trajectory opportunities.

Avoid a single scalar “map score.” Keep a vector of descriptors and use quality-diversity search to preserve different viable styles.

## 5. Engine paths

## 5.1 Web / Three.js

Recommended stack:

- TypeScript LevelSpec/compiler;
- robust Boolean in a worker or offline build step;
- GLB static shell;
- simple Box/Sphere/Capsule colliders for dynamic actors;
- Rapier or another physics library;
- Recast/Detour navmesh;
- semantic JSON loaded alongside GLB; and
- WebGPU/WebGL renderer.

Do not keep hundreds of overlapping cubes as the final visible shell. They are acceptable for an editor/debug mode. Bake static geometry and instance repeated dynamic pieces.

## 5.2 Unity

Recommended path:

- import LevelSpec or compiled boxes in an Editor tool;
- use ProBuilder or custom mesh generation for editable greybox;
- bake final static mesh assets;
- generate separate collider assets;
- use NavMesh build automation;
- dynamic panels as prefabs with stable IDs; and
- edit-mode/play-mode tests for paths and capsule sweeps.

Keep the source compiler engine-independent. The Unity adapter handles Y-up, winding, components, materials, and prefab generation.

## 5.3 Godot

Recommended path:

- import boxes/brushes for prototyping;
- use CSG only during editor generation;
- convert/bake to MeshInstance3D for the static shell;
- StaticBody3D with concave collision for the level or optimized primitives where practical;
- dynamic panels with primitive/convex collision;
- NavigationRegion3D and explicit links for vertical/dynamic traversal; and
- GUT/headless scripts for route checks.

Godot’s documentation explicitly warns that CSG nodes have significant CPU cost compared with ordinary mesh instances, especially when moved. Treat CSG as an authoring backend, not a gameplay-time architecture.

## 5.4 Unreal

Recommended path:

- import LevelSpec through an Editor Utility/Python/C++ plugin;
- spawn DynamicMesh/Geometry Script primitives or PCG graph inputs;
- Boolean/bake static geometry;
- generate StaticMesh assets and collision;
- dynamic surfaces as Blueprint/C++ actors;
- NavMeshBounds/links and automated functional tests; and
- semantic tags/Data Assets keyed by stable IDs.

Unreal’s canonical world is left-handed, Z-up, and centimeter-based. Perform that conversion in one backend, never in model-authored map files.

## 6. Agent loop

```text
brief/reference
   ↓
LLM proposes topology graph
   ↓
solver produces metric LevelSpec
   ↓
compiler + validators
   ↓
metrics + errors + previews
   ↓
LLM makes targeted semantic patch
   ↓
repeat until hard constraints pass
   ↓
quality-diversity / bot simulation
   ↓
designer selects candidate and locks regions
   ↓
modular art pass + final engine validation
```

Use transactional generation. A candidate only replaces the accepted version after all hard checks pass.

## 7. Human controls

A useful tool needs more than a text box:

- lock a room or route;
- pin a portal;
- paint no-build zones;
- drag a space and let the solver repair neighbors;
- compare candidates side by side;
- show why a constraint cannot be satisfied;
- keep designer-authored exceptions; and
- branch/merge LevelSpec versions.

The AI should be an editor and search partner, not the sole owner of the map.

## 8. Suggested build sequence

### Milestone 1 — reliable greybox compiler

- rectangular spaces and layers;
- compiler-owned shared walls;
- doors/windows;
- floors and stairs;
- GLB/engine primitive export;
- schema/connectivity/mesh tests.

### Milestone 2 — tactical analysis

- spawns/sites;
- route families and timing;
- LOS sampling;
- cover volumes;
- first-person preview cameras;
- automated regression reports.

### Milestone 3 — R6 semantics

- wall roles;
- reinforcement slots;
- breakable panel grid;
- hatches and floor destruction cells;
- rappel surfaces;
- state-dependent nav/visibility tests.

### Milestone 4 — solver and candidate search

- topology grammar;
- CP-SAT metric placement;
- soft-objective optimizer;
- MAP-Elites archive;
- simple bot simulation.

### Milestone 5 — art pipeline

- modular-kit sockets;
- hidden-face trimming;
- authored trim/decal rules;
- lightmap UVs;
- LOD/occlusion generation;
- performance budgets.

## 9. Acceptance criteria

A generated map candidate should not enter human playtest unless:

- schema and semantic validation pass;
- no unintended coplanar/intersecting static surfaces remain after bake;
- static collision is closed where required;
- player capsule traverses all declared routes;
- nav graph has expected components;
- every objective is reachable from every required spawn/state;
- spawn safety and route timing are within declared bounds;
- dynamic panels have valid frames and state transitions;
- engine import is reproducible; and
- generated artifacts are tied to the exact LevelSpec hash.

## 10. Recommended immediate next implementation

Use this package as the seed and replace the handcrafted example specs with a topology-to-metric solver. The first solver should generate original CS-style maps with:

- two sites;
- three route families;
- one elevated overlap;
- two defender rotations;
- bounded spawn/site distances; and
- a fixed library of corridor/room width classes.

That problem is constrained enough to solve reliably and rich enough to demonstrate that the architecture produces maps rather than merely reconstructing a reference.